IN
А зачем делить?)
Size: a a a
2021 May 30
AI
Чтобы был ssot и была консистентность
IN
Зачем делить состояние и хранить их в разных слоях и классах?
JF
у меня есть похожий кейс, с историей поиска. Там у меня запросы связаны с результатом. И реализована история, когда выбором предыдущего запроса чиститься все, что было выше него
Но все это происходи внутри одного класса
Но все это происходи внутри одного класса
JF
в этом примере исходный settings хранится вне памяти
AI
Да, всё состояние целиком хранится в памяти, в одном месте и в одном классе, в единственном экземпляре.
AI
Изименить состояние можно только в одном месте - в редьюсере. Ну это если MVI/TEA и т.д.
JF
Я так понимаю, что когда пользователь нажимает "отмена" он возвращается назад в навигации. А что еслибы ему нужно было показать исходное состояние (без возврата)?
IN
Что напишешь то и будет. Ничего автоматические не произойдет, ты сам пишешь поведение. Вернешь туда , куда надо.
AI
Тогда надо заменить editing на содержимое из settings
AI
В моём случае факт наличия editing (!= null) одзначает видимость диалога с полями ввода
JF
а если settings из сети берется? (как с профилем)
AI
У меня из базы например, принцип тот же. Сначала загружаем, потом храним
JF
и при каждой "отмене" открывать базу?
AI
Нет. Один раз загружаем из базы в settings. Когда надо начать редактирование - компируем из settings в editing. Отмена - снова копируем. Применить, копируем в обратную сторону и записываем в базу.
JF
тогда почему settings и editing это 1 состояние, когда их 2
AI
Потому что эти два "подсостояния" лежат в одном общем классе State, и его измение контролируется одной единственной функцией.
JF
вот теперь понял
AI
Кроме того, обеспечивается атомарность изменения и чтения состояния.