экранов? Хочу понять как decompose ложиться на большое приложение
Можно сделать базовый интерфейс для компонентов с Composable функцией Content, и реализовывать её в каждом компоненте. Т.е. полиморфизм через наследование, вместо when. Но тут тогда другие минусы.
@arkivanov, может ты подскажешь? Я пока нечто такое придумал: abstract class FeatureEntry<T : RootScreenConfig>( val configClass: KClass<T> ) { @Composable abstract fun <R : T> Render(config: R, componentContext: ComponentContext) }
Да, но тогда как искать экраны и как передавать аргументы?
Если есть у кого примеры многомодульных проектов на decompose было бы классно глянуть - пока все что видел это один монолит
Там when в двух местах - в компоненте в childFactory при создании дочерних компонентов и в UI при отображении. В первом случае мне кажется не избавиться от when, т.к. в любом случае надо создавать N компонетов (N вызовов конструкторов). Во втором случае поможет общий Composable интерфейс, но появятся другие минусы (компонент знает о UI).
Мне не нравится что в текущем варианте есть компонент который знает обо всех экранах - я бы хотел этого избежать
Вот простой но с несколькими модулями пример - https://github.com/IlyaGulya/TodoAppDecomposeMviKotlin
Надо группировать компонеты, например вынести флоу авторизации в отдельный компонет. Сделать отдельные компонеты для Signed-In и Signed-Out состояний, и т.д.
А что?
Предлагаю перейти в https://t.me/mvikotlin :-)
А сколько у вас экранов?
Эх, мне не нравится там работа со вложенными графами навигации, с диплинками и общая стабильность библиотеки
Точно не меньше 10
Она же хороша только тем что сделана гуглом
С диплинками все прям плохо?
Никому не верь Сам попробуй У меня нет проблем с ними.
А как вы открываете диплинк во вложенном графе навигации с бекстеком?
Я не помню про вложенность Но диплинк хорошо открывается и бекстек на месте Приложение несколько раз приводила) см профиль
Бекстек должен уметь сетиться из диплинка, а компоуз это не позволяет
Обсуждают сегодня