Почему мы нуждаемся в избыточности в реакции

Question

Я сделал одно маленькое веб-приложение, используя ReactJS. Это легко поддерживать и понятно. Теперь я изучил Redux и планирую реализовать на нем. Нужно больше вещей и дополнительных вещей (для создания магазина, редукторов и т. Д.). Я лично думал, что без излишней реакции это нормально, легко понять и поддерживать состояния. Тогда зачем нам дополнительные вещи (Redux)?

Answer 1

Причины использования Redux:

Одна и та же часть состояния приложения должна быть сопоставлена ​​с несколькими контейнерные компоненты.

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

Глобальные сильные текстовые компоненты, к которым можно получить доступ из любого места.

Обычно существуют компоненты, которые работают в течение всего жизненного цикла приложения (для одностраничного приложения это происходит каждый раз при перезагрузке точки входа), которые выполняют такие функции, как показ уведомлений, снэк-баров, всплывающих подсказок, модалов, интерактивных учебных пособий и т. Д. В Redux вы можете создавать действия, которые отправляют команды этим компонентам, например, если код выполняет асинхронный запрос к бэкэнду, он может отправлять действие show snackbar в случае сбоя запроса. Без Redux вам потребовалась бы какая-то другая система событий или нужно было бы создавать экземпляр компонента «закусочная» каждый раз, когда он используется.

Слишком много реквизита проходит через несколько иерархий компоненты.

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

Управление состоянием с использованием setState приводит к вздутию компонента.

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

Состояние страницы кэширования.

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

Answer 2

Как сказано на редукционной странице мотивации :

Поскольку требования к JavaScript для одностраничных приложений имеют усложняется, наш код должен управлять больше состояния, чем когда-либо прежде. Это состояние может включать в себя ответы сервера и кэшированные данные, а также локально созданные данные, которые еще не были сохранены в сервер. Состояние пользовательского интерфейса также усложняется, так как нам нужно управлять активными маршрутами, выбранными вкладками, счетчиками, элементами управления разбиением на страницы, и т. д.

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

Как будто это не так уж плохо, подумайте о новых требованиях распространены в разработке передовых продуктов. Как разработчики, мы ожидается обработка оптимистичных обновлений, рендеринг на стороне сервера, выборка данные перед выполнением маршрутов и т. д. Мы находимся пытаясь справиться со сложностью, с которой нам никогда не приходилось сталкиваться раньше, и мы неизбежно задаем вопрос: пора ли сдаваться? ответ - нет.

С этой сложностью трудно справиться, поскольку мы смешиваем две концепции человеческому разуму очень трудно рассуждать о мутации и асинхронность. Я называю их Ментос и Кола. Оба могут быть хорошими в разделение, но вместе они создают беспорядок. Такие библиотеки, как React попытаться решить эту проблему в слое представления, удалив оба асинхронность и прямое манипулирование DOM. Тем не менее, управление состоянием Ваши данные оставлены на ваше усмотрение. Это где Redux входит.

Выполнение шагов Flux, CQRS и Event Sourcing, Redux пытается сделать состояние мутаций предсказуемым путем наложения определенных ограничения на то, как и когда могут происходить обновления. Эти ограничения отражены в трех принципах Redux.

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

Answer 3

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

Вам не нужен Redux , если без него легко управлять состоянием вашего приложения.

Answer 4

TL; DR: Потому что вы сделали "одно маленькое веб-приложение". Не все веб-приложения маленькие.

Наиболее тривиальные примеры того, почему вам может это нужно, включают:

• Иногда несвязанные компоненты должны совместно использовать состояние.
• Иногда состояние необходимо обновлять не только компонентами, а другими вещами.

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

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

(Хотя даже в этих случаях это может быть полезно; как всегда, «это зависит».)