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