Family Frontend Meetup #3
Автогенерация функций выборки данных с помощью Orval, переработка логики оптимизации изображений с заменой нашего компонента Picture, обновления Next.js 15 и небольшой бонус – наш топ библиотек, которые упростят поддержку и разработку вашего проекта, а также сэкономят время на его инициализацию.
Как использовать Orval для автоматизации разработки
Долгое время мы создавали функции выборки данных вручную. Внедрение Orval помогло автоматизировать этот процесс с полной типизацией данных payload и response.
В результате нам удалось:
- Сократить время на разработку;
- Убрать ненужные созвоны для постоянных уточнений по проектам;
- Привести документацию практически к идеальному состоянию.
Подробнее про опыт настройки Orval на примере реального проекта мы рассказали в этой статье.
Следующий шаг – автоматизировать создание документации, чтобы backend-специалисты больше не писали ее вручную. Но об этом они расскажут сами, когда все получится.
Что изменилось в логике работы с изображениями
Ранее для работы с изображениями мы написали компонент Picture, который включал:
- Выбор наиболее подходящего размера изображения;
- Ленивую подгрузку;
- Blur-версию изображения, которая отображается до загрузки.
Работа компонента была организована следующим образом: бэкенд отправлял структуру с разными размерами изображений, которые нужно использовать при определенных условиях. Например, в зависимости от ширины экрана, поддерживаемого браузером формата или количества пикселей на дюйм. Подробнее про компонент Picture можно прочесть здесь.
Пример структуры:
Со временем мы обнаружили в Picture следующие недостатки:
- Фронтенд-специалистам приходилось составлять размерную схему изображений для каждого компонента на сайте;
- Для хранения каждой сущности с графикой нужны были объемные структуры с ссылками на изображения, что увеличивало размер хранилища и осложняло работу с ним;
- Компонент использовал дополнительные библиотеки для работы с canvas из-за взаимодействия с форматом base83, необходимым для blur-версии изображения.
Эти ограничения не позволяли использовали нативные возможности основного фреймворка, с которым мы работаем. Например, оптимизацию изображений.
Поэтому мы решили отказаться от нашего компонента и в корне изменить логику работы.
Мы используем Next.js практически в каждом проекте. Он включает ленивую загрузку, умеет самостоятельно обрезать изображение под нужные размеры и дальше выбирает подходящий вариант. Новая логика предполагает, что мы просто отдаем Next.js изображение, а всё остальное фреймворк делает сам. Кратко опишем, как устроен этот процесс.
Чтобы не загружать заранее подготовленные для разных устройств (tablet, desktop, mobile и т.д.) изображения, мы будем использовать компонент next/image. Он использует параметры deviceSizes и imageSizes в конфигурации Next.js, что позволяет создавать массив изображений с разной шириной. Компонент автоматически генерирует ссылки, в которых с помощью параметра передаётся ширина из массива. Далее браузер делает запрос на сервер Next (обёртка над node.js), а тот уже сжимает изображение до нужного размера и возвращает браузеру.
В next/image можно указывать параметр sizes. Он подсказывает браузеру, какое изображение нужно загрузить в зависимости от ширины экрана. Это позволяет автоматически подбирать наиболее подходящее изображение для текущего устройства, тем самым улучшая производительность. В результате, загружаются картинки нужного размера, а не огромные файлы, которые потом сжимаются на клиенте с потерей качества.
Для создания кастомного загрузчика вместо стандартного, который по умолчанию предлагает Next.js, будем использовать сервис imgproxy. Он позволит быстрее и удобнее генерировать ссылки на изображения на основе заголовков параметров. Это дополнительно оптимизирует загрузку.
Сейчас мы работаем над пошаговой инструкцией для интеграции новой логики в проекты. Так что следите за обновлениями в блоге!
Что нового у Next.js 15
На каждом митапе мы проводим обзор обновлений для основных фреймворков, с которыми работаем.
Хотя Next.js 14 вышла относительно недавно, появилось обновление для React. Его упаковали в Next.js 15, хоть пока и с приставкой RC. Но даже здесь разработчики Vercel смогли нас удивить. Рассмотрим наиболее значимые изменения.
RC (Release Сandidate) – версия программы, которая почти готова к выпуску, но все еще может содержать несколько ошибок, и имеет статус между бета-версией и стабильной.
Частичный предварительный рендеринг (Partial Prerendering – PPR)
В настоящее время Next.js по умолчанию использует статический рендеринг. Только если вы не работаете с динамическими функциями, такими как cookies(), headers(), query-параметры и другими. В противном случае весь маршрут переходит на динамический рендеринг.
Частичный предварительный рендеринг (PPR) позволяет объединять статические и динамические компоненты в одном маршруте. Теперь можно работать с query-параметрами, не боясь навредить статическому рендерингу. Учитывая, что их используют довольно часто, обновление сделает разработку удобнее и улучшит производительность приложений.
Чтобы использовать новую опцию, добавьте ключ experimental.ppr со значением 'incremental' в конфигурацию в вашем next.config.js файле.
Также добавьте в верхнюю часть страницы или макета следующую директиву:
experimental_ppr будет применяться ко всем потомкам сегмента маршрута, включая вложенные макеты и страницы. Вам не нужно добавлять его в каждый файл, только в верхний сегмент маршрута.
С PPR вы можете обернуть любой динамический UI в границу Suspense. Когда поступает новый запрос, Next.js сначала обслуживает статическую HTML-оболочку, затем рендерит и передает динамические части в том же HTTP-запросе.
next/after: новый API для выполнения кода после завершения потоковой передачи ответа
Данная функция позволяет выполнять произвольный код на сервере после того, как HTTP-ответ был отправлен клиенту. С ее помощью вы сможете решать задачи, которые не требуют немедленного завершения до отправки ответа пользователю.
Раньше пользователю пришлось бы ждать ответ сервера, пока тот не обработает всю логику. С использованием next/after отложенные задачи могут быть выполнены в фоновом режиме, что позволяет серверу немедленно отвечать на запрос клиента.
Например, можно использовать данную функцию для отправки действий аналитики, сбора информации или выполнения ресурсоемких задач на фоне.
Опцию также надо включить в конфигурационный файл Next.js:
Пример использования функции может выглядеть так:
Другие изменения Next.js
- Fetch-запросы, GET-обработчики маршрутов и клиентская навигация больше не кэшируются по умолчанию;
- Произошло обновление дизайна create-next-app, и появился новый флаг для включения Turbopack в локальную разработку;
- Оптимизация импортирования внешних пакетов (optimizePackageImports) получила стабильную версию. Она направлена на сокращение размера бандла и улучшение производительности благодаря более эффективному управлению зависимостями и компиляцией.
Разработчики уверяют, что процесс будет дешевле, чем tree-shaking. Функция не новая, вся дополнительная информация находится здесь.
Полный список изменений в Next.js 15 можно изучить тут.
Для чего использовать комбинации линтеров
Бурную дискуссию на митапе вызвал вопрос: нужно ли использовать линтеры – программы для чистки кода? В итоге решили, что нужно. Расскажем про возможности комбинации eslint + stylelint + prettier + husky.
Eslint
Eslint позволяет форматировать код в соответствии с существующими правилами, а также прописывать собственные требования. С его помощью можно настроить:
- Количество максимальных параметров у функции;
Сортировку импортов по типам (например, размещать импорты css-файлов внизу по умолчанию); - Контроль массива зависимостей внутри хуков, например чтобы не забыть добавить в массив данные, в зависимости от которых в хуке выполняется логика;
- Ограниченную вложенность относительных импортов “../../../components” (в противном случае придется использовать абсолютный импорт);
Stylelint
Помогает форматировать стили:
- Сортировать свойства;
- Подсвечивать дубликаты селекторов
- Преобразовывать rgb в hex и многое другое.
Prettier
Также работает с форматированием по правилам. Но от него можно отказаться, так как Eslint выполняет абсолютно те же функции. К тому же, в составе одной комбинации между этими линтерами часто происходят конфликты: Eslint пытается сделать форматирование по одной инструкции, а Prettier тоже самое, но по другой. Поэтому, если вы не хотите настраивать Prettier для форматирования JSON, readme и других файлов, – можете работать только с Eslint.
Husky
Помогает настроить git hook pre-commit. Это значит, что перед созданием вашего коммита, произойдет выполнение описанных инструкций. В нашем случае – произойдет проверка линтерами Eslint и Stylelint с автоматическим исправлением возможных проблем. Если критических ошибок не останется, коммит будет успешно создан. В противном случае – вам придется устранить ошибки вручную и создать коммит заново.
Такой подход помогает следить за качеством отправляемого в удаленный репозиторий кода и поддерживать идентичную кодовую базу для всех разработчиков. Также можно настроить вашу IDE (например, VS Code), чтобы при каждом сохранении в файле автоматически выполнялось форматирование с помощью линтеров. А если изменить конфигурации, то сохранение будет происходить сразу после того, как вы перестаете писать код.
Топ библиотек по версии dev.family
Делимся любимой подборкой, проверенной временем и проектами в нашем портфолио.
Orval
О нем мы уже рассказывали выше и даже подготовили целую статью. Главное преимущество Orval в том, что функции выборки данных генерируются автоматически, ориентируясь на yaml-файл, который формируют бэкэнд-специалисты. Фронтенд-специалистам остается только использовать готовые функции. Так мы экономим время и получаем постоянно поддерживаемую документацию.
Библиотеки локализации
К таким библиотеками мы относим i18-next, react-intl, next-intl и используем их везде. Даже на проектах, где для разработки нужен только один язык. Дело в том, что текст всегда находится в одной директории. При добавлении еще одного языка на сайт, нам не придется искать текстовые данные по всему проекту, потому что они уже будут храниться в одном месте. Все, что вам нужно сделать, – добавить идентичные файлы с новой локализацией и внести соответствующие изменения в конфигурацию библиотеки.
Довольно часто разработчикам приходится менять текст в некоторых частях сайта. В этом случае библиотеки локализации также придут на помощь. Больше не нужно вручную искать все места, где использован один и тот же текст. Достаточно просто изменить его в соответствующей переменной внутри JSON-файла с локализацией.
Figma-tokens
Прямо сейчас мы тестируем этот подход на одном из новых проектов. Кратко опишем контекст.
Существует плагин, который позволяет экспортировать дизайнерские токены из Figma прямо в удаленный репозиторий проекта в формате JSON. Данный файл парсится с помощью определенных библиотек сразу в css-файлы. Внутри них будут находиться css-переменные и даже миксины, которые можно использовать по всему проекту.
В Tokens Studio (плагин) есть возможность выгружать изменения в GitLab. Если все правильно настроено, как только JSON-файл с токенами меняется, CI/CD проект будет пересобираться. Во время пересборки проекта все css-файлы генерируются заново с учетом внесенных изменений и, после успешной сборки, применяются во всех необходимых местах. Это значит, что дизайнер может внести изменения в Figma и автоматически отправить изменения прямо на сайт, минуя фронтенд-специалиста.
В свою очередь, фронтенд-специалисту не нужно вручную создавать все файлы и переменные для CSS. Они будут сгенерированы автоматически. Это позволит сэкономить много времени на старте проекта.
На этом все! Больше наших статей о фронтенд-разработке можно почитать тут.Небольшой бонус от нас – ссылки на все библиотеки и другие артефакты, которые мы упоминали в этой статье: