AI
я пока не понимаю как в реалиях compose перерисовать компонент не перерисовывая все остальное, так вообще можно?
Конечно можно
Size: a a a
2020 August 15
Д
а каким образом можете подсказать?
AI
ML
Ты можешь делать единый стейт и вкладывать компоненты прямо себе в стейт. Тогда будет неприятность с тем, чтобы прокидывать месседжи редьюсеру компонента и интегрировать результаты в единый стейт
Аналогично, можешь делать независимые черные коробочки а-ля MVICore, но с каждой коробочкой стейт все больше будет дробиться и тебе придется все больше думать о том, как и в какой последовательности связывать коробочки, как у них настроить жц и DI
Аналогично, можешь делать независимые черные коробочки а-ля MVICore, но с каждой коробочкой стейт все больше будет дробиться и тебе придется все больше думать о том, как и в какой последовательности связывать коробочки, как у них настроить жц и DI
Я для себя выбрал подход с единым стейтом, так как мне кажется, что такое проще скейлить. Начинаю на следующей неделе петпроджект, в котором доведу до абсолюта. Посмотрим, как оно будет работать
ML
Вообще, это как раз проблема simple vs easy
ML
Типа затянуть либу, которая всё будет за тебя делать и мучаться с конфигурацией, чужими багами и настройкой или сделать самому только тот функционал, который нужен
AM
Я для себя выбрал подход с единым стейтом, так как мне кажется, что такое проще скейлить. Начинаю на следующей неделе петпроджект, в котором доведу до абсолюта. Посмотрим, как оно будет работать
Я надеюсь, в опенсорсе со старта?)))
AD
Типа затянуть либу, которая всё будет за тебя делать и мучаться с конфигурацией, чужими багами и настройкой или сделать самому только тот функционал, который нужен
так это от размера команды еще сильно зависит
если толпа в 25+ человек будет один редьюсер месить - будет очень больно
если толпа в 25+ человек будет один редьюсер месить - будет очень больно
AD
я пытаюсь сам принцип понять -
мессадж+стейт -> редусер -> стейт+эффект
эта цепочка вроде как одна на все приложение, параллельно ничего не происходит, значит мессадж от компонента попадет туда, следовательно мессадж от компонента получит редусер экрана и должен будет направить в редусер компонента. как редусер компонента может получить этот мессадж напрямую я не понимаю, можете как то на пальцах обьяснить? я понимаю что может быть тупой вопрос, так что извиняюсь заранее за него, но я не догоняю
мессадж+стейт -> редусер -> стейт+эффект
эта цепочка вроде как одна на все приложение, параллельно ничего не происходит, значит мессадж от компонента попадет туда, следовательно мессадж от компонента получит редусер экрана и должен будет направить в редусер компонента. как редусер компонента может получить этот мессадж напрямую я не понимаю, можете как то на пальцах обьяснить? я понимаю что может быть тупой вопрос, так что извиняюсь заранее за него, но я не догоняю
Сколько костылей вместо стейт монады
AI
Я для себя выбрал подход с единым стейтом, так как мне кажется, что такое проще скейлить. Начинаю на следующей неделе петпроджект, в котором доведу до абсолюта. Посмотрим, как оно будет работать
Да, и это основой вопрос к этому подхожу) потому что разделять на компоненты и собирать из в дерево (особенно если есть удобный фреймворк для стыковки типа RIBs) более чем масштабируемый. Как раз делали чтобы толпой наваливать код независимо.
Д
подождите, может я изначально заблуждался, но вроде как суть mvi(mvu) была в том чтоб был общий стейт и одна цепочка обработки месседжей, чтоб убрать параллельность в обновлении вью. а если вью продолжают обновлять состояния в любой произвольным момент времени, по моему это уже что то не то
ошибаюсь?
ошибаюсь?
DE
Я для себя выбрал подход с единым стейтом, так как мне кажется, что такое проще скейлить. Начинаю на следующей неделе петпроджект, в котором доведу до абсолюта. Посмотрим, как оно будет работать
вообще мне кажется, что это скорее подход для мелких приложений. В крупных проектах может быть много отдельных независимых фичей, которые будут работать, как отдельное приложение. Вот единый стейт на фичу выглядит интереснее в этом плане
AI
подождите, может я изначально заблуждался, но вроде как суть mvi(mvu) была в том чтоб был общий стейт и одна цепочка обработки месседжей, чтоб убрать параллельность в обновлении вью. а если вью продолжают обновлять состояния в любой произвольным момент времени, по моему это уже что то не то
ошибаюсь?
ошибаюсь?
У единости может быть "скоуп". Это может быть приложение, или часть экрана.
KD
фф стабильно и легко работает
А дип линки он научился нормально открывать? Ибо раньше не умел.
ML
так это от размера команды еще сильно зависит
если толпа в 25+ человек будет один редьюсер месить - будет очень больно
если толпа в 25+ человек будет один редьюсер месить - будет очень больно
Бля, да чего вы все с одним редьюсером. Их же много, просто собраны в один. Никто же блять не против, что 25+ человек один DI граф месят?
ML
Да, и это основой вопрос к этому подхожу) потому что разделять на компоненты и собирать из в дерево (особенно если есть удобный фреймворк для стыковки типа RIBs) более чем масштабируемый. Как раз делали чтобы толпой наваливать код независимо.
Ну тут как с даггером - если разобрался и есть проблемы, которые им можно решить, то все ахуенно. Но начинать проект сразу с ribs по мне это самоубийство
ML
подождите, может я изначально заблуждался, но вроде как суть mvi(mvu) была в том чтоб был общий стейт и одна цепочка обработки месседжей, чтоб убрать параллельность в обновлении вью. а если вью продолжают обновлять состояния в любой произвольным момент времени, по моему это уже что то не то
ошибаюсь?
ошибаюсь?
Ты ошибаешься в том, что мешаешь в кучу mvi и mvu
Д
ну я на mvu сейчас в первую очередь ориентируюсь
AM
А дип линки он научился нормально открывать? Ибо раньше не умел.
Не юзаю этот функционал, так что не в курсе
Д
ну я на mvu сейчас в первую очередь ориентируюсь
хотя я шо то шо то пока что хреново понимаю