Redux FAQ: Настройка хранилища

Содержание

Настройка хранилища

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

Оригинальная 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. Кроме того, подписчики предназначены для реагирования на само значение состояния, а не на действие. Миддлвэр может быть использован, если действие важно и нуждается в специальной обработке.

Дополнительная информация

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

Обсуждения

Библиотеки

results matching ""

    No results matching ""