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 г.