Comments 8
1. Как задаются стили элементов? Как оно выглядит, когда задаваемых свойств много, допустим 10?
2. Вся работа производится в JVM, в натив через JNI не думали переносить?
- Т.к UI в коде, то можно написать стиль как метод, который получает Builder и проставляет нужные пропсы. Но также есть поддержка андроидных стилей, например, в
Text.create()можно передать либо styleId, либо themeAttrId, и которых будут взяты значения TextAppearance и тд - Litho — это JVM. А вот Yoga кроссплатформенная. Т.е измерения элементов и учёт их layout_props идёт через Йогу и будет одинаково работать на разных платформах. Она под капотом у Litho, ComponentKit, ReactNative и во многих других браузерных решениях
Круто, что можно вынести ещё больше расчётов из главного потока, но мне всегда не нравилось программировать аннотациями, так как в моём понимании здесь проще ошибиться. Может быть, Вы развеете мои опасения: насколько легко ошибиться в описании тех или иных компонентов, что это выявится только на этапе кодогенерации или, ещё хуже, на этапе выполнения? Были ли добавлены линт-правила, чтобы на этапе компиляции некоторые ошибки отлавливать?
С кодогенерацией действительно возникают сложности удовлетворения контрактам – вместо фич языка (т.е прямо во время написания кода в IDE) вас будет ограничивать компилятор. Но это явные правила, ошибки с ними легко отлавливаются, т.к компилятор явно ругается (не нужно никаких линт-правил, Litho-процессор покрывает эти ситуации), однако за счёт этих контрактов и статических методов можно явно запретить пользователям ввести Состояние (поля класса, например) там, где не надо. Что при неправильном использовании, вызвало бы очень хитрые и трудноотлавливаемые ошибки при многопоточной обработке UI. Так что это меньшее из зол.
А для того, чтобы раньше отлавливать ошибки, не дожидаясь компиляции мы и работаем над плагином к IDE – он и методы правильно поможет описать, и ошибки подсветить прямо в IDE, и компоненты сгенерить без сборки всего приложения
Во-первых, фреймворк создан был 5 лет назад, а заопенсоршен 3. Гораздо раньше, чем о Компоузе начали думать. Т.е это уже production-proven решение. Да, это проблема, что в маркетинг вкладывалось недостаточно усилий, и, например, на территории СНГ мало кто о нём слышал. Но предположение, что его никто больше не использует ошибочно – взгляните сюда для контекста: https://www.appbrain.com/stats/libraries/details/litho/litho
Второй момент в том, что не так много приложений, которые сталкиваются с реальными проблемами при работе с тяжёлыми списками, скажем. И в таких ситуациях, вместо того, чтобы тратить кучу времени на ручные оптимизации, можно использовать готовый Litho.
И третий момент в том, что все разработчики знают, как работать с View, разбираться в декларативке мало кто хотел. А если UI работает и на привычных View, то зачем трогать. С годами ситуация менялась в лучшую сторону, появлялись Epoxy и прочие, обёртки над View, типа Anko. А теперь вообще создан хайп вокруг этого и люди, даже если раньше не хотели вникать в новый подход, начинают тянуться за модой
Очень интересно, но пока ничего не понятно
Litho: лучшие практики для создания эффективного UI в Android