ReactJS: философия, области применения, требования к бэкенду и всё, что нужно знать о технологии сейчас

В этой статье мы собрали несколько своих материалов по ReactJS и смежным темам за последние 1,5 года, в которых говорили о преимуществах любимой и понятной нам технологии. Здесь есть главы как для общего ознакомления с React, так и главы технически насыщенные и сложные. Для более взвешенного решения, какой технологией пользоваться на своём проекте, поищите подобные статьи про конкурирующие с React фреймворки Vue и Angular.

Reaсt — это библиотека, отвечающая за создание пользовательского интерфейса сайта. Причём такого интерфейса, где есть не только текст, но и интерактивные элементы, динамика, разные события. Под интерактивными событиями мы понимаем возможность поставить лайк, отправить заполненную контактную форму, работать с картами, напичканными инфографикой, или с административной панелью в интернет-магазине, где у товара, корзины и процесса отправки платежа бывает несколько состояний.

Все эти элементы и состояния — это маленькие программы (или скрипты), разрабатываемые на языке JavaScript и исполняемые браузером пользователя. Когда пользователи делают что-то с элементами интерфейса, они запускают эти скрипты: браузер посылает запрос на сервер, сервер обрабатывает запрос и берёт из базы данных то, что нужно, чтобы пользователь увидел поставленный им лайк в соцсети, выбранные им товары в корзине интернет-магазина, наложенные эффекты в браузерных редакторах для работы с фотографиями, результаты теста и прочее в зависимости от задач приложения.

Чтобы разработка сайта с большим количеством JavaScript-кода шла быстрее и удобнее для разработчика, используют React.

React появился в 2013 году. Его придумали в компании Facebook* в процессе внедрения чата в свою социальную сеть. Чат должен был работать на всех страницах, но при этом не влиять и не попадать под влияние других элементов интерфейса.

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

Что-то похожее на Java, но не такое сложное. Претендентом на такой язык был даже Python, но, после череды переименований, под руководством Брендана Айка появился JavaScript.

Любая веб-страница, если уметь читать её код, — это объекты, как бы вложенные друг в друга. Например, страница состоит из области head для заголовка, стилей, размера шрифта и прочей технической информации, и области body для основного содержимого. Получается такое ветвящееся дерево из HTML и CSS-объектов, которое называется DOM (Document Object Model).

Для JavaScript структура DOM является интерфейсом, через который скрипты заставляют неподвижные HTML и CSS-объекты шевелиться.

Классический DOM не предусматривает создания динамических интерфейсов, поэтому исполняемый на страницах JavaScript замедляет её отрисовку. Но React сначала создаёт имитацию DOM (Virtual DOM), более лёгкую по сравнению с DOM, меняет в этой копии только те объекты, на которые влияют пользовательские действия, и накладывает эти изменения на реальный DOM.

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

React следует парадигме компонентно-ориентированного программирования, которая ввела в словарь разработчиков понятие компонента. Компонент — это JavaScript-функция или класс, которые можно написать один раз и по необходимости использовать снова при разработке интерфейса приложения. Есть также понятие «элементы», которое не следует путать с компонентами. Элементы — это результат компиляции языка JSX, с которым работает React, и работы метода React.createElement; после рендеринга внутри React элемент становится тем самым объектом в дереве DOM, который пользователь увидит на экране. Иначе говоря, элемент создаётся в Virtual DOM, а при рендеринге он переносится в стандартный DOM веб-приложения, чтобы стать кнопкой в интерфейсе приложения.

Разработчики говорят, что в React тесно связаны разметка и логика. Это значит, что данные о внешнем виде интерактивного элемента интерфейса и его изменениях в процессе работы с веб-приложением не разделяются по разным файлам, а хранятся внутри компонента. Этим и впечатляет разработчиков компонентный подход в React. Язык разметки JSX помогает им лучше ориентироваться в UI, но разрабатывать на React можно и без него.

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

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

Компоненты следует создавать по принципу единственной ответственности: каждый должен отвечать за какую-то одну задачу. Если компонент всё же выполняет несколько задач, то лучше разбивать его на подкомпоненты. Сложная интерактивная форма с множеством полей и кнопок будет одним большим компонентом, а подкомпонентами будет каждое поле и каждая кнопка. Если несколько компонентов можно объединить в один большой прямоугольник, то он будет родительским компонентом, а содержащиеся в нём — дочерними.

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

Компонент:

• может быть функцией или классом, который принимает в себя какие-то данные и возвращает элементы, другие компоненты, строки и числа;
• работает по жизненному циклу;
• содержит в себе разметку;
• может изменять своё состояние (мутабелен);
• работает с React hooks — JavaScript-функциями, с помощью которых можно «подцепиться» к состоянию и методам жизненного цикла React из функциональных компонентов.

Элемент:

• это то, что всегда возвращается компонентами;
• это представление объекта в узле DOM;
• создаётся и не изменяется (иммутабелен);
• не работает с React hooks, потому что не изменяется.

Какое влияние компонентный подход библиотеки React оказывает на время разработчиков и бюджет вашего проекта:

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

Если нагрузка снимается с сервера, то она возрастает на стороне пользователя. Но статистика говорит, что у клиентских машин достаточно оперативной памяти для отрисовки страниц сайта на React в браузере.

Однако, если нужно получить максимально быстрый отклик от интерфейса, то используют подход SPA (Single Page Application). Его суть в том, что весь сайт — это одна страница, которую React постоянно перерисовывает — но не целиком.

В простом приложении для перехода со страницы на страницу пользователь делает к ней запрос на сервер, и сервер возвращает разметку, стили и файлы скриптов (то есть HTML, CSS и JavaScript). В случае SPA пользователь, переходя между разделами сайта, формально находится на одной и той же странице, но файлы скриптов и стили у него уже есть — остаётся дотянуть то, чего не хватает. Например, если шапка сайта одинаковая на каждой странице, а поменялся только какой-то блок страницы, то не нужно заново отрисовывать шапку.

Это экономит ресурсы и даёт более быстрый и отзывчивый интерфейс. Владельцам интернет-магазина нужно дорожить каждым мигом: есть шанс потерять клиента, если он ждёт 5-10 секунд после нажатия кнопки.

Поисковая оптимизация — слабая часть React-приложений. Вред для бизнеса от плохого SEO понятен: если ваш сайт не видят поисковики, то его не существует.

Для решения проблемы существует подход Server Side Rendering. Часть работы по отрисовке сайтов происходит на сервере (да, всё правильно, мы пришли к тому же, от чего пытались уйти), за что отвечает NextJS, фреймворк на базе React. При запросе от браузера сервер отдаёт заранее отрисованную страницу — готовую и как будто собранную. Потом эти элементы начинают вести себя как React-компоненты на стороне клиента. Таким образом, то, что видит пользователь, частично отрисовано на сервере, а остальное собирается в браузере. Иначе страницы сайта индексировались бы хуже.

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

Серверную часть приложения, в основном, пишут на языках PHP, Python, Ruby, C# и JavaScript. Справедливости ради скажем, что ни один из этих языков не был задуман как язык строго для одной среды — даже популярнейший в бэкенд-разработке PHP. Все они в разной степени годятся для разработки всего подряд: десктопных приложений, видеоплееров, текстовых редакторов и т. д. Но именно JavaScript изначально разрабатывался как язык для браузера, чтобы программировать взаимодействие пользователя с элементами интерфейса, но потом и он стал языком общего назначения благодаря NodeJS, среде для выполнения JavaScript-кода на сервере, в которой JavaScript превращается в универсальный машинный код.

С одной стороны, для эффективной работы с JavaScript существует стек MERN. Его название сложилось из начальных букв технологий, которые в него входят: базы данных MongoDB, фреймворка ExpressJS, собственно, ReactJS и среды для выполнения JAvaScript-кода на сервере NodeJS. Но с другой стороны, если у приложения клиентская и серверная части работают отдельно, то основное, что стоит определить — это как они будут общаться.

И здесь пора поговорить о чистой архитектуре. Для приложения с чистой архитектурой характерны:

• читабельный код. Пришедший на проект новобранец быстро в него вольётся, если увидит, что здесь используются знакомые ему практики;
• расширяемость. Даже в разгар процесса можно что-то изменить или добавить к тому, что уже было сделано;
• оптимизированная работа. Быстрое приложение приятнее медленного.

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

Какое значение имеет чистота архитектуры, когда мы говорим о разработке React-приложений?

Клиент и сервер (фронтенд и бэкенд соответственно) — это хоть и связанные, но разные приложения. Для фронтенда не так важны детали реализации бэкенда, как важен API (Application Programming Interface) — набор соглашений между клиентской и серверной частью об использовании определённых процедур для выполнения операций с определённым результатом в конце. Достигнув этого соглашения, их можно разделить и разрабатывать параллельно. Это одна из особенностей разработки на React.

В погоне за чистотой архитектуры бэкенд и фронтенд часто разделяют, потому что с ростом монолитного приложения поддерживать его становится всё сложнее. Возьмём тот же Drupal CMS, где обе эти части близко связаны. Скажем, на сайте есть форма, в которой надо что-то поменять, и велика вероятность, что разработчику нужно менять в настройках CMS отображение формы. Если разработать пользовательский интерфейс на React, то все нужные изменения в форме пройдут на клиентской стороне, без привлечения сервера. То же самое на бэкенде. Например, есть интернет-магазин, в котором изменилась логика начисления скидки или доставки. При разделённом фронтенде и бэкенде разработчик делает изменения на бэкенде, но отображения это может не касаться.

Итак, на проектах с React важен используемый архитектурный стиль API, по которому бэкенд-приложение общается с фронтенд-приложением. Мы поговорим про GraphQL, потому что знакомы с технологией и считаем её наиболее подходящей для React-приложений. Кто-то говорит, что это язык запросов для API-интерфейсов и среда, в которой они выполняются. Кто-то (например, мы) называет это описанием стандарта, которое можно реализовать разными способами. В любом случае, это следующая после SOAP и REST API ступень эволюции клиент-серверного общения и наш личный фаворит.

На фоне своих предшественников у GraphQL ещё более конкретные и экономные запросы к серверу. Когда на проекте много ресурсов и используется архитектурный стиль REST API, клиент обращается к нескольким точкам входа (endpoints), в то время как через GraphQL клиент отправляет запросы только через одну точку входа и формулирует, какие данные и в каком формате он хочет получить. Например, ваше React-приложение — агрегатор магазинов электронной техники. По специальным правилам, которые предписывает стандарт GraphQL, клиент отправляет серверу запрос данных в формате JSON о модели телефона и магазинах, в которых она продаётся. Если сервер правильным образом написан и сконфигурирован, то он поймёт запрос и пришлёт всё, что нужно. Следовательно, главная фишка GraphQL в том, что клиент сам может выбрать, какие данные ему нужны от сервера.

У GraphQL есть три типа запросов:

• query — запрос на получение данных,
• mutation — запрос на обновление данных после каких-то операций типа создания заказа,
• subscription — автоматическое уведомление клиента через WebSocket-соединение о том, что произошли какие-то изменения, и данные на странице надо обновить.

Что такое WebSocket-соединение и чем оно может быть нам полезно? Большинство протоколов не держат двери для данных нараспашку: клиент посылает запрос, сервер отвечает — всё, соединение можно закрыть. Но для постоянного обмена данными был создан WebSocket, протокол на базе HTTP. Этот протокол, в отличие от соединения по обычному HTTP-протоколу, не закрываются после ответа сервера, и поэтому незаменим на таких проектах, как онлайн-игры, интернет-магазины, чаты и прочих, где клиент и сервер должны обмениваться данными постоянно. Разумеется, для создания интерактивных и высоконагруженных React-приложений он тоже подходит.

Преимущества GraphQL:

• не нужно создавать несколько REST-запросов. Чтобы извлечь данные, достаточно ввести один запрос — даже если данные лежат в разных источниках;
• не привязан к конкретной базе данных или механизму хранения;
• GraphQL использует строгую систему типов данных, определяющую различные форматы данных, используемых в приложении.

Так как GraphQL — это не конкретная разработка, а скорее стандарт, то нужен инструмент для его реализации. Один из способов реализации — библиотека управления состоянием Apollo, состоящая из двух библиотек: Apollo Client и Apollo Server.

Не обязательно, чтобы твой сервер с данными и бизнес-логикой был частью приложения. Сейчас популярностью пользуется паттерн Backend-for-Frontend (BBF), представленный компанией Soundcloud в 2015 году. Его суть в том, что бэкенд может быть написан на чём угодно и может отдавать данные как угодно, но они с фронтендом всё равно будут понимать друг друга, потому что на бэкенде GraphQL работает как отдельный сервис, забирающий данные с сервера и отдающий их клиентской стороне.

Представьте, что у вас старый проект с легаси, где клиент и сервер общаются через SOAP. С паттерном BBF не нужно переписывать весь бэкенд — достаточно лишь добавить прослойку на GraphQL. Что до новых приложений, то в них, разумеется, есть смысл использовать GraphQL сразу.

Подытожим этот длинный разговор о бэкенде. Использование React на клиенте не определяет выбор технологии для серверной части. Во-первых, обмен данными через WebSockets можно построить и на NodeJS, и на Python, и на C#. Во-вторых, хотя с фронтендом и бэкендом, написанными на JavaScript, ваш fullstack-разработчик и будет чувствовать себя на своём месте, метод Backend-for-Frontend тем и хорош, что позволяет сделать между клиентом и сервером прослойку на GraphQL и не задумываться о совместимости технологий с обеих сторон. Иными словами, используя ряд уже известных ноухау, бэкенд для React-приложения можно построить на всём, что популярно, что используется, что нравится вашей команде и с чем она умеет работать.

В чём преимущества приложений, написанных на React:

1. Снижается нагрузка на сервер и время разработки. Повышается производительность сайта: быстрее открываются страницы и отзывается на действия пользователей интерфейс. Если обычное веб-приложение на запрос от браузера возвращает ему HTML-разметку с CSS, чтобы браузер отрисовал страницу, то в случае приложений на React браузер сначала скачивает набор скриптов, которые выполняются на устройстве пользователя. Это снимает нагрузку с сервера и повышает производительность.

2. На React необязательно разрабатывать весь сайт, если динамичные блоки занимают лишь его малую часть. Пока статичные страницы работают как обычно, мы можем сделать на React конкретный блок и вставить скрипты так, чтобы они выполнялись только в нём. Есть компании, которые спустя годы переписывали свой продукт на React. Этот переход не обязательно делать сразу, но с точки зрения разработки это может оказаться удобнее.

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

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

5. React подходит для разработки одностраничных приложений (Single Page Applications).

По состоянию на конец 2022 года React всё ещё на первых местах среди JavaScript-технологий для разработки фронтенда. Мы надеемся, наша статья помогла вам понять причины — мы сами разрабатываем несколько наших флагманских проектов с применением этой библиотеки и знаем, о чём говорим. Но если вы нашли изъян или хотите нас чем-то дополнить, мы ждём ваших комментариев.

_____

*соцсеть признана экстремистской в России