Redux: Как управлять конфликтующими состояниями на разных маршрутах? - PullRequest
1 голос
/ 04 июля 2019

В моем приложении на route1 я получаю список предметов из вызова API. Компонент подключен, и элементы сохраняются в redux хранилище и передаются в компонент в качестве реквизита. Теперь на route2 мне снова нужен этот список предметов. Сейчас я снова получаю список предметов, когда мы переходим на route2

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

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

  3. Имеет ли смысл называть эти кусочки состояния по-разному, чтобы одно не мешало другому? Это кажется неправильным, поскольку обе функциональные возможности одинаковы, и мы не хотели бы для этого увеличивать размер глобального состояния.

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

Ранее я использовал useReducer для вызовов axios. В этом случае состояние было локальным для каждого из компонентов / маршрута, поэтому им не нужно было заботиться о том, было ли это состояние заполнено кем-то другим. У этого подхода были проблемы с разделением состояния между маршрутами, но проблема локального состояния была хорошо обработана.

Ответы [ 2 ]

0 голосов
/ 04 июля 2019

Я был в этой ситуации, и я использовал следующий подход:

  1. Сохраняйте одно состояние для обоих маршрутов. Так как это единственная точка сохраняя единый источник правды в приложении. Если мы хотим сохранить отдельный список для обоих маршрутов, тогда мы можем напрямую использовать состояние, которое, я думаю, здесь не требуется.
  2. Выборка списка должна быть сделана в componentDidMount из На первом маршруте и на маршруте 2 вы можете снова получить список и сравнить данные на основе некоторой контрольной суммы, если у нас есть новые данные или нет, если у нас есть новые данные, обновите исходный список. В этом у нас нет проблема устаревших данных тоже.

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

0 голосов
/ 04 июля 2019

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...