Могу ли я хранить все мое состояние в 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).

Source: rajdee.gitbooks.io