Перейти к содержанию

Настройка стора

Могу/должен ли я создавать несколько сторов? Могу ли я импортировать мой стор напрямую и использовать его в компонентах?

Оригинальная Flux-архитектура предполагает наличие нескольких “сторов” в приложении, каждое из которых хранит определенную область данных. Однако, это может привести к тому, что потребуется создать стор, который будет ждать обновления другого. Redux исключает такой случай, так как разделение данных на области достигается дроблением одного редьюсера на более мелкие.

Как и с другими вопросами по Redux, технически возможно создать несколько различных сторов, но шаблон предполагает только один стор. Наличие единственного стора дает возможность использовать Redux DevTools, делать сохранение и восстановление данных (для отладки по time-travel) и упрощает логику подписки.

Веские причины по использованию нескольких сторов в Redux должны включать:

  • Решение проблем с производительностью, связанные со слишком частыми обновлениями некоторых частей сторов во время длительного профилирования приложения.
  • Выделение Redux-приложения в компонент более крупного приложения. В этом случае Вам, возможно, потребуется стор для экземпляра главного компонента.

Однако, создание новых сторов не должно быть первым, что Вы будете делать, особенно если Вы пришли из Flux. Для начала, попробуйте композицию редьюсеров. Используйте несколько сторов только в том случае, если композиция не решила Вашей проблемы.

Кроме того, пока у Вас есть возможность передавать экземпляр Вашего стора напрямую, не рекомендуется множить сторы в Redux. Если Вы создаете экземпляр стора и передаете его из модуля, то это будет синглтон. Это значит, что будет сложно выделить Redux-приложение в качестве компонента большего приложения, если нет необходимости или возможности сделать на сервере, потому что на сервере вы можете создать разделенные экземпляры сторов для каждого запроса.

С React Redux классы-оболочки, созданные при помощи функции connect(), ищут props.store, если оно существует. Но будет лучше, если Вы обернете Ваш главный компонент в <Provider store={store}> и позволите React Redux позаботится о пробросе ссылки на стор по всему дереву компонентов. Таким образом, компонентам не нужно заботиться о получении доступа к стору, а будущее отделение Redux-приложения или возможность серверного рендеринга становится проще.

Документация

Обсуждения

Нормально ли использовать более одного мидлвара в моем расширителе стора? В чем разница между next и dispatch в функции мидлвара?

Redux мидлвар ведет себя, как связанный список. Каждая мидлвар-функция может также вызвать next(action) для передачи экшена следующему мидлвару в цепочке. Вызов dispatch(action) перезапустит процесс и начнет с начала цепочки. Или можно вообще ничего не вызывать, чтобы остановить дальнейшую обработку экшена.

Упомянутая выше цепочка мидлваров описывается в аргументах функции applyMiddleware, которая используется при создании стора. Определение нескольких цепочек не будет корректно работать, так как они будут иметь сильно отличающиеся объявления dispatch, и отличающиеся цепочки будут эффективно отключены.

Документация

Обсуждения

Как мне подписаться на получение только части стора? Могу ли я получить запущенный экшен, как часть подписки?

Redux предоставляет единственный метод store.subscribe для объявления прослушивателей обновлений стора. Обработчики не получают состояние в качестве аргумента — они лишь сообщают, что что-то изменилось. Затем в прослушивателе можно вызывать getState(), чтобы получить текущее значение состояния.

Этот API, как низкоуровневый примитив без зависимостей или усложнений, может быть использован для построения высокоуровневой логики подписок. UI-привязки, такие как React Redux, могут создавать подписчков для каждого подключенного компонента. Это дает возможность писать функции, которые могут грамотно сравнивать старое состояние и новое и выполнять дополнительные экшены, если определенные части были изменены. Примеры включают redux-watch и redux-subscribe, которые предлагают различные подходы определения подписчиков и отлова изменений.

Новое состояние не передается прослушивателям, чтобы упростить реализацию расширенных возможностей стора, таких как Redux DevTools. Кроме того, подписчики предназначены для реагирования на само значение состояния, а не на экшен. Мидлвар может быть использован, если экшен важен и нуждается в специальной обработке.

Документация

Обсуждения

Библиотеки

Комментарии