Реагировать на управление состоянием компонентов с использованием приставки

Question

Итак, в основном, я сталкивался со многими статьями, в которых они ссылаются на управление состоянием через поток или избыточность. Я хотел бы знать, как насчет того, чтобы компонент пользовательского интерфейса имел свое собственное состояние? Является ли хорошей практикой позволить редуксу управлять вызовами Api, сообщениями о тостах успеха и т. Д., Но компоненты пользовательского интерфейса должны иметь свое собственное локальное состояние?Пожалуйста, кто-нибудь уточнит, что является лучшей практикой в ​​отрасли?

Answer 1

Хороший вопрос!Ответ обычно «зависит», но есть явные случаи, когда вы, вероятно, предпочтете использовать один над другим.

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

Используйте состояние компонента для хранения состояния, относящегося только к компонент .То есть, если вы заполняете форму, имеет смысл сохранить значения текстовых вводов, флажков и т. Д. В состоянии вашего компонента (возможно, в сочетании с контейнером и компонентами представления ) в качестве значений вэтот пункт не относится к остальной части приложения.

Answer 2

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

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

Answer 3

Хотя вопрос требует мнения, я собираюсь оставить свой ответ.В этом отношении нет стандартной передовой практики.Это сводится к удобству и основным правилам вашей команды, если код пишут несколько человек.

Я довольно часто использую Redux.Однако я не буду воздерживаться от использования локального состояния в компонентах.

Для обработки форм, таких как обработчики ввода onChange, требуется локальное состояние.Использовать глобальное состояние для обработчиков onChange нецелесообразно.

Повторно используемый компонент использует локальное состояние.Опять же, все сводится к тому, является ли возможность повторного использования технической возможностью повторного использования или повторным использованием в бизнесе.Если вы разрабатываете пользовательский компонент полосы прокрутки, используйте локальное состояние.Однако, если вы используете форму комментария, которая используется повсеместно в вашем приложении, используйте глобальное состояние.

Я предпочитаю, чтобы большая часть материала находилась в глобальном состоянии.Я также использую Redux Thunk.В избыточном транке можно получить доступ к глобальному состоянию внутри функции thunk.Это очень полезно, поскольку позволяет избежать зависимости от пропуска / контекста.

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

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

React - это способ декларативно иметь дело с пользовательским интерфейсом.Есть некоторые правила фреймворка, такие как состояние, реквизит, контекст.Разработчику остается сделать декларативный и производительный интерфейс на основе этих примитивов.То, как разработчик делает это, не имеет значения, если код поддерживается и понятен другим.