1. Оптимизация React с самого начала
2. Рендеринг на стороне сервера для SEO
3. Встроенные стили и импорт CSS
4. Вложенный троичный оператор
5. Замыкания в реакции
6. Заключение

На данный момент сложно утверждать, что React является одной из самых любимых библиотек на планете. React вызывает огромный интерес, и новые разработчики склоняются к платформе благодаря подходу, ориентированному на пользовательский интерфейс. И хотя и библиотека, и вся экосистема React стали зрелыми за эти годы, есть определенные случаи, когда вы задаетесь вопросом: «Каков правильный способ сделать это, точно?»

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

В этой статье я опишу 5 общепринятых методов разработки, которых вы можете избежать при использовании React. Естественно, я объясню, почему я считаю эту практику предотвратимой, и предложу альтернативные подходы, которые позволят вам выполнить то же самое.

Оптимизация React с самого начала

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

Зачем?

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

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

Представьте, что у вас есть дерево, которое выглядит так:

Представьте, что приложение получает новые данные и необходимо обновить следующие узлы:

React обычно завершает повторное рендеринг всего поддерева вместо рендеринга только соответствующих узлов:

Когда состояние изменяется в компонентах высшего порядка, все компоненты ниже этого переопределяются. Это поведение по умолчанию, и это нормально для небольших приложений. По мере роста приложения вы должны рассмотреть возможность измерения фактической производительности с помощью Chrome Profiling Tools. Инструмент даст вам точную информацию о времени, потраченном на нежелательные рендеры. Если числа значительны, вы можете оптимизировать время рендеринга, добавив хук shouldComponentUpdate в свой компонент.

Хук срабатывает до начала процесса повторного рендеринга и по умолчанию возвращает true:

Когда он возвращает true, алгоритм сравнения React вступает во владение и повторно отображает все поддерево. Этого можно избежать, добавив логику сравнения в shouldComponentUpdate и обновляя логику только после изменения соответствующих реквизитов .

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

Помимо этого, существуют определенные приемы оптимизации, не связанные с React, которые обычно пропускают разработчики, но они влияют на производительность приложения.

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

1. Неоптимизированные изображения. Если вы работаете с динамическими изображениями, при работе с изображениями необходимо учитывать свои возможности. Изображения с огромными размерами файлов могут создать у пользователя впечатление, что приложение работает медленно. Сожмите изображения перед тем, как отправить их на сервер или использовать динамическая обработка изображений решение вместо. Мне лично нравится Cloudinary для оптимизации реагирующих изображений, потому что у него есть собственная библиотека реагирования, но вместо этого вы можете использовать Amazon S3 или Firebase.
2. Несжатые файлы сборки - Gzipping файлы сборки (bundle.js) могут значительно уменьшить размер файла. Вам нужно будет внести изменения в конфигурацию веб-сервера. Webpack имеет плагин сжатия gzip, известный как Сжатие-WebPack-плагин , Вы можете использовать эту технику для генерации bundle.js.gz во время сборки.

Рендеринг на стороне сервера для SEO

Несмотря на то, что одностраничные приложения просто великолепны, есть еще две проблемы, которые им приписывают.

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

Вот где пригодится техника рендеринга на стороне сервера. В SSR содержимое JavaScript отображается с сервера изначально. После первоначального рендеринга клиентский скрипт вступает во владение, и он работает как обычный SPA. Сложность и стоимость установки традиционного SSR выше, потому что вам нужно использовать сервер Node / Express.

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

Вот выдержка из блога для веб-мастеров в октябре 2015 года.

Однако, если вы делаете это, чтобы улучшить начальную скорость рендеринга, вам следует попробовать более простую реализацию SSR, используя такую ​​библиотеку, как Next.js. Next экономит ваше время, которое вы бы потратили на настройку сервера Node / Express.

Встроенные стили и импорт CSS

Работая с React, я лично пробовал разные идеи стилей, чтобы найти новые способы внедрения стилей в компоненты React. Традиционный подход CSS-in-CSS, существующий десятилетиями, работает с компонентами React. Все ваши таблицы стилей будут помещены в каталог таблиц стилей, и вы сможете импортировать необходимый CSS в ваш компонент.

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

Различные другие подходы практикуются, чтобы объединить код CSS и JS в один файл. Inline Style, пожалуй, самый популярный среди них.

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

Вот где CSS-in-JSS пригодится, а встроенные стили не совсем CSS-in-JSS. Код ниже демонстрирует концепцию с использованием styled-компонентов.

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

Новый тег <style> добавляется в начало DOM, и в отличие от встроенных стилей, здесь создаются настоящие стили CSS. Итак, все, что работает в CSS, работает и в стилизованных компонентах. Кроме того, этот метод улучшает CSS, улучшает читабельность и вписывается в архитектуру компонентов. С помощью библиотеки styled-components вы также получаете поддержку SASS, которая включена в библиотеку.

Вложенный троичный оператор

Тернарные операторы популярны в React. Это мой оператор перехода для создания условных операторов, и он прекрасно работает внутри метода render (). Например, они помогают вам отображать элементы как встроенные в примере ниже, я использовал его для отображения статуса входа в систему.

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

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

Но хорошо то, что у вас есть много альтернатив, из которых вы можете выбирать. Вы можете использовать плагин babel, такой как JSX Control Statements, который расширяет JSX, чтобы включать компоненты для условных операторов и циклов.

Есть еще один популярный метод, называемый iify (IIFE - выражения с немедленным вызовом функций). Это анонимная функция, которая вызывается сразу после их определения.

Мы обернули функцию в пару круглых скобок, чтобы сделать анонимную функцию выражением функции. Этот шаблон популярен в JavaScript по многим причинам. Но в React мы можем поместить все операторы if / else внутри функции и вернуть все, что мы хотим отобразить.

Вот пример, который демонстрирует, как мы собираемся использовать IFFE в React.

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

Замыкания в реакции

Замыкания - это внутренние функции, которые имеют доступ к переменным и параметрам внешней функции. Замыкания повсюду в JavaScript, и вы, вероятно, использовали его, даже если вы еще не осознали.

Но когда вы используете замыкания внутри метода render (), это на самом деле плохо. Каждый раз, когда отображается компонент SayHi, создается новая анонимная функция, которая передается в компонент Button. Хотя реквизиты не изменились, <Button /> будет вынужден повторно выполнить рендеринг. Как упоминалось ранее, потерянные рендеры могут напрямую влиять на производительность.

Вместо этого замените замыкания методом класса. Методы класса более читабельны и их легко отлаживать.

Заключение

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

Что вы думаете о React и лучших практиках в React? Поделитесь ими в комментариях.