Redux - несколько магазинов, почему бы и нет?

Как примечание: я прочитал документы для 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, но я успешно использовал его в производстве в течение нескольких месяцев.

+174
источник поделиться
6 ответов

Существуют крайние случаи, когда вы можете использовать несколько магазинов (например, если у вас есть проблемы с производительностью при обновлении списков тысяч элементов, которые отображаются на экране одновременно много раз в секунду). Это говорит о том, что это исключение, и в большинстве приложений вам не нужно больше, чем один магазин.

Почему мы подчеркиваем это в документах? Поскольку большинство людей, прибывающих из фона Flux, будут предполагать, что несколько магазинов - это решение сделать модульный код обновления. Однако у Redux есть другое решение для этого: состав редуктора.

Наличие нескольких редукторов, которые далее разделены на дерево редукторов, - это то, как вы сохраняете модульные обновления в Redux. Если вы не узнаете об этом и не перейдете к нескольким магазинам, не в полной мере понимая композицию редуктора, вы пропустите много преимуществ архитектуры единого хранилища Redux:

  • Использование редукторной композиции позволяет легко реализовать "зависимые обновления" a la waitFor в Flux, написав редуктор, вручную вызывающий другие редукторы с дополнительной информацией и в определенном порядке.

  • В одном магазине он очень легко сохраняется, увлажняет и считывает состояние. Реализация сервера и предварительная выборка данных тривиальны, потому что на клиенте требуется только одно хранилище данных, которое должно быть заполнено и регидратировано, а JSON может описать его содержимое, не беспокоясь о идентификаторе или имени магазина.

  • В одном магазине предусмотрены возможности перемещения по времени Redux DevTools. Он также упрощает расширение сообщества, например, сокращение-сокращение или сокращение-оптимист, поскольку они работают на уровне редуктора. Такие "усилители редуктора" не могут быть записаны для магазинов.

  • Один магазин гарантирует, что подписки вызывают только после обработки отправки. То есть, к тому времени, когда слушатели будут уведомлены, государство полностью обновлено. Со многими магазинами таких гарантий нет. Это одна из причин, по которой Флюсу нужен костыль waitFor. В одном магазине это не проблема, которую вы видите в первую очередь.

  • Прежде всего, в Redux нет необходимости в нескольких хранилищах (за исключением случаев крайностей производительности, которые вы должны сначала профилировать). Мы делаем это важным моментом в документах, поэтому вам рекомендуется изучить композицию редуктора и другие шаблоны Redux вместо использования Redux, как если бы это был Flux, и потерять свои преимущества.

+181
источник

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

Например, я обычно рассматриваю следующие общие функциональные области как отдельные приложения:

  • Администратор
  • Аналитика/данные в информационных панелях
  • Управление биллингами и потоки покупок
  • Командная консоль предприятия/управление правами

Если какая-либо из этих вещей невелика, просто сохраните их как часть основного приложения. Если они растут очень большими (как это делают некоторые инструменты управления учетными записями предприятий и аналитиками), разделите их.

Лучший способ управлять очень большими приложениями - рассматривать их как состав многих небольших приложений.

Если ваше приложение меньше, чем сказать ~ 50k LOC, вы, вероятно, должны игнорировать этот совет и следовать рекомендациям Dan.

Если ваше приложение превышает 1 миллион LOC, вы, вероятно, должны делиться мини-приложениями, даже если вы поддерживаете их в режиме моно-репо.

+14
источник
другие ответы

Связанные вопросы


Похожие вопросы

Несколько магазинов могут быть полезны в следующих случаях использования 1. Если у вас есть большие компоненты, которые независимы друг от друга с точки зрения структуры данных, поведения, контекста приложения. Изоляция этих компонентов упрощает управление потоками данных и приложений. Это также помогает независимому развитию и обслуживанию ваших компонентов. 2. Проблемы с производительностью: не типичный вариант использования, но если некоторые из ваших компонентов обновляются очень часто и не оказывают никакого влияния на другие компоненты, возможно, вы можете пойти в разные магазины.

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

+3
источник

Это архитектурное решение принадлежит разработчикам приложений на основе потребностей их проектов.

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

  • Это не надежно, потому что части магазина не изолированы.
  • Это неэффективно, потому что вы клонируете и пересекаете хэш-три. Когда мутации растут арифметически - сложность растет геометрически. Вы не можете исправить это путем рефакторинга каких-либо редукторов, селекторов и т.д. Вы должны разделить свою базу данных.
  • Когда это становится медленным, никто не хочет разделить это на отдельные приложения с отдельными магазинами. Никто не хочет тратить деньги на рефакторинг. Люди обычно конвертируют некоторые умные компоненты в дамп и тому подобное. Знаете ли вы, какое будущее ждет разработчиков излишков? Они будут поддерживать эти ады.
  • Это не дружественная отладка. Трудно отлаживать соединения между практически изолированными частями магазина. Очень сложно даже проанализировать количество этих связей.

Представьте, что у вас есть несколько магазинов редуксов. Вы нарушите однонаправленный поток данных. Вы сразу поймете, сколько связей между магазинами у вас есть. Вы можете страдать от этих связей, сражаться с круговыми падениями и т. Д

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

+3
источник

Наличие одного хранилища в Redux действительно то, что нам нужно во многих случаях, я использовал Redux и Flux и считаю, что Redux делает работу лучше!

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

Также концепция одного магазина имитирует базу данных для нас, один источник правды, который вы можете изменить, и вы можете получить к ней доступ в памяти браузера...

Если все приложение хорошо управляется, одного хранилища может быть достаточно для управления всем статусом приложения...

+1
источник

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

Объяснение: почему мы не можем использовать несколько магазинов, используя RedEx????

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

Исходный шаблон Flux описывает наличие нескольких "хранилищ" в приложении, каждое из которых содержит отдельную область данных домена. Это может привести к таким проблемам, как необходимость обновления одного магазина "waitFor" в другом магазине.

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

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

Некоторые допустимые причины использования нескольких магазинов в Redux могут включать:

Решение проблемы производительности, вызванной слишком частыми обновлениями некоторой части состояния, что подтверждается профилированием приложения. Изоляция приложения Redux как компонента в более крупном приложении, в этом случае вы можете создать хранилище для каждого экземпляра корневого компонента. Тем не менее, создание новых магазинов не должно быть вашим первым инстинктом, особенно если вы пришли из Flux. Сначала попробуйте составить редуктор и использовать несколько магазинов, только если это не решит вашу проблему.

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

официальный документ по редуксу

0
источник

Посмотрите другие вопросы по меткам или Задайте вопрос