React-Redux: должны ли все состояния компонентов храниться в магазине Redux

скажем, у меня есть простой тумблер:

когда я нажимаю кнопку, цвет компонента изменяется между красным и синим

Я мог бы достичь этого результата, делая что-то вроде этого.

.js 
Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

контейнер.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

редуктор.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

но это чертовски много кода писать для чего-то, что я мог бы достичь в 5 секунды с jQuery, некоторыми классами и некоторыми css...

так что я думаю, что я действительно спрашиваю, что я делаю неправильно здесь?

4 57
javascript reactjs redux

4 ответа:

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

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

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

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

97

Redux FAQ: организация государства
эта часть redux official doc хорошо ответила на ваш вопрос.

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

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

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

с целью выделения отличной ссылки, предоставленной @AR7, и потому, что эта ссылка переместилась некоторое время назад:

используйте React для эфемерного состояния, которое не имеет значения для приложения глобально и не мутирует сложными способами. Например, переключатель в каком-либо элементе пользовательского интерфейса, состояние ввода формы. Используйте Redux для состояния, которое имеет значение глобально или мутирует сложными способами. Например, кэшированные пользователи или черновик записи.

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

эмпирическое правило: делайте то, что менее неудобно.

дан Абрамов:https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

4

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

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

по соображениям производительности, вы можете вернуться к this.setState() для всего, что бы отправить много действий повторно. Например: сохранение состояния поля ввода в Redux каждый раз, когда пользователь вводит ключ, может привести к снижению производительности. Вы можете решить эту проблему, рассматривая ее как транзакцию: как только пользовательское действие "зафиксировано", сохраните конечное состояние в Возвращение.

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

0