Д
Так а что за mvu? Что то не могу ничего найти
Model-View-Update aka The-Elm-Architecture aka TEA
PS гуглить лучше the elm architecture
Size: a a a
2020 August 03
I
mvi это какое-то извращенное mvu завязанное на rxjava (или др реактивных стримах)
Д
Ну смысл тот же по сути
I
Ну все unidirectional-flow архитектуры по сути похожи (и redux и flux)
Д
А где в этом случае хранится логика? Аналог презентера или вью модели
I
в функции update
вот тут серия статей есть от @sgrekov
- https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-1-566caae0f706
- https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-2-c709f75f7596
- https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-3-f37a7a630ec1
вот тут серия статей есть от @sgrekov
- https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-1-566caae0f706
- https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-2-c709f75f7596
- https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-3-f37a7a630ec1
Д
Спасибо, сейчас перечитаю
Д
Если отойти сейчас от интерактивности, само построение представления корректно так производить? Т.е. вместо того чтоб передавать всю модель состояния в функцию и там ее педалить отрисовывая то или иное состояние, разделить состояния на отдельные вьюхи грубо говоря
(
Если отойти сейчас от интерактивности, само построение представления корректно так производить? Т.е. вместо того чтоб передавать всю модель состояния в функцию и там ее педалить отрисовывая то или иное состояние, разделить состояния на отдельные вьюхи грубо говоря
можно, но непонятно зачем
Д
можно, но непонятно зачем
Ну, для разделения ответственности
I
Я облажался и вместо 30 сек, поставил 30 мс 😔
Д
Я облажался и вместо 30 сек, поставил 30 мс 😔
Будем считать что тест пройден в таком случае)
I
Если отойти сейчас от интерактивности, само построение представления корректно так производить? Т.е. вместо того чтоб передавать всю модель состояния в функцию и там ее педалить отрисовывая то или иное состояние, разделить состояния на отдельные вьюхи грубо говоря
Ну как бы одному другому не противоречит.
- Делишь на вьюхи
- Передаешь им ВЕСЬ необходимый стейт в параметрах
По идеи чем вьюха ближе к "лист", тем меньше у нее должен быть стейт
- Делишь на вьюхи
- Передаешь им ВЕСЬ необходимый стейт в параметрах
По идеи чем вьюха ближе к "лист", тем меньше у нее должен быть стейт
I
В корне должен быть весь стейт и даже функции для хранения его (
state() )Д
Ну мне не нравится идея передавать в стейт ошибки к примеру модель в которой есть список с данными, пусть и пустой
Д
Ограничить бы набор данных для определенного состояния
I
Ну так ADT (алгебраические типы данных)
- Произведение
Дробишь стейт на кучу мелких стейтов, вложенных в друг друга (data) классов
- Сумма
Выражаешь отдельные стейты в виде sealed class
- Произведение
Дробишь стейт на кучу мелких стейтов, вложенных в друг друга (data) классов
> Ограничить бы набор данных для определенного состояния
- Сумма
Выражаешь отдельные стейты в виде sealed class
I
ООП / интерфейсы / абстрактные классы и тд для этого вообще не нужно
Д
ага, понял