Медленно, и можно нарваться на то, что дом обновиться где не надо
По крайней мере по опыту
Я уверен, что кто работал в больших проектах с этим, могут поточнее набросать

Ещё была проблема, что стейт начинает ликаться из одного места в другое, тип бизнес логика одной фичи начинает быть по всему стейту одновременно
Но я уверен, что это изи избежать можно, я просто писал больше на скорость

При хорошо спроектированном стейте (нормализованном) большинство апдейтов ничего не стоит, т.к. проверяются ссылки в первую очередь, и редко доходит до сравнения полей объектов. Recoil лучше интегрирован в современный реакт (построен на хуках изначально), и в отличии от провайдеров контекста - горизонтален (можно о нем думать как об N редакс сторах). Был уже похожий mobx который решал примерно те же проблемы, но redux все равно привлекает простотой. Если вы читаете это все, и думаете "о чем эти люди говорят", то советую послушать выпуск подлодки с создателем redux https://podlodka.io/154

О, была подлодка с дэном

Спасибо :)

Во, хорошо сформулировано. Плюс мы часто хотим, чтобы была модульность, то есть внешний стейт вообще ничего не знал про внутреенний

Ну так это все работает только если речь идет о мобильном экранчике или о простенькой страничке. Когда ты заранее знаешь какие элементы где будут, как они будут взаимодействовать и как все это "нормализовать". А если это отдельные компоненты, которы взаимодействуют между собой хитрым образом и могут подгружаться и заменяться?

при инициализации можно задать набор middleware и сам state

Если мы говорим про компоуз, а мы все-таки в котлин чате. Выглядит более логично. Модель определяется отдельно. И может обновляться, скажем, из Flow

Ну я вот как раз про это говорил
Теоретически, все это можно организовать, но на практике люди делают как проще, а не как правильно
Хочется что-то более близкое к mobx как раз, где у компонентов отдельные состояния, которые как то синкаются (:wink wink: mvicore")

Я не понимаю в чем архитектурная разница?
Там setState  тут stateFor - а дальше е__тесь как хотите

Разница в подходе к проектированию и в @Model

А вы слышали что @Model уже задеприкейтили?

Нет. А можно ссылку?

Я вообще только сейчас читать внимательно про него начал

Там же сделали руками несколько имплементаций оберток и сказали юзать их

ссылку хочу!

https://developer.android.com/jetpack/androidx/releases/compose#0.1.0-dev12

и чуточку проскролить к

> @Model annotation is now deprecated

О, делегатики. Ну тоже хорошо

> @Model annotation is now deprecated

спасиб