Пришла осень и созрела очередная версия фреймворка Chorda 3.0. Можно наконец устроиться поудобнее за чашечкой кофе и подвести некоторые итоги

Про сам фреймворк можно почитать здесь, посмотреть там и пощупать тут

В прошлый раз я рассказывал о дизайн-функции, чертежах и построении API компонентов, а в этот раз попробую заинтересовать вас некоторыми очевидными решениями и не очень очевидными следствиями, которые появились во время работы с Chorda.

Я уже рассказывал про свой UI фреймворк Chorda в предыдущей статье. Интереса он (ожидаемо) не вызвал, но остался как полигон для испытания идей и подходов, которые кажутся мне интересными.

Фреймворк немного подрос, преобразился, но в его основе так и осталась концепция смешивания (перекрытия) конфигураций и упор на декларативность

При разработке UI библиотеки на базе Chorda я столкнулся с неожиданной проблемой: без постоянного обращения к коду сложно понимать, как увязывать компоненты друг с другом. Была универсальная конфигурация, заданная фреймворком, но отсутствовал специфичный API. А для библиотеки, которую ты хочешь передать другим разработчикам, это просто приговор.

Как удалось исправить ситуацию и что в итоге получилось можно узнать, заглянув под кат

Каждый раз, когда мне нужно сесть за создание нового приложения, я впадаю в легкий ступор. Голова идет кругом от необходимости выбрать, какую же библиотеку или фреймворк взять на этот раз. Вот в прошлый раз я писал на библиотеке X, но теперь уже подрос и хайпанулся фреймворк Y, а еще есть классный UI Kit Z, да и с прошлых проектов осталась куча наработок.

С какого-то момента я понял, что фреймворк не имеет особого значения — то, что мне нужно, я могу сделать на любом из них. Тут вроде следует обрадоваться, взять что-то с макимумом звездочек на гитхабе и успокоиться. Но все-равно постоянно появляется непреодолимое желание сделать что-то свое, свой собственный велосипед. Ну что ж. Немного общих размышлений по этому поводу и фреймворк под названием Chorda ждут вас под катом.