Привет, мир !!!
Есть одна удивительная вещь в человеческом поведении: регулярное выполнение одной крошечной полезной вещи заставляет наш разум и тело развивать мышечную память.
Примеры некоторых случаев мышечной памяти: печатать, не видя клавиатуры, по очереди идти по знакомым дорогам, погружаясь в собственные мысли, есть в темный и многое другое.
Точно так же, как мышечная память заставляет нас принимать решения, не обращая внимания, если мы каким-то образом развиваем эту мышечную память во время написания кода, это может принести удивительные преимущества нашей кодовой базе. Потому что тогда нам не нужно заботиться о мелочах. Мы можем полностью посвятить свое время решению сложной логики.
Вот некоторые преимущества передовой практики на кончиках пальцев:
1. Управляемый и поддерживаемый код
2. Приложение будет менее подвержено сбоям из-за нулевых значений.
3. Улучшено время загрузки
> 4. Сокращение времени отладки.
5. Последовательность в командной работе
Несколько месяцев назад я поделился несколькими плохими практиками в ReactJS. Если вы еще не проверяли их, посмотрите, потому что эта статья является продолжением той же.
Итак, вот это офигенность
1. Импорт ненужных модулей
Если мы не обращаем внимания на то, что мы импортируем, то мы без необходимости увеличиваем размер пакета нашего приложения.
Рассмотрим ниже фрагмент кода.
Здесь я импортирую только метод get lodash, но этот метод не является хорошим способом импортировать что-либо.
В этом методе, хотя я использую только метод get, но за кулисами импортируются все методы. Что, в свою очередь, увеличит размер нашего пакета.
Мы всегда должны проверять, как мы импортируем библиотеки и функции в наш код.
Рекомендуемый способ — импортировать только те вещи, которые нам нужны, и этого можно добиться, используя импорт по умолчанию:
Вот сравнение размера с обоими стилями импорта:
2. Ленивые при работе с HTTP-запросами
Рассмотрим следующий фрагмент. У него есть одна кнопка, при нажатии на которую мы извлекаем данные и показываем их в пользовательском интерфейсе.
Демо:
Поверьте мне, я видел такой код в отраслевых приложениях с тысячами еженедельных пользователей.
В чем проблема в приведенном выше коде?
Проблема 1: нет индикатора загрузки, указывающего на то, что что-то происходит.
Проблема 2. Нет механизма обработки ошибок. Если обещание отклонено, пользователь не сможет узнать, что происходит что-то плохое, и он может продолжить попытки и в конечном итоге покинуть приложение с плохим опытом.
Так что имейте это в виду, всякий раз, когда вы делаете какой-либо HTTP-запрос. Убедитесь, что пользователь ожидает этого в пользовательском интерфейсе, затем покажите что-нибудь и никогда не пропускайте обработку ошибок.
Фиксированный код:
Демо с успехом и неудачей
4. Не использовать силу хуков
В моем предыдущем примере я сделал HTTP-запрос в компоненте. Теперь предположим, что у нас есть 100 компонентов, которым нужна одинаковая реализация.
Например, получить данные, показать индикатор во время выборки, после завершения выборки скрыть индикатор и показать данные, а если возникает ошибка, показать соответствующее сообщение и способ реагирования на ошибку, если это применимо.
Теперь некоторые могут думать о написании одного и того же кода снова и снова. Но это не лучший способ.
Мы можем легко решить эту проблему с помощью хуков. Одной из основных целей введения хуков было отделение логики от компонента.
Чтобы решить эту проблему, мы можем создать собственный хук. Чья работа будет:
1. Сделать HTTP-запрос
2. Управление состоянием загрузки
3. Управление состоянием успешного выполнения
4. Управление ошибкой
5. Управление состоянием данных в случай успеха
Давайте посмотрим на это в коде:
И в действии:
4. Несоблюдение какой-либо структуры каталогов
В настоящее время мы пишем меньше кода по сравнению с использованием готовых методов из библиотек. Благодаря этому организация вещей становится неотъемлемой частью любого проекта.
Организация вещей всегда лучше, она делает вещи доступными и экономит время просмотра.
Есть много хороших ресурсов для хорошей структуры каталогов. Я перечисляю некоторые из них, вы можете выбрать любой из них в зависимости от ваших личных предпочтений и потребностей:
5. Не разбивать большой компонент на более мелкие
Я видел, как многие разработчики пишут код для всего экрана вместо того, чтобы создавать более мелкие компоненты. Причина, по которой они говорят об этом, заключается в том, что они не хотят управлять большим количеством файлов, вместо этого им нужен большой файл.
Лично мне такой подход совсем не нравится. Сам React говорит, что это библиотека на основе компонентов. Если мы работаем в React, мы должны думать в стиле React.
Мы должны разбить наш экран на компоненты.
Давайте разберемся в этом на примере. Здесь я прикрепляю скриншот официального документа React. И я даю как хороший, так и плохой способ оформления экрана:
Вперед, попробуйте сами, прежде чем увидеть реальную поломку.
.
.
.
При таком подходе мы действительно получим тот пользовательский интерфейс, который хотели, а также сможем сэкономить несколько минут нашей жизни, не создавая повторно используемые компоненты.
Недостатком этого подхода является то, что если нам нужно использовать одну и ту же кнопку и текстовый компонент, нам придется писать дублированный код CSS и JSX. Что в свою очередь занимает много времени и увеличивает размер кода.
Способ React сделать это следующим образом:
У нас есть компонент Text, который позаботится о стилях, контролируемых реквизитами. Точно так же пользовательский интерфейс для компонента Button управляется реквизитами.
6. Спагетти-код в повторно используемых компонентах
Как правило, в нашем приложении для реагирования мы создаем несколько повторно используемых компонентов, которые используются во всем проекте. Некоторыми хорошими примерами повторно используемых компонентов являются Button, Text, Checkbox.
Ошибка, которую мы делаем в повторно используемом компоненте, заключается в том, что мы импортируем другой повторно используемый компонент, чтобы сделать повторно используемый компонент.
Рассмотрим этот фрагмент кода:
В приведенном выше коде у меня есть повторно используемый компонент Button, но внутри него я использую компонент Text.
Проблема с этим подходом заключается в том, что если мне нужно использовать этот компонент Button в любом из моих других проектов или если я хочу поделиться им с другими разработчиками, то Я также должен поделиться компонентом Text.
Здесь компонент Button зависит от Text Component.
Мы должны избегать таких случаев. Вышеупомянутый компонент может быть реорганизован как:
Предостережение: при такой практике код будет дублироваться. Так что мы должны принять решение здесь. Если ваш повторно используемый компонент специфичен для одного проекта, вам не нужно беспокоиться о зависимостях.
7. Не выполнять проверки типа пропса
Большинство ошибок в веб-приложении возникает из-за отсутствия проверки на null или передачи неподходящих типов данных. Все это происходит из-за прощающей природы JavaScript, поскольку это язык с нестрогим типом.
Частые сбои могут повлиять на удержание пользователей на любом веб-сайте.
Для компонента React мы можем решить эту проблему двумя способами. Первый использует TypeScript. Если мы используем машинописный текст, мы можем использовать interfaces для определения типов свойств. Так что только ожидаемый тип данных назначается переменной.
Другой способ решить эту проблему — использовать популярный пакет под названием proptypes.
8. Не использовать границы ошибок
Границы ошибок помогают нам изящно обрабатывать ошибки. Большинство из них заключают все наше приложение React в одну границу ошибки и забывают об этом.
Недостатком этого является то, что если в какой-либо части вашего приложения произойдет сбой, то все приложение станет бесполезным.
Чтобы справиться с такими случаями, разбейте приложение на такие части, как:
1. NavBar
2. SideBar
3. Content
4. Footer
5. Диалоги
6. Подсказки
И для таких компонентов заворачивайте их в отдельные ErrorBoundaries. Так что, если в SideBar произойдет сбой, остальную часть приложения можно будет использовать.
9. Не разделять код
Разделение кода помогает нам уменьшить размер пакета при первоначальном запуске, а также во время навигации пользователя между страницами.
Следствием его неиспользования является то, что все будет загружено в браузер, как только пользователь нажмет URL-адрес. И есть вероятность, что 80% загруженных вещей не используются.
Типы разделения кода:
1. Уровень маршрута
2. Уровень компонента
3. Ленивая загрузка стороннего импорта.
10. Несоблюдение правил именования компонентов
Пока мы находимся на этапе обучения, мы часто совершаем эту ошибку.
Мы даем имена файлов компонентам так, как хотим, и не придерживаемся никаких соглашений.
Я предлагаю две рекомендуемые практики для соглашения об именах компонентов:
- Имена компонентов должны начинаться с заглавных букв. Без тире и подчеркивания. Разделяйте слова другой заглавной буквой.
- создать папку, имя этой папки будет строчными буквами. И внутри этой папки создаем index.js. И мы пишем всю логику нашего компонента внутри этого индексного файла.
11. Запись бизнес-логики в файл компонента
Как правило, в большинстве реагирующих приложений нам приходится писать некоторый код, чтобы получить определенную форму объектов или вычислить некоторые значения.
Обычно люди пишут все в файл компонента. Что является плохой практикой. Файл компонента — это представление пользовательского интерфейса для вашего кода, вот и все. Мы всегда должны избегать написания в нем какой-либо бизнес-логики.
У нас должен быть отдельный файл utility, содержащий все часто используемые методы, а также выполняющий некоторые вычисления.
У нас может быть столько служебных файлов, сколько нужно, с описательными именами.
12. Не использовать логи в приложении
Это совершенно необязательное предложение. Это не обязательно, но хорошо иметь предложение.
В каждое реагирующее приложение у нас должно быть встроено какое-то log отслеживание и отслеживание событий. Несколько примеров — MixPanel, LogEntries, Google Analytics, LogRocket.
Преимущество этого заключается в том, что это поможет нам увидеть поведение пользователей, какая часть приложения широко используется пользователями, чтобы мы могли работать над этой конкретной областью.< br /> Это также поможет выявлять ошибки. Если у какого-либо пользователя возникла проблема, мы можем проверить журналы для этого конкретного пользователя и легко отследить проблему.
Это также поможет вам узнать, из каких разных источников и стран пользователи посещают ваш веб-сайт.
13. сверление подпорок
Сверление реквизитов означает прохождение большого количества реквизитов через компонент и получение их в дочерних компонентах.
Недостатки передачи большого количества реквизитов:
1. Сложно управлять компонентом позже (через несколько месяцев)
2. Некоторые дочерние компоненты могут даже не использовать реквизит, но при изменении реквизита они также будут повторно оказывать.
3. Сложный и большой файл компонента.
Что мы можем сделать, чтобы этого избежать: 1. Используйте функциональные возможности контекста поставщика. С хуками их проще использовать
2. С введением хуков вместо использования mapDispatch и mapStateToProps с HOC мы можем использовать хуки useDispatch и useSelector.
Благодаря этому мы можем извлечь требуемое состояние редукции по компонентам отдельно.
Короче говоря, мы получим только то, что хотим.
14. выполнение одного и того же кода при многократном повторном рендеринге
Рассмотрим следующий фрагмент кода
В приведенном выше коде у нас есть простая логика для фильтрации массива для even и odds.
Теперь давайте посмотрим на поведение в браузере. Обратите внимание на логи консоли.
Основная проблема заключается в том, что при каждом изменении состояния логика вычислений выполняется снова и снова. Для меньшего приложения это может не вызвать проблемы, но по мере роста размера приложения и введения сложной логики для большего набора данных наше приложение определенно пострадает.
Решение для таких сценариев заключается в кэшировании такого результата. И React предоставьте нам hook для этого. Мы можем легко memoize получить результат, используя хук useMemo.
И если мы можем пересчитать логику на основе любой переменной состояния, то просто передаем эту переменную в массив зависимостей. (В нашем случае я передал его как пустой массив)
15. использование устаревшего кода JS для доступа к элементам DOM
React — это декларативная библиотека пользовательского интерфейса.
Он имеет тенденцию скрывать все операции с домом низкого уровня. Но может быть бесчисленное количество случаев, когда нам нужно получить доступ к элементам dom.
Иногда мы используем традиционный код document.getElementById() для доступа к элементу.
Это допустимо, когда мы работаем в традиционном JS. Но не в реакции. хотя он будет работать все время.
В React рекомендуемый способ доступа к элементам DOM — использовать useRef .
И если каким-то образом использование ref не решает задачу, вы можете использовать querySelector из querySelectorAll, что быстрее, чем document.getElementById. Единственный недостаток использования метода querySelector заключается в том, что они возвращают копию cached элемента DOM, а это означает, что если DOM будет изменен, то querySelector все равно вернет старый кэшированный элемент DOM. Так что имейте это в виду при использовании этого метода.
