Я хотел бы в кое-чем признаться. Мне нравится работать с React. Сначала, когда я начал изучать фреймворк, он показался мне запутанным. Это был большой отход от того, с чем я раньше работал в виде фреймворка MVC, такого как Ruby on Rails. Не сразу было понятно, с чего начать. Где я могу разместить свои контроллеры? А модели? Почему нет четкой файловой структуры? Однако эти вопросы быстро уступили место оценке динамизма и гибкости React.

В то время как девиз Rails — конвенция превыше конфигурации, что означает, что вам нужно настроить только нетрадиционные аспекты вашего приложения, с React все в ваших руках, чтобы формировать и формировать соответствующим образом. Это, конечно, поначалу кажется более пугающим, но со временем становится вдохновляющим.

Одним из особенно замечательных аспектов React является его обработка state. Что такое государство? Состояние — это просто место, где хранятся данные вашего приложения. Мощным аспектом React является создание виртуальной DOM (объектной модели документа), которую приложение проверяет на наличие любых изменений и повторно отображает только ту часть приложения, в которой произошло изменение. Каждый компонент React может иметь собственное локальное состояние, и, кроме того, состояние может передаваться от одного компонента к его дочерним компонентам с помощью props.

Тем не менее, по мере того, как ваше приложение усложняется, и особенно когда вам необходимо поддерживать общие точки данных в вашем состоянии для всех компонентов, например, информацию о пользователе, состояние на основе компонентов React начинает становиться неуклюжим. Затем, в 2015 году, вошел в Redux. Что случилось с Redux? Проще говоря, это единственный источник достоверной информации для вашего приложения.

Другими словами, Redux помогает создать единый store для всех данных вашего приложения, который беспрепятственно распределяется по всему приложению. В Redux разработчик использует reducer действия, которые фиксируют изменения в файле store. Каждому компоненту предоставляется доступ только к элементам в состоянии, к которому, по мнению разработчика, ему нужен доступ, путем сопоставления состояния Redux с реквизитами внутри этого компонента. Так, например, вы можете поддерживать несколько файлов редукторов, организованных для различных действий в вашей программе (например, редукторы API, редукторы поиска, редукторы аутентификации и т. д.), но в конечном итоге все эти данные обрабатываются в одном хранилище: источник истины.

Когда вы должны внедрить Redux в свое приложение? Это источник обсуждения в сообществе React. Поскольку Redux является промежуточным программным обеспечением, дополнительным слоем поверх вашей программы (хотя и очень маленьким), некоторые люди утверждают, что его следует включать только тогда, когда это необходимо. То есть, когда становится ясно, что различные состояния, основанные на компонентах, и передача данных по компонентам становятся несостоятельными. В то время как другие считают, что Redux следует включать на ранней стадии разработки приложения, чтобы избежать необходимости рефакторинга позже.

У меня нет твердого мнения по поводу этой дискуссии. Я создавал приложения, которые запускались без Redux, а затем возвращались и включали его, и где Redux был включен сразу же, даже когда не было очевидно, что он нужен на том этапе. Я думаю, что хорошее раннее планирование, до того, как в редакторе будет зафиксирована хоть одна строка кода, для разработки и развития программы прольет свет на то, какое промежуточное ПО, включая Redux, необходимо для приложения. Такое разумное планирование, вероятно, лучше, чем строгая приверженность какой-либо конкретной ортодоксии Redux: всегда Redux с самого начала или никогда Redux с самого начала.

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

Дополнительные ресурсы:
1. ReactJS
2. React на Github
3. Использование Redux с React