Организация компонентов в Jetpack Compose: Еще один вариант

Полная версия тут

5. Хранить данные в Modifier

Чуть позже, просматривая различные репозитории в GitHub, наткнулся на ещё один вариант реализации компонентов, вдохновленный внутренней реализацией Modifier. 

В этом репозитории дизайн система довольно скудная, но реализована она интересным образом. Там есть следующее:

• Кодогенерация с использование KSP для генерации sample приложения, как в google/casa-android
• Компиляторный плагин для генерации компонентов оберток над примитивными компонентами
• Прокидывание данных для компонента через Modifier

Нам интересно последнее. К тому же сами разработчики в Readme акцентируют на этом внимание.

Начну с того, чем вдохновлялись при создании такого решения. В Compose Runtime есть такая функция, как materialize, которая вызывается для каждой LayoutNode. Ее основная задача в том, чтобы проитерироваться по цепочке Modifier.Element и выполнить @Composable лямбды, которые прокидываются через Modifier.composed.

В дизайн системе же Quack-Quack есть функция quackMaterializeOf, которая повторяет логику выше, но для того чтобы вытащить все модели с описанием состояния компонента. Такое возможно, так как модели реализуют Modifier.Element.

В базовом интерфейсе есть дока как создавать новые модели. К тому же планируют скоро переписать на более оптимизированный Modifier.Node. Эта часть очевидна вдохновлена ParentDataModifier.

Причем они даже скопировали работу composed в своей обертке, чтобы после выполнения @Composable лямбды так же вытащить модели для компонента.

Функция quackMaterializeOf вызывается в каждом компоненте, а из всех моделей компоненты вытаскивают только необходимые для них.

Решение выглядит довольно экзотическим. Мне нравится, что они применили идеи из Compose Runtime и UI, но не нравится количество аллокаций для создания экземпляров моделей и списка с моделями. Кроме этого, для больших цепочек будет довольно много итераций, чтобы вытащить нужные модели.

Опубликовано в Полуночные Зарисовки