Перейти к основному содержимому

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

Неофициальный Бета-перевод

Эта страница переведена PageTurner AI (бета). Не одобрена официально проектом. Нашли ошибку? Сообщить о проблеме →

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

Обязательно ли хранить всё состояние в Redux? Можно ли использовать useState или useReducer из React?​

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

Использование локального состояния компонента — это нормально. Разработчик сам решает, какие типы состояний составляют его приложение и где должно находиться каждое состояние. Найдите баланс, который подходит именно вам.

Общие эмпирические правила для определения, какие данные стоит помещать в Redux:

  • Важны ли эти данные для других частей приложения?

  • Нужно ли создавать производные данные на основе этих исходных данных?

  • Используются ли эти данные для управления несколькими компонентами?

  • Есть ли ценность в возможности восстановить это состояние на определённый момент времени (например, для отладки с перемещением во времени)?

  • Хотите ли вы кэшировать данные (использовать существующие в состоянии вместо повторных запросов)?

  • Нужно ли сохранять согласованность данных при горячей замене компонентов (которые могут терять внутреннее состояние)?

Дополнительные материалы​

Статьи

Обсуждения

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

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

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

Дополнительные материалы​

Обсуждения

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

Данные с идентификаторами, вложенными структурами или взаимосвязями обычно следует хранить в «нормализованном» виде: каждый объект сохраняется один раз с ключом-идентификатором, а другие объекты, ссылающиеся на него, должны хранить только этот ID вместо полной копии. Можно представлять части вашего хранилища как базу данных с отдельными «таблицами» для каждого типа элементов. Библиотеки вроде normalizr и redux-orm помогут управлять нормализованными данными.

Дополнительные материалы​

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

Статьи

Обсуждения

Следует ли хранить состояние форм или другой UI-логики в хранилище?​

Те же эмпирические правила применимы и к этому вопросу.

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

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

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

  • Если ручное написание форм кажется слишком сложным, попробуйте библиотеки для работы с формами на основе React, такие как Formik или React-Final-Form.

  • Если вы абсолютно уверены, что должны использовать Redux-ориентированную библиотеку, потому что другие подходы недостаточны, рассмотрите Redux-Form или React-Redux-Form.

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

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

Дополнительные материалы​

Статьи