Можно ли сохранять локальное состояние в объекте state при использовании реакции вместе с сокращением? Хранение всего в дереве штата через действия быстро становится утомительным. Похоже, что какое-то состояние имеет значение только для представления/отображения приложения, а не для логики. Под презентацией я подразумеваю анимацию/мигание, расширенное/сжатое состояние панелей, критерии сортировки в таблицах и т.д.
Работа с локальным состоянием в реакции и редукции
Ответ 1
Трудно ответить, потому что разные люди классифицируют разные части компонента как "состояние".
Так как Redux заботится о состоянии приложения, как правило, все, что вы ожидаете от кнопки "Отменить/повторить" на уровне приложения, должно происходить как действие Redux. Тот факт, что Redux имеет плагин для магазина отмены, возможен только из-за доступности состояния приложения.
Конечно, некоторые анимации не будут отменены, так как они действительно должны быть связаны с изменениями в состоянии приложения, а не изменениями внутри себя. Остальные ваши примеры, похоже, очень похожи на состояние приложения. Если бы я отсортировал таблицу и затем отменил отмену, я бы абсолютно ожидал, что сортировка будет отменена.
Ответ 2
Теперь это ответ на редукция часто задаваемых вопросов:
Для этого нет "правильного" ответа. Некоторые пользователи предпочитают хранить каждую отдельную часть данных в Redux, чтобы поддерживать полностью сериализуемую и контролируемую версию своего приложения в любое время. Другие предпочитают сохранять некритическое или пользовательское состояние, например, "это раскрывающийся список в настоящее время открыто", внутри внутреннего состояния компонента.
Использование локального состояния компонента прекрасное. Как разработчик, ваша задача - определить, какое государство составляет ваше приложение, и где должно жить каждое государство. Найдите баланс, который работает на вас, и идите с ним.
Ответ 3
Как уже упоминал Тириус - есть разные мнения об этом.
Для нас - как правило, мы должны отслеживать все с состоянием приложения, которое мы хотели бы видеть, если мы будем удаленно подключаться к текущему сеансу некоторых пользователей.
Если мы не хотим видеть, что мышь зависает над некоторым элементом, мы можем использовать только состояние компонентов для этого (если нам нужно состояние тогда вообще).
У нас есть только несколько таких случаев в наших сценариях, хотя мы хотели бы точно знать, что пользователь видит в большинстве случаев для более легкой отладки.
Вы упоминаете расширенные/скомпенсированные состояния для панелей - мы иногда создаем компоненты, которые обрабатывают эту расширенную/свернутую логику для нас, поэтому нам не нужно писать такие редукторы все время для каждой панели, которую мы создаем.
Мы можем использовать эти компоненты следующим образом:
<Panel id="somePanelId">some content</Panel>
Компонент панели будет следить за активным состоянием панелей в состоянии приложения. Таким образом, очень просто сохранить ваш код простым и не позволить ему взорваться.