Как примечание: я прочитал документы для Redux (тоже Baobab), и я сделал немалую долю в Google и тестировании.
Почему так настоятельно рекомендуется, чтобы приложение Redux имело только один магазин?
Я понимаю плюсы и минусы настройки одного магазина по сравнению с настройкой нескольких магазинов ( Есть много вопросов и ответов по SO на эту тему ).
ИМО, это архитектурное решение принадлежит разработчикам приложений на основе потребностей их проектов. Так почему же это так настоятельно рекомендуется для Redux, почти на грани звучания обязательно ( хотя ничто не мешает нам создавать несколько магазинов )?
РЕДАКТИРОВАТЬ: обратная связь после преобразования в один магазин
После нескольких месяцев работы с redux над тем, что многие считают сложным SPA, я могу сказать, что работать с единой структурой магазина было просто приятно.
Несколько моментов, которые могут помочь другим понять, почему один магазин против многих является спорным вопросом во многих, многих случаях использования:
- это надежно : мы используем селекторы, чтобы рыться в состоянии приложения и получать контекстную информацию. Мы знаем, что все необходимые данные находятся в одном магазине. Это позволяет избежать любых вопросов относительно того, где могут быть проблемы государства.
- это быстро : в нашем магазине сейчас около 100 редукторов, если не больше. Даже при таком количестве данных лишь немногие редукторы обрабатывают данные в любой конкретной отправке, остальные просто возвращают предыдущее состояние. Аргумент, что огромный / сложный магазин ( nbr редукторов ) медленный, в значительной степени спорный. По крайней мере, мы не увидели никаких проблем с производительностью.
- дружественная отладка : хотя это наиболее убедительный аргумент в пользу использования избыточности в целом, он также подходит для одного хранилища против нескольких хранилищ. При создании приложения вы должны иметь ошибки состояния в процессе ( ошибки программиста ), это нормально. PITA - это когда отладка этих ошибок занимает несколько часов. Благодаря единственному хранилищу ( и избыточному логгеру ) мы никогда не тратили больше нескольких минут на какую-либо проблему состояния.
несколько указателей
Истинная проблема в создании вашего магазина редуксов заключается в том, чтобы решить, как его структурировать . Во-первых, потому что изменение структуры в будущем - это просто большая боль. Во-вторых, потому что это в значительной степени определяет, как вы будете использовать и запрашивать данные вашего приложения для любого процесса. Есть много предложений о том, как структурировать магазин. В нашем случае мы нашли идеальным следующее:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
Надеюсь, этот отзыв поможет другим.
РЕДАКТИРОВАТЬ 2 - полезные инструменты магазина
Для тех из вас, кому интересно, как «легко» управлять одним магазином , который может быстро стать сложным. Есть инструменты, которые помогают изолировать структурные зависимости / логику вашего магазина.
Существует Normalizr, который нормализует ваши данные на основе схемы. Затем он предоставляет интерфейс для работы с вашими данными и извлечения других частей ваших данных id, подобно словарю.
Не зная Normalizr в то время, я строил что-то в том же духе. реляционный-json принимает схему и возвращает интерфейс на основе таблиц ( немного похожий на базу данных ). Преимущество реляционного json заключается в том, что ваша структура данных динамически ссылается на другие части ваших данных (по сути, вы можете перемещаться по данным в любом направлении, как обычные объекты JS ). Он не такой зрелый, как Normalizr, но я успешно использую его в производстве уже несколько месяцев.