React довольно легко выучить, если вы знаете JavaScript, однако довольно легко потерять контроль над своим проектом или просто все испортить, когда он масштабируется или готовится к рефакторингу или переписыванию. Я поделюсь некоторыми советами, которые буквально спасли мне жизнь… и кучу времени😇. Давайте погрузимся в это!

Совет 1: (Использование контейнеров)

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

Этот компонент извлекает новости и отображает пользовательский интерфейс для выбранных новых элементов.

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

Вместо того, чтобы весь наш код был просто панелью инструментов, мы можем разделить его на DashboardContainer и Dashboard. НЕ необязательно называть ваши контейнеры с помощью Container, однако это хорошее соглашение об именах, как это делается с контроллерами в MVC, например: UsersController.

DashboardContainer.jsx

Теперь ваш компонент панели мониторинга будет выглядеть так:

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

Совет 2: (Опрятный мужской реквизит😂)

Я дал этому совету такое нелепое название, потому что обнаружил его, когда пытался украсить свой код и сократить количество строк. Что включает в себя все это? Давайте взглянем. В приведенном выше совете мы передавали реквизит следующим образом:

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

Чисто, просто и очень читабельно😊

Совет 3: (Границы ошибки)

Согласно react docs, границы ошибок — это компоненты React, которые перехватывают ошибки JavaScript в любом месте своего дочернего дерева компонентов, регистрируют эти ошибки и отображают резервный пользовательский интерфейс вместо дерева компонентов, которое потерпело крах. Границы ошибок перехватывают ошибки во время рендеринга, в методах жизненного цикла и в конструкторах всего дерева под ними.

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

И оберните компонент, который вы хотите «защитить»

Это все. Вы можете ознакомиться с демонстрацией документов здесь.

Совет 4: (Выбор ваших библиотек)

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

Одна проблема, с которой я всегда сталкивался, заключается в том, что другие библиотеки обычно не вписываются в ваше приложение для реагирования, требуют большого количества стандартного кода или просто имеют эти странные операции😓 Redux отвечает всем этим критериям, кстати😓

Однако есть и хорошие новости: обычно всегда есть более легкий/меньший вариант, если хорошо поискать. Например, большинству проектов не нужны все функции редукса, только глобальное состояние, может быть редукторы, сеттер и геттер😅 Вы можете попробовать такие библиотеки, как Zustand, Reactn и многоцелевой React Query.

Если вам нужна более простая маршрутизация, вы также можете попробовать Glass Router, который использует более дружественный подход ко всему бизнесу маршрутизации.

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

Совет 5: (Относительный импорт)

Это относится к пользователям CRA

Обычно у нас есть разные каталоги для активов, представлений и всего того, что есть в нашем приложении. Обычно это приводит к неудобному импорту с ../../... Для этого есть куча решений, однако наиболее часто используемым, который я также предпочитаю, является перенастройка webpack для использования относительных путей: вместо ../../assets у нас может быть @/assets

настраивать

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

yarn add react-app-rewired customize-cra

Оттуда мы создаем файл config-overrides.js и выгружаем этот код:

Оттуда мы переходим к нашему разделу скриптов package.json и заменяем react-scripts на react-app-rewired вот так:

Вот и все для пользователей CRA + JS!

Если вы используете TypeScript с CRA, вам нужно добавить следующее, чтобы компилятор не кричал на вас за использование @ в вашем импорте.

Создайте новый файл, например tsconfig.base.json, в корне вашего проекта (на том же уровне, что и ваш package.json) и добавьте следующее:

Мы не добавляем это в основной tsconfig.json, потому что TypeScript перепишет tsconfig.json и выдаст эту ошибку:

The following changes are being made to your tsconfig.json file: - compilerOptions.paths must not be set (aliased imports are not supported)

Теперь, чтобы заставить это работать, вам просто нужно расширить это в вашем основном файле tsconfig.json:

Возможно, вам придется перезапустить редактор, чтобы это вступило в силу (только для пользователей TypeScript). Оттуда вы можете начать заменять весь свой неудобный импорт😇

Спасибо за чтение

Вот несколько советов и приемов, которые помогли мне ускорить мой рабочий процесс, сделать мой код аккуратным и, в основном, помочь в моих поисках лени😇

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

Первоначально опубликовано на https://dev.to 24 марта 2021 г.