Это сотрудничество с Хуаном Канепой. Не только мой коллега, но и хороший друг :)

Прежде чем начать читать, мы исходим из того, что вы хотя бы раз работали с React и Redux.

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

С этим введением мы можем углубиться в нашу тему: передовой опыт в React/Redux.

Спойлер: это не полный список фейлов, это даже не самые критичные ошибки при программировании, а несколько вещей, которые мы видели в проектах, над которыми работали.

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

Передовая практика (GP) №1. Инициализация состояния: не используйте null.

Вместо этого используйте реальное значение, например число (-1, 0, 1, 2, …), строку или даже массив или object, но никогда не null, потому что это может быть источником некоторых проблем с пользовательским интерфейсом.

ГП №2. Чем меньше контейнерных компонентов, тем лучше для вас… и вашей команды!

Довольно часто встречаются такие ситуации, когда компонент-контейнер использует в качестве дочернего компонента другой компонент-контейнер, я имею в виду другой компонент с отслеживанием состояния со всей его логикой.

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

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

Решение? Только один компонент-контейнер (или как можно меньше), а затем компоненты без сохранения состояния.

ГП №3. Очистите состояние по завершении действия/процедуры/асинхронного процесса…, а не по componentWillMount.

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

Решение?: Очистите состояние после завершения рабочего процесса процесса:

ГП №4. Не изменяйте данные.

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

Но, очевидно, если мы сейчас говорим об этом, то не потому, что это хорошая идея, а наоборот, потому что нам нужно помнить, какие типы изменяемы, а какие неизменяемы в Javascript:

Изменяемые: объект, массив, класс…даже множество и карта.
Неизменяемые: строка, число, логическое значение, символы.

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

Итак, вместо этого сделайте что-то вроде:

Сделай это:

…и все будет хорошо :)

ГП №5. Избегайте глубоких предметов.

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

  1. Клонировать объекты глубины.
  2. Реорганизуйте данные.

Когда мы говорим о клонированных объектах глубины, мы имеем в виду не объекты с 2 или 3 уровнями, а настоящие объекты глубины с несколькими вложенными уровнями, для которых в некоторых случаях требуются сторонние библиотеки.

Типичный пример может быть таким, как показано ниже:

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

Это неправильно из-за дополнительной сложности, и в результате мы привыкаем к серьезным проблемам с нашими данными. У вас должен быть более чистый способ получить те же данные.

Лучший способ получить тот же результат — использовать селекторы или какую-нибудь неизменяемую библиотеку. Итак, наше решение было больше похоже на:

Вы можете узнать больше о шаблоне обновления Immutable в официальной документации Redux.

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