Этот пост изначально был опубликован в моем блоге. Обратите внимание на похожие типы сообщений. :)

Семь месяцев назад мы решили переписать веб-приложение PowerPost, используя React и Redux. Это был вызов. В то время я был единственным фронтенд-разработчиком и никогда не использовал React в производственной среде. Первые три недели я читал все, что попадалось мне в руки, о React. Я сделал кучу руководств, прочитал о типичных ошибках и перешел к примерам кода с открытым исходным кодом. Теперь, семь месяцев спустя, мы выпустили первую версию веб-приложения на React / Redux.

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

1. Создайте магазин Redux с самого начала.

Наша организация приложений была основана на замечательном React Boilerplate Макса Штойбера. У каждого из наших маршрутов есть собственный редуктор для работы со своей частью магазина Redux. Это упростило модульную разработку. Однако, когда мы начинали, у нас не было определенных спецификаций или требований для каждого маршрута. Неизбежно мы получили несколько маршрутов, которые одинаково действовали на хранилище Redux. Это означало, что нам пришлось несколько раз рефакторинг хранилища Redux на протяжении всей разработки.

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

Дальнейшее чтение об архитектуре / дизайне Redux:

2. Линтинг поможет вам оставаться в здравом уме ...

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

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

Я рекомендую внедрять линтинг с самого начала и выбирать самые строгие правила линтинга, которые все еще приемлемы для вашей команды. Правила бессмысленны, когда им никто не следует.

Дополнительная информация о линтинге:

3. Соблюдайте единый шаблон именования интеллектуальных / глупых компонентов

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

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

Feed/ // container directory
--index.js // the container component that is connected to Redux
--Wrapper.js // styled-components component
--FeedItem.js // stateless component that receives props from index
...

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

Дальнейшее чтение:

4. Всегда упаковывайте сторонние компоненты

Это сэкономит ваше время и количество нажатий клавиш! Когда мы только начинали, мы решили использовать готовый набор компонентов пользовательского интерфейса. Две недели спустя мы перешли на другой набор компонентов пользовательского интерфейса. Через месяц после этого мы решили создать собственные компоненты пользовательского интерфейса. А теперь представьте, если бы каждый раз, когда мы вносили такие изменения, нам приходилось просматривать каждый файл и заменять старые компоненты новыми. Мы сделали это в первый раз, когда поменяли комплекты интерфейса… больше никогда.

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

Это пример обернутого стороннего компонента:

import React from 'react';
import { Button } from 'third-party-library';
const WrappedButton = (props) => <Button {...props} />;
export default WrappedButton;

Подробнее:

5. Если вы используете redux-saga, изучите генераторы…

Когда мы впервые начали использовать redux-saga в приложении, я мог заставить все работать. Но как это работало мне намекало. С таким же успехом это могло быть колдовство. Это быстро привело к появлению побочных эффектов и непредсказуемому поведению (наряду с сильными головными болями).

Саги сложно осмыслить. Их еще труднее понять, когда вы не знаете, как работает функция генератора - это, по сути, функции генератора ES6.

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

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

Вот несколько ссылок, которые помогли мне понять саги:

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

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

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