Redux FAQ: Организация состояния

Содержание

Организация состояния

Могу ли я хранить все мое состояние в Redux? Должен ли я всегда использовать setState() из React?

Не существует “правильного” ответа на этот вопрос. Некоторые пользователи предпочитают хранить все данные в Redux, чтобы поддерживать полностью сериализуемую и контролируемую версию своего приложения на протяжении всего времени. Другие предпочитают выносить некритичные данные (UI состояние), как, например “is this dropdown currently open”, в состояние компонента.

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

Ниже описаны некоторые негласные правила для определения тех частей данных, которые должны хранится в Redux-хранилище:

  • Остальные части приложения используют эти данные?
  • Потребуется ли в дальнейшем возможность создавать данные, основанные на этих данных?
  • Эти данные используются для управления несколькими компонентами?
  • Важна ли Вам возможность восстанавливать это состояние в какой-то момент времени, т.е. отладка по времени (time travel debugging)?
  • Требуется ли кэшировать данные, т.е. использовать то, что уже хранится в состоянии вместо повторного запроса?

Существует несколько пакетов, реализующих различные подходы к хранению данных в Redux-хранилище вместо состояния компонента, таких как: redux-ui, redux-component, redux-react-local и другие. Они также позволяют применять принципы Redux и концепцию редюсера к задачам обновления локального состояни компонента, поддерживая идею this.setState( (previousState) => reducer(previousState, someAction)).

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

Статьи

Обсуждения

Библиотеки

Могу ли я хранить функции, промисы или другие несериализируемые данные в моем хранилище состояния?

Настоятельно рекомендуется класть в хранилище только простые сериализуемые объекты, массивы и примитивы. Технически возможно добавить несериализуемые данные в хранилище, но это может сломать способность сохранять и восстанавливать содержимое хранилища, что сделает невозможным отладку по временной шкале (time-travel debugging).

Если Вы смиритесь с тем, что эти функции возможно не будут работать как положено, то Вы можете спокойно использовать несериализуемые данные в Redux-хранилище. В конечном счете, это Ваше приложение, и как оно будет реализовано — решать Вам. Как и со многими другими вещами в Redux, Вы должны четко понимать, на какие компромиссы идете.

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

Обсуждения

Как мне хранить вложенные или дублирующиеся данные в моем состоянии?

Данные с идентификаторами, вложенностью или отношениями, как правило, следует хранить в “нормализированном” стиле: каждый объект должен быть сохранен однажды, идентифицирован, и другие ссылающиеся на него объекты должны хранить только идентификатор, а не копировать весь объект.

Это помогает думать о частях приложения как о базе данных с отдельными “таблицами” на каждый элемент. Такие библиотеки, как normalizr и redux-orm могут помочь и облегчить управление нормализированными данными.

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

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

Статьи

Обсуждения

results matching ""

    No results matching ""