Фронтенд разработка еще никогда не была такой сложной и увлекательной, как сегодня. Новые инструменты, библиотеки, фреймворки и плагины появляются через день. Их становится так много, что не успеваешь им обучаться.
Крайне важно, чтобы сегодняшние разработчики руководствовались этой эволюцией внешнего интерфейса, учились легко ориентироваться в экосистеме и максимально быстро доставляли код своим пользователям. В этой статье мы дадим несколько советов касательно того, как и когда использовать те или иные инструментарии.
Если вы знакомы с разработкой внешнего интерфейса и постоянно следите за последними разработками, то это руководство, вероятно, будет для вас не очень полезным. Оно больше ориентировано на новичков, только приступающим к работе с фронтендом.
Одностраничные приложения (SPA)
В наши дни веб-разработчики называют свои продукты веб-приложениями, а не веб-сайтами. Хотя между этими двумя терминами нет строгой разницы, веб-приложения, как правило, очень интерактивны и динамичны, что позволяет пользователю выполнять различные действия и получать на них ответ.
Традиционно браузер получает HTML с сервера и отображает его. Когда пользователь переходит на другой URL, требуется полное обновление страницы, и сервер отправляет новый HTML для новой страницы. Это называется рендерингом на стороне сервера.
Однако в современных SPA, вместо этого используется рендеринг на стороне клиента. Браузер загружает начальную страницу с сервера вместе со скриптами (фреймворками, библиотеками, кодом приложения) и таблицами стилей, необходимыми для всего приложения. Когда пользователь переходит на другие страницы, обновление страницы не запускается. URL-адрес страницы обновляется с помощью API истории HTML5. Новые данные, необходимые для новой страницы, обычно в формате JSON, извлекаются браузером через запросы AJAX на сервер. Затем SPA динамически обновляет страницу данными через JavaScript, которые он уже загрузил при начальной загрузке страницы. Эта модель похожа на работу нативных мобильных приложений.
Преимущества:
- Приложение выглядит более отзывчивым, и пользователи не видят разрыва между переходами по страницам из-за полного обновления страницы;
- На сервер поступает меньше HTTP-запросов, поскольку одни и те же ресурсы не нужно загружать снова для каждой загрузки страницы;
- Четкое разделение проблем между клиентом и сервером. Вы легко можете создавать новых клиентов для разных платформ (например, для мобильных устройств, чат-ботов, умных часов) без необходимости изменять код сервера. Вы также можете изменить технологический стек на клиенте и сервере независимо от того, нужен API-контракт или нет.
Недостатки:
- Более тяжелая начальная загрузка страницы из-за загрузки инфраструктуры, кода приложения и ресурсов, необходимых для нескольких страниц;
- На вашем сервере необходимо выполнить дополнительный шаг, который заключается в том, чтобы настроить его так, чтобы он направлял все запросы к одной точке входа и позволял выполнять оттуда маршрутизацию на стороне клиента;
- Соглашения SPA основаны на JavaScript для отображения контента, но не все поисковые системы выполняют JavaScript во время сканирования, и они могут видеть пустой контент на вашей странице. Это может случайно навредить SEO-части вашего приложения.
В то время как традиционные приложения на стороне сервера по-прежнему являются жизнеспособным вариантом, четкое разделение на клиент-сервер лучше масштабируется для более крупных инженерных групп, поскольку код клиента и сервера можно разрабатывать и выпускать независимо.
Поскольку веб-разработчики теперь создают приложения, а не страницы, организация клиентского JavaScript становится все более важной. На отрисованных страницах на стороне сервера обычно используют фрагменты jQuery для добавления интерактивности пользователя на каждую страницу. Однако при создании больших приложений просто jQuery недостаточно. В конце концов, jQuery – это, прежде всего, библиотека для манипулирования DOM, а не полноценный фреймворк; он не определяет четкую структуру и организацию вашего приложения.
Пользовательский интерфейс – React
Если какой-либо проект JavaScript в последние годы штурмует экосистему внешнего интерфейса, то это React. React – это библиотека, созданная руками специалистов из компании Facebook. В React разработчики пишут компоненты для своего веб-интерфейса и составляют их вместе.
React рождает много радикальных идей и побуждает разработчиков переосмыслить лучшие практики. В течение многих лет веб-разработчиков учили, что было бы неплохо писать HTML, JavaScript и CSS по отдельности. React делает прямо противоположное и рекомендует вам вместо этого писать HTML и CSS на своем JavaScript. Сначала это звучит как сумасшедшая идея, но после того, как она опробована, она на самом деле не так странна, как кажется на первый взгляд. Причина в том, что сцена разработки внешнего интерфейса смещается в сторону парадигмы разработки на основе компонентов. Особенности React:
- Декларативность. Вы описываете, что вы хотите видеть по вашему мнению, а не как этого добиться. В дни jQuery разработчикам приходилось придумывать серию шагов для манипулирования DOM для перехода из одного состояния приложения в другое. В React вы просто изменяете состояние внутри компонента, и представление обновляется в соответствии с состоянием. Также легко определить, как будет выглядеть компонент, просто взглянув на разметку в методе render().
- Функциональность. В большинстве случаев компонент React определяется props (внешние параметры) и state (внутренние данные). Для одних и тех же props и state воспроизводится один и тот же параметр view. Чистые функции легко тестируются, и то же самое касается функциональных компонентов. Тестирование в React стало проще, потому что интерфейсы компонента четко определены, и вы можете протестировать компонент, предоставив ему различные props и state, сравнив визуализированный вывод.
- Простота обучения. Обучиться React довольно просто. Поверхность React API относительно мала, так что у вас будет всего несколько API для изучения, и они меняются не часто. Сообщество React является одним из крупнейших, и наряду с этим появляется динамичная экосистема инструментов, компонентов пользовательского интерфейса с открытым исходным кодом и множество отличных ресурсов в интернете, которые помогут вам начать изучение React.
Административное управление состояниями – Flux/Redux
По мере того, как ваше приложение становится больше, вы можете обнаружить, что его структура становится немного запутанной. Компоненты во всем приложении, наверное, должны совместно использовать и отображать общие данные, но в React нет элегантного способа справиться с этим. В конце концов, React – это просто слой представления, он не определяет, как вы структурируете другие слои вашего приложения, такие как модель и контроллер, в традиционных парадигмах MVC. Чтобы решить эту проблему, Facebook изобрела Flux, архитектуру приложения, которая дополняет компоненты составного представления React, используя однонаправленный поток данных. Таким образом, шаблон потока имеет следующие характеристики:
- Однонаправленный поток данных – делает приложение более предсказуемым, поскольку обновления легко отслеживаются;
- Разделение проблем – каждая часть в архитектуре Flux имеет четкие обязанности и сильно отделена;
- Хорошее взаимодействие с декларативным программированием – хранилище может отправлять обновления в представление без указания способа перехода между представлениями.
Поскольку Flux сам по себе не является фреймворком, разработчики попытались придумать множество реализаций шаблона Flux. В конце концов, явным победителем стал Redux. Redux объединяет идеи из Flux, шаблона Command и архитектуры Elm и является де-факто библиотекой управления состоянием, которая используется разработчиками в React в наши дни. Его основные понятия:
- Состояние приложения описывается одним простым старым объектом JavaScript (POJO).
- Отправление действия (также POJO), чтобы изменить состояние.
- Reducer – это чистая функция, которая принимает текущее состояние и действие для создания нового состояния.