Сколько государства действительно принадлежит в магазинах?
Мне было интересно, сколько государства действительно принадлежит магазинам, а не компонентам? Я читал в некоторых местах, что действительно все государства должны жить внутри магазинов.
Будет ли это включать действительно специфичные для компонента вещи, такие как входные значения (перед отправкой), проверка входных данных, если модальное окно открыто, если что-то щелкнуло и т.д.?
Каковы лучшие практики здесь?
4 ответа
Хранение всего в магазинах потоков может быть полезным для некоторых приложений.
Итак, сначала вы должны попытаться решить, является ли ваше приложение таким.
- Если вы не уверены, принадлежит ли часть состояния хранилищу потоков, скорее всего, нет.
- Вы будете знать, когда вам нужен поток. И когда вы достигнете такого уровня понимания того, подходит ли вам такая архитектура приложения, вы, вероятно, также узнаете ответ на свой первоначальный вопрос.
Но, конечно, приятно иметь какое-то конкретное руководство, может быть, просто руководство для ума, которое говорит вам, когда сохранять состояние внутри компонента, а когда нет.
Я бы пошел с этими руководствами:
- Это состояние связано исключительно с пользовательским интерфейсом? Тогда вам, вероятно, не нужно хранить его в магазине.
- Распространено ли это состояние где-либо еще за пределами компонента? Если нет, то не кладите его в магазин. Это хорошо внутри компонента.
- Можно ли сохранить это состояние в URL? Если так, то не кладите его в магазин; поместите это в URL! Это может быть поисковый запрос ввода или открытая вкладка.
Могут быть исключения из всего этого, но в целом я считаю, что это хорошо соответствует оригинальным идеям приложения Flux.
PS Также я должен сказать, что есть много разговоров о том, что вы должны (можете) хранить весь свой пользовательский интерфейс в неизменном дереве состояний. Вот как редукс представлен многим людям. Я думаю, вы должны понимать, что, хотя это отличная концепция и она позволяет вам сохранять / воспроизводить любые взаимодействия с пользователем, это чаще всего является ненужным и не является главной идеей Flux. А сам по себе редукс является отличным инструментом, который не заставляет вас сохранять все состояние пользовательского интерфейса в магазинах.
Очевидный ответ:
Сохраняйте специфическое состояние компонента (входное значение, модальное открытие / закрытие, щелчок материала, компоновка, форматирование) как можно больше внутри состояния компонента.
И приложение конкретного состояния внутри магазина. Включая, но не ограничиваясь этим, материал, который вы отправляете с сервера на сервер.
Тем не менее, здесь много серой зоны:
- применяются ли фильтры к состоянию компонента списка поиска? Или состояние приложения (если вы сохраняете фильтры для будущих посещений той же страницы)?
- находятся ли посещенные ссылки в состоянии корневого компонента глобального меню или в состоянии приложения?
- Если вы используете оптимистичные обновления, вам может потребоваться сохранить пользовательский ввод в хранилище, до и после связи с сервером.
Некоторые практические правила, которые я использую:
- Состояние принадлежит компоненту, если у него тот же жизненный цикл, что и у компонента (поэтому, если состояние не нужно существовать до монтирования компонента и если его можно забыть после размонтирования компонента)
- Если состояние необходимо запомнить при закрытии и повторном открытии приложения, его, вероятно, лучше всего поместить в хранилище (где вы обмениваетесь данными с сервером и / или локальным хранилищем)
- Если вы сомневаетесь, начните с состояния только в компоненте: он сохраняет состояние гораздо более локализованным (для компонента) и делает ваш код более управляемым. На более позднем этапе вы всегда можете переместить состояние в магазин.
Это спорный вопрос. Например, приставка предлагает шаблон, где ВСЕ состояние принадлежат магазину. Лично я считаю, что это нецелесообразно во многих ситуациях. Это очень редко, когда у меня есть какая-либо причина, например, хранить состояние кнопки в магазине. Но иногда это может быть выгодно. Определенно легче проверить, когда все ваше приложение не имеет состояния.
Состояние просмотра, относящееся к компоненту, принадлежит этому компоненту. Состояние приложения, касающееся многих компонентов, принадлежит магазину.