Ну так тоже хорошо. Важно, что нет обязательного ограничения, что стейт - внутренний. В реакте правда проблема в основном из-за JS, там без типов не разберешь, что внутреннее, а что внешнее

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

Как раз таки это создано для сложных SPA. С модульностью там проблема только из-за того что splitting усложняется, т.к. store не поддерживает асинхронную подгрузку редьюсеров (а это на самом деле можно очень просто сделать).

Конечно прикрутить компонент который написан без unidirectional-flow в голове сложно, но так же его сложно будет прикрутить в Compose. Блокирующие API плохо прикручиваются к корутинам, портя всю систему - так и тут, если есть существующий компонент который написан для jquery - это не будет работать хорошо. Но можно всегда написать адекватную обертку или лучше всего - написать свои компоненты для системы и там будет все ок.

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

Redux не накладывает тут никаких принципиальных ограничений, компонент ожидает что-то на входе, вы можете его подключить к общему состоянию, например лайкам:

data class Store(val like: LikeStore)
data class LikeStore(val likes: Map<String, Int>)

и имеется два компонента:

fun Foo(like: Int)
fun Bar(complexObject: CompolexObject)

В функции connect как раз таки происходит маппинг одного стейта на два компонента:

body {
    if (addFooComponent) {
        store.connect(::Foo, ::mapStoreToIntLike)
    }
    if (addBarComponent) {
        store.connect(::Bar, ::mapStoreToComplexLike)
    }
}

Общение идет через поток action, и каждый комопонент может кидать свои экшены, остается прикрутить их к этому стору таким же способом

Как видно - компоненты не знают ничего про store, они просто ожидают что-то на входе, им можно дать колбеки которые они будут вызывать чтобы изменить состояния store. Т.е. такая архитектура как раз таки делает компоненты максимально чистыми, они даже не знают что находится с наружи, чистые функции:

fun Foo(like: Int, increment: () -> Unit)
fun Bar(complexObject: CompolexObject, increment: () -> Unit)


body {
   if (addFooComponent) {
store.connect(::Foo, ::mapStoreToIntLike, ::mapStoreToDispatchFunction)
   }
   if (addBarComponent) {
store.connect(::Bar, ::mapStoreToComplexLike, ::mapStoreToDispatchFunction)
   }
}

Да это отличная вещь, которая прибита к redux. Без connect ты ничего не можешь сделать, тем самым твоя архитектура имеет чистые компоненты - что круто.
Но как всегда есть нюанс. Если нужно передать из одной части приложения в другую часть (у нас еще нету хуков) как правило создается еще один стейт в store для передачи данных, тем самым store начинает становиться частью стейтом компонента. Тем самым у нас теряется весь смысл разделения.

Вся крутость и вся проблема redux в том, что это один большой стейт.

Как итог, для меня redux отлично подходит для приложений в несколько десятков экранов, ну или я просто не умею его готовить.

Ну так тогда без разницы, есть там редукс или нет.

Вот теперь не хочу никакого редукса, хочу иметь модельку со stateflow. Круто же

может кто-нибудь знает как бороться с
io.ktor.utils.io.charsets.MalformedInputException: Input length = 1?

> Если нужно передать из одной части приложения в другую часть (у нас еще нету хуков) как правило создается еще один стейт в store для передачи данных, тем самым store начинает становиться частью стейтом компонента. Тем самым у нас теряется весь смысл разделения.

Ну если это нужно двум компонентам в разных частях приложения это конечно глобальный стейт который уходит в store. Store описвается как композиция, и код хорошо масштабируется.

> Как итог, для меня redux отлично подходит для приложений в несколько десятков экранов, ну или я просто не умею его готовить.

Так и не понял где проблема 🙂 Я конечно не писал приложения с 1000 страниц, но на условно систему управления персоналом + рекрутинговая система + админка блога это все отлично прикручивалось.

Ну я на самом деле не писал на редукс. А на реакте в основном замумукался не с менджментом стейта а с багами реконсайла для менеджет компонент.

> багами
ну если баги, то надо репорить) иначе это фичи

К вопросу о багах. Я обещал в ктор зарепортить. Будем обживать трекер

Есть разница в том, что до него (до flux) компоненты сами ходили в сеть, сами меняли свой стейт и сами пытались общаться с другими компонентами. В том что до него two-way-binding было наше все)

> Вот теперь не хочу никакого редукса, хочу иметь модельку со stateflow. Круто же

Круто, интересно как это все будет масштабироваться, ведь нужно видимо создать кучу этих StateFlow и прикрутить в разных частях дерева компонентов. Как будут делаться сайд эффекты в такой архитектуре и т.д.

Ну и как тут получится такая модульная удобная архитектура, которая почему-то не получается с flux подходом

> но на условно систему управления персоналом + рекрутинговая система + админка блога это все отлично прикручивалось.

Да тут всегда отлично. Redux заходит как родной.

> Ну если это нужно двум компонентам в разных частях приложения это конечно глобальный стейт который уходит в store.

Основная проблема, что твои детали ui протекают в store, который общий для всех. Например выбранный таб. Если там где-то был выбран такой-то таб, то в другой части приложения, ставим то и то. Я не считаю, что store должен отвечать за такие мелкие детали ui. Он должен быть более абстрактным. Что решаемо, если начинать думать, о redux более в CLEAN смысле. За счет своей простоты, туда очень легко положить то что не нужно.

> Есть разница в том, что до него (до flux)

unidirectional data flow, отличная шутка, до нее было больно =)

> Ну и как тут получится такая модульная удобная архитектура, которая почему-то не получается с flux подходом

Flux. Волшебная в своей простоте идея, от которой хочется оставить только unidirectional data flow

Не очень понял насчёт сайд эффектов со стейт флоу, зачем и куда :)

> Основная проблема, что твои детали ui протекают в store, который общий для всех. Например выбранный таб. Если там где-то был выбран такой-то таб, то в другой части приложения, ставим то и то. Я не считаю, что store должен отвечать за такие мелкие детали ui. Он должен быть более абстрактным. Что решаемо, если начинать думать, о redux более в CLEAN смысле. За счет своей простоты, туда очень легко положить то что не нужно.

Не вижу тут противоречия с CLEAN, т.к. в connect мы отвязываем компонент от store. Если мы прям хотим спрять какие-то данные от других - можно вообще не обращаться напрямую к store, а писать селекторы которые связаны с редьюсером (вполть до того, что при инициализации генерить уникальный ключ, и тем самым нельзя будет просто пойти в стор и достать что-то в обход этого слоя абстрации.

То что в store хранится много всего - да, и тут основаная проблема что нужно следить за lifecycle - подчищать данные, если данных много и приложение живет долго (например дашбоард).

Ну например я хочу по кнопке сделать запрос, и перерисовать табличку. Куда тут прикладывать StateFlow, какая архитектура будет

Тут опять все предположения исходят из того, что источник данных где-то на сервере, а приложение - это довольно тонкая UI прослойка. Я понимаю, что это основной случай. Но не единственный же.

Нет, это не важно вообще

Тут скорее всего чтот типо блока с флаттера или тип того

Важно. Вы исходите из того, что источником данных является какой-то flux на сервере. А если один из компонентов является источником данных для другого? Прокидывать стейт наверх в стор и потом прокидывать вниз?