ReactJS *

Несколько важных новостей

👀 THE MAIN THING!

Gemini в Chrome.
Google официально встроил Gemini прямо в браузер. Пару дней назад Firefox обьявила о том, что приостанавливает создание AI-браузера из-за недовольства пользователей. Google решила сделать наоборот и начинает Новую эру браузеров".

Вот несколько фичей которые они представили:

1. Постоянная боковая панель, которая видит все ваши открытые вкладки(максимально 112) и может отвечать по конкретной странице. Звучит на самом деле неплохо, так как меньше нужно будет думать и переключаться, однако есть вопросы с безопасностью. Для серфинга в интернете я думаю всем очень понравится.

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

3. Встроенный Nano Banana. Редактирование и создание изображений прямо в браузере без надобности их сохранять и запускать в Paint.

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

😍 ЕЩЕ НЕМНОГО ИНТЕРЕСНОГО

Bun ускоряет async/await на 35%.
Bun v1.3.7 обновил JavaScriptCore и дал реальный прирост производительности для async/await операций. Для фронтенд-команд это означает более быстрые билды и CI/CD пайплайны, особенно если вы используете Bun для сборки Next.js или других фреймворков.

Yarn 6 переписывают на Rust.
Yarn делает логичный ход: порт в Rust с фокусом на производительность. Если это действительно ускорит установку зависимостей, это сэкономит часы времени разработчиков в неделю, особенно в больших монорепозиториях. Но скорее всего, они просто не смогли победить pnpm, и решили добиться ускорения засчет нативности Rust. 💪

WSO2 публично прощается с Java, переходит на Go.
Enterprise-компания, которая 20 лет строила middleware на Java, теперь говорит: "Java — не язык будущего для нашей инфраструктуры". Для фронтенд-команд это важно, потому что переход backend на Go означает более быстрые BFF и API, что напрямую влияет на UX наших приложений.

Ryan Carniato выпустил обзор JavaScript-фреймворков на 2026 год.
Автор SolidJS делает традиционный "большой обзор" ландшафта фреймворков. Полезен не из-за "кто победит", а из-за того, как он раскладывает тенденции по направлениям — это помогает планировать, какие технологии изучать команде.

Cloudflare делает microfrontends частью своей платформы.
Ещё один шаг к тому, чтобы "фронтенд как монолитное SPA" оставался больше в учебниках, чем в проде. Если инструменты для microfrontends становятся более доступными, это открывает возможности для разделения фронтенда на независимые части.

Мой телеграм канал, все новые посты там! Подпишись!

А как?

Как?

Реально, как? Скажите мне. Почему это происходит так..

Почему у PWA до сих пор нет полноценного «магазина приложений» — возможно ли это вообще?

Всем привет.

В течение последних месяцев, работая с PWA-приложениями, мы постоянно сталкивались с одним и тем же вопросом:

Почему в 2025 году у PWA до сих пор нет настоящего App Store?

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

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

⸻

1. Установка остаётся непонятной для пользователей

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

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

Во многих PWA-каталогах всё ограничивается текстовой инструкцией — и на этом взаимодействие с сервисом фактически заканчивается.

⸻

2. Отсутствие доверия

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

Со стороны разработчиков наблюдаются крайности:
• либо любой может опубликовать приложение без подтверждения права собственности,
• либо проверка обязательна, но сложна и ограничена одним способом (например, через DNS-записи).

В итоге доверие не формируется ни у одной из сторон.

⸻

3. Разработчики — второстепенные участники экосистемы

Распространённые проблемы:
• медленные и неудобные процессы публикации,
• почти полное отсутствие автоматического заполнения данных из манифеста,
• нехватка инструментов, которые были бы полезны разработчику ещё до установки приложения пользователем.

Экосистема не стимулирует разработчиков поддерживать и развивать свои PWA.

⸻

4. Интерфейс не воспринимается как «нативный»

Это тонкий, но важный момент.

Если магазин:
• выглядит как обычный веб-сайт,
• не вызывает ассоциаций с App Store или Google Play,

пользователи инстинктивно доверяют ему меньше — даже если сами приложения качественные.

⸻

При этом сами PWA как технология за последние годы заметно повзрослели: офлайн-режим, push-уведомления, installability, Web APIs.
Однако именно слой распространения и доверия остаётся самым слабым звеном.

⸻

Главный вопрос, к которому мы пришли

Возможно ли вообще создать PWA-магазин, который:
• пользователи будут воспринимать как настоящий магазин приложений,
• не станет источником боли для разработчиков,
• сможет устойчиво развиваться, а не быть заброшенным через несколько месяцев?

Или же сама идея магазина PWA в текущей экосистеме изначально ошибочна?

Будет интересно узнать ваш опыт.

Вы публиковали PWA-приложения в существующих магазинах или каталогах?
Что вызывало наибольшие сложности — у разработчиков или у пользователей?

React One Click Component

Поделюсь самодельным расширением для VS Code, которое позволяет создавать React-компоненты в один клик.

Что умеет:

• гибкое именование файлов: выбор между PascalCase, camelCase, kebab-case или snake_case для генерируемых файлов;

• работа с .tsx и .jsx для файлов компонентов, а также .scss, .css, .less и .sass для стилей;

• редактируемые шаблоны: настройка содержимого генерируемых файлов прямо в VS Code;

• опциональное создание файлов реэкспорта и стилей.

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

На всякий случай: ни с какими внешними сервисами и нейронками расширение не взаимодействует)

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

Несмотря на это, i18next остаётся решением по умолчанию, которое ChatGPT рекомендует для внедрения i18n. Мы слишком часто попадаемся на удочку страниц «Get Started» (да, оно работает, но действительно ли это сделано правильно?).

На практике я замечаю, что многие проекты пропускают самые критичные аспекты интернационализации, особенно связанные с SEO: перевод метаданных, теги hreflang, локализация ссылок, настройка sitemap и robots.txt.

Что ещё хуже, почти половина проектов, использующих i18next (особенно после роста популярности ИИ), не структурируют контент по неймспейсам или же загружают все неймспейсы при каждом запросе.

Последствия? Вы можете заставлять каждого пользователя загружать контент всех страниц на всех языках, даже если он посещает только одну страницу. Например: при 10 страницах и 10 языках 99% загружаемого контента никогда не будет использовано. Совет: используйте анализатор бандла, чтобы выявить это.

Чтобы решить проблему, я подготовил руководство о том, как правильно интернационализировать приложение Next.js 16 с i18next в 2025 году.

Вот ссылка: https://intlayer.org/ru/blog/nextjs-internationalization-using-next-i18next

Новое видео с нашей Конференции Luxms, теперь с технологической сессии. Илья Гурешидзе @IlyaGureshidze начальник отдела разработки Luxms BI рассказал о магии вне Хогвартса внутри движка.

Одна из сильных сторон Luxms BI – гибкость клиентской части. Связка JSON + React дает предсказуемое поведение, быструю сборку и легкую доработку интерфейсов – без необходимости лезть в «ядро» или переписывать все с нуля.

Для удобства разработчиков в системе есть специальный проект – bi-magic-resources (BMR). Это проект на React, где можно разрабатывать интерфейсы, хранить наработки в GIT, вести совместную разработку, кастомизировать сборку и запуск, подключать свои библиотеки и переиспользовать уже готовые компоненты заказчика. С ним удобно разрабатывать, тестировать и пробовать новый функционал, не мешая основной ветке разработки.

Подробнее на:

• VK video

• Youtube

• Rutube

От TODO-листа к анимационному шедевру

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

• Разбор ключевых motion-компонентов.

• Практические примеры кода с плавной анимацией TODO-листа.

• Как настроить анимации появления, исчезновения и перетаскивания элементов.

• Советы по оптимизации с LazyMotion и управлению анимациями через хуки.

• Интересные лайфхаки для создания интерактивных интерфейсов без потери производительности.

В статье «Попробовал библиотеку Motion в React: делюсь обзором» есть примеры кода, GIF-анимации и описание хуков, которых, достаточно, чтобы понять Motion, и, возможно, попробовать его руками, сэкономив время на чтении документации.

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

Переписываем примеры из популярных стейт-менеджеров на kr-observable используя только две функции.

7 полезных плагинов для фронтенд-разработки в VS Code!

Сегодня хочу поделиться с вами списком полезных плагинов для Visual Studio Code, которые упростят вашу работу и повысят производительность.

1. ESLint — находит ошибки и баги в JS/TS коде. Незаменим для профессиональной разработки. 🛠

2. Prettier — автоматически форматирует код по стандартам. Никаких споров о стилях! 📊

3. Code Spell Checker — ищет опечатки в коде и комментариях. Больше никаких ошибок из-за опечаток! Для русского языка нужно установить дополнительный плагин Russian - Code Spell Checker 🔍

4. DotENV — подсветка синтаксиса для .env файлов. Переменные окружения больше не путаются! 📦

5. GitLens — показывает, кто и когда менял каждую строку кода. Незаменим для работы в команде.

6. NPM outdated — показывает устаревшие зависимости в проекте. Не пропустите важные обновления! ⏳

7. SonarQube — анализирует качество кода, ищет уязвимости. 🔐

Установите эти плагины и сделайте свою работу ещё эффективнее! 💻

Жёсткая структура React-компонентов

При работе над React-приложениями я часто сталкиваюсь с тем, что мои коллеги смешивают в одном файле и JSX, и CSS-in-JS стили, и логику, и типы компонента. Работать с таким месивом очень сложно. Даже если настаивать на выделении логики, стилей и типов в отдельные файлы, это то делается, то нет. Для введения жёсткой структуры компонентов мною была написана простейшая библиотека react-component-structure.

https://github.com/sergeyshpadyrev/react-component-structure

Работает она простейшим образом. Любой компонент необходимо разделить на три хука и файл с типами:

-| Component
    -| index.ts
    -| logic.ts
    -| render.tsx
    -| style.ts
    -| types.ts

В файле logic.ts мы пишем хук useLogic - контроллер компонента, включающий в себя всю его бизнес-логику - все хуки useCallback, useEffect, useMemo и подобные. В этом хуке у нас есть доступ к props компонента.

import { useCallback, useState } from 'react';
import type { Props } from './types';

const useLogic = (props: Props) => {
    const [count, setCount] = useState(props.defaultCount);

    const onClickMinus = useCallback(() => setCount((c) => c - 1), []);
    const onClickPlus = useCallback(() => setCount((c) => c + 1), []);

    return {
        count,
        onClickMinus,
        onClickPlus,
    };
};

export default useLogic;

В файле styles.ts мы помещаем хук useStyle со стилями нашего компонента. Тут мы можем использовать inline-стили, CSS-in-JS или Tailwind. В этом хуке у нас есть доступ к props нашего компонента и к его контроллеру.

import type { Props } from './types';
import useLogic from './logic';
import { useMemo } from 'react';

const useStyle = (props: Props, logic: ReturnType<typeof useLogic>) =>
    useMemo(
        () => ({
            counter: {
                fontSize: logic.count + 10,
            },
            title: {
                color: props.color,
            },
        }),
        [logic.count, props.color],
    );

export default useStyle;

В файле render.tsx мы помещаем хук useRender с JSX, то бишь отображение компонента. В этом хуке у нас есть доступ и к props компонента, и к его контроллеру logic, и к стилям.

import type { Props } from './types';
import type useLogic from './logic';
import type useStyle from './style';

const useRender = (props: Props, logic: ReturnType<typeof useLogic>, style: ReturnType<typeof useStyle>) => {
    return (
        <div>
            <div style={style.title}>Hello {props.greeting}!</div>
            <div style={style.counter}>Count: {logic.count}</div>
            <div onClick={logic.onClickMinus}>Decrease</div>
            <div onClick={logic.onClickPlus}>Increase</div>
        </div>
    );
};

export default useRender;

В index.ts файле мы соединяем все три хука с помощью функции createComponent:

import { createComponent } from 'react-component-structure';

import useLogic from './logic';
import useRender from './render';
import useStyle from './style';

const Component = createComponent({ useLogic, useRender, useStyle });

export default Component;

И в файле types.ts мы объявляем тип для props компонента:

export interface Props {
    color: string;
    defaultCount: number;
    greeting: string;
}

Если у компонента нет props, то можно объявить их так:

export type Props = unknown

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

Если подход и библиотека вам понравились, поставьте репозиторию звезду на гитхабе. Надеюсь этот подход будет вам полезен.

Unit-тесты во фронтенде: развеиваем мифы

После статьи о навыках джуниоров многие не согласились с моей оценкой unit-тестов. Давайте посмотрим, где они действительно полезны, а где создают иллюзию ценности.

Если вы начинающий разработчик, вас наверняка убеждали:
«Без unit-тестов никуда! Всё должно быть покрыто тестами!»
Но так ли это на самом деле?

Где unit-тесты полезны:

• Бизнес-логика и утилиты (форматирование данных, расчёты)

• Кастомные хуки (управление состоянием, формы)

• Критичные функции (редкий зверь во фронтенде)

Где они бесполезны (и даже вредны):

• UI-компоненты (скриншотные тесты часто ломаются из-за изменений вёрстки)

• API с моками (моки не показывают реальное поведение сервера)

• Тестирование библиотек (проверяете чужой код)

Что использовать вместо?

1. Интеграционные тесты — проверяют реальные сценарии

2. Zod для валидации API — предотвращает ошибки из-за неожиданных данных

3. Ручные проверки — быстрее и точнее, чем скриншотные тесты

Для джуниора unit-тесты — не приоритет. Важнее:

• Глубокое изучение фреймворка

• Умение работать с API

• Навык чтения и отладки кода

Не стоит тратить время на «тесты ради тестов». Сосредоточьтесь на том, что действительно поможет в работе.

Чек-лист для эффективного технического интервью

1. Подготовка: что сделать перед собеседованием

• Определите 3 главных навыка, необходимых для вакансии. Например: «Оптимизация React», «Работа с легаси-кодом (React классы)», «Работа с Redux».

• Подготовьте реальные задачи из вашего проекта, а не абстрактные алгоритмы.

• Четко опишите стек технологий и проблемы проекта, чтобы кандидат понимал контекст.

Пример: «У нас проект на React 16.8. Остались классовые компоненты, которые нужно переписать на хуки, и мы используем классический Redux».

2. Структура собеседования

А. Вводная часть (5-10 минут)

• Представьтесь и расскажите о проекте простым и понятным языком.

• Спросите кандидата, есть ли у него опыт работы над подобными задачами.

Б. Проверка навыков (30-50 минут)

1. Практическая задача (5-10 минут)

   • Дайте кандидату упрощенную версию реальной проблемы. Например: «Нужно переписать классовый компонент на хуки и подключить его к Redux, а затем оптимизировать рендер».

   • Позвольте кандидату воспользоваться интернетом для поиска информации. Главное, чтобы он показал процесс решения задачи, а не просто копировал ответ.

2. Гибкие вопросы (5-10 минут)

   • В процессе выполнения задачи или после ее завершения (на мой взгляд, лучше после) задавайте вопросы, которые помогут вам лучше понять подход кандидата.

   Пример: «Вы использовали кеширование. Расскажите подробнее, как это поможет нашему проекту?»

3. Финальное обсуждение задачи (10-15 минут)

   • Обсудите решение задачи целиком, что получилось, а что можно улучшить.

4. Если все навыки не уместились в одну задачу, вернитесь к шагу 1.

В. Заключение (5-10 минут)

• Дайте кандидату возможность задать вопросы о проекте.

• Объясните, какие будут следующие шаги, чтобы не оставлять его в подвешенном состоянии.

3. Критерии оценки

Оценивайте кандидата по конкретным показателям, а не по субъективным впечатлениям:

1. Понимание проблемы — видит ли кандидат суть задачи?

2. Процесс решения — как ищет ответ, какие вопросы задает?

3. Качество кода — читаемость, оптимизация.

4. Коммуникация — может ли кандидат объяснить свои решения?

Пример оценки:

• ✅ «Правильно переписал с классов на хуки и подключил Redux» — отличный кандидат!

• ⚠️ «Правильно настроил кеширование, но забыл useCallback в одном месте» — нужно обсудить детали.

• ❌ «Не смог объяснить, почему компонент ререндерится» — потенциальные риски для проекта.

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

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

SOLID как священная корова? 🤔
Я думал, что пост о «фальшивых сеньорах» пройдёт спокойно — ну, очередной крик души о собеседованиях. 😅 Но нет! Хабровчане увидели слово «SOLID» и решили, что это вызов их святыне. Хотя я ничего плохого про него не сказал — просто отметил, что в React 2025 спрашивают про него по инерции. 😕

Где магия, а где фарс? ✨
Комментатор с саркастичным «быдлокод» (спасибо за реакцию, коллега!) будто подтвердил мою мысль: SOLID — это не религия, а инструмент. 🛠
SRP (Single Responsibility) в React — это о компонентах. Но если ваш «компонент формы» содержит логику, стили, валидацию и даже полёт на Марс, это не нарушение SOLID’а, а просто плохой код. 🌙
DIP (Dependency Inversion) в мире хуков и Context API чаще выглядит как «передать пропс» или «создать useClient», чем как «абстрактный фабричный фасад». 🧩
LSP (Liskov Substitution) в функциональном программировании? Его там просто нет. Или вы верите, что Button и IconButton должны наследоваться от AbstractClickable? 🤔

Если кандидат не может объяснить даже это, а только бормочет о «SOLID — это про ответственность» и использует ChatGPT, это не про принципы, а про некомпетентность. 🙅‍♂️

Про GPT и кандидатов-попугаев 🦜
«Чатжпт вам расскажет» — именно! Но если человек не может пересказать своими словами, он не понимает. А если не понимает, как он будет применять это на практике? 😵

Вывод 📜
SOLID — это хорошо. Плохо — догматично использовать его без понимания, где он нужен, а где создаёт лишние сложности. 🚫

🤡 «Фальшивые сеньоры»: как меня пытались обмануть кандидаты

Кандидат с «идеальной памятью»

Сидит передо мной разработчик. Отвечает на вопросы... странно:

Простые вещи вроде «что такое замыкание» — щёлкает как орешки.

Сложные вопросы — делает паузу на 15 секунд... и выдаёт академический ответ.

Решил проверить на практике:

✅ Теория — 10 из 10

❓ Практика — 6 из 10: простые и типовые задачи легко, рефакторинг с адской болью

❌ Объяснить, что и для чего делал — 0 из 10. Поддержать диалог, хоть как-то отойти от шаблонов — это всё не про таких кандидатов.

Напоминает студента, который выучил билеты, но не понимает предмет. Скорее всего, ему кто-то подсказывал, или он просто зазубрил типовые ответы.

«SOLID? Ну это когда ответственно»

Обычно я не люблю спрашивать про SOLID (кому вообще это нужно в React в 2025?). Но тут поведение кандидата было подозрительным — решил проверить.

Диалог:

— Расскажи про SOLID

— Это принцип единственной ответственности!

— Я жду продолжения

— Всё...

— Больше ничего не помнишь?

— Ну это основная часть....💥

Тут всё еще грустнее, видимо, GPT просто выкинул перед кандидатом 5 принципов без пояснения, что все 5 принципов образуют SOLID.

Так к чему это я:

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

Как провести идеально бесполезное собеседование для фронтендера!

Шаг 1: Берем «элитный» шаблон Яндекс.Мультитрека.

Шаг 2: Удаляем всё ценное — оставляем только хаотичный набор вопросов.

Шаг 3: Делаем вид, что это «специально под вакансию» (спойлер: одни и те же 40 вопросов получают все — от стажера до лида).

Главные хиты программы:

— «Назови 5+ способов центрировать div» (ведь React-лид должен уметь это с закрытыми глазами). — «Расскажи про Event Loop как стихотворение» (иначе как проверить лидерские качества?). — «SOLID наизусть, включая историю создания каждого принципа». — Секретный прием: задаем общие вопросы, но с видом эксперта ждем «правильного» ответа (который знает только интервьюер).

Философский бонус: пока такие собеседования существуют, «прохождение собеседований» остаётся отдельным навыком в вакууме — где побеждает не тот, кто лучше код пишет, а тот, кто научился угадывать, что имел в виду интервьюер.

Гарантированный результат:

• Кандидат либо засыпает, либо пишет гневный пост.

• Ваша компания экономит на зарплатах — никто не доходит до оффера.

• Вы получаете статус «самое запоминающееся собеседование в карьере». Если узнали свою компанию — не переживайте, вы не одиноки в этом увлекательном квесте!

Сравнение производительности React-компонентов: Gravity UI vs другие библиотеки

Я core‑разработчик Gravity UI, и периодически нам в команду поступают вопросы про производительность react‑компонентов из нашей библиотеки @gravity‑ui/uikit. Я решил сделать небольшое исследование этого вопроса, и всё написанное ниже является отправной точкой для дальнейших исследований и попыткой ответа на вопрос «Почему Gravity тормозит?»

Обычно этот запрос пишут без дополнительных деталей, поэтому я исхожу из предположения, что одна (но, конечно же, не единственная) из основных проблем производительности — долгое время отрисовки. В рамках этого исследования мы рассмотрели затраты на первый рендеринг отдельных компонент каждой из библиотек в изолированной среде. Для сравнения были выбраны библиотеки @adobe/react‑spectrum, @mui/material и antd.

Методология исследования

Технический стек:

• Playwright — фреймворк для автоматизации тестирования кода в разных браузерах (подробнее).

• PerformanceObserver API — браузерный API для измерения производительности (подробнее).

Условия выполнения тестов:

• Каждый тест запускается в отдельном контексте браузера.

• Единовременно выполняется только один тест (настройка workers в конфиге Playwright), что гарантирует выделение одинакового количества ресурсов на каждый тест.

• Каждый тест повторяется 50 раз.

• Тесты проводятся с разным количеством нод (10, 100, 1000).

Порядок выполнения одного теста:

1. Открытие новой страницы в браузере.

2. Инициализация PerformanceObserver.

3. Начало сбора метрик.

4. Рендеринг компонентов.

5. Завершение сбора метрик.

Процесс измерения:

В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.

Результаты

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

1. @gravity‑ui/uikit показывает конкурентоспособные результаты:

   • В большинстве тестов находится в верхней части рейтинга.

   • Демонстрирует стабильное время рендеринга при разном количестве нод.

   • Особенно эффективен в компонентах Button, Checkbox и Switch.

   • Имеет проблемы со временем рендера компонента TextArea.

2. @mui/material также показывает хорошие результаты:

   • Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.

   • Имеет видимый рост времени рендера в зависимости от количества нод.

3. antd и React Spectrum:

   • Показывают более высокое время рендеринга в большинстве тестов.

   • Имеют больший разброс между минимальным и максимальным временем.

С помощью этого инструмента можно провести замеры производительности на своей локальной машине, а также добавить тесты для компонентов, которых ещё нет. Нам поможет, если вы развернёте его у себя и пришлёте в PR результат работы на своём компьютере.

В этой статье я раскрыл один из примеров, как мы работаем с библиотекой. Но нам очень важна обратная связь от сообщества: если у вас есть конкретный пример, где Gravity UI показывает себя сильно хуже других библиотек, или если вы видите ошибку в нашей методологии тестирования, приходите в комментарии к этому посту или создавайте issue, обсудим. А также не забывайте ставить звёздочки проекту!

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

Но где сейчас обитает студент? Где можно рассказать о себе, и закинуть удочку для поиска интернов? Хотелось бы и собрать команду, и дать молодым специалистам возможность пополнить свое портфолио реальным кейсом. Заранее спасибо.

Как тестировать фронтенд?

Для меня уже нет вопроса - нужны ли тесты на фронтенде? Личный опыт подсказал, что нужны, как и согласованный цельный подход к архитектуре. Тому есть несколько причин:

• Без unit-тестов и автоматических e2e-тестов ручное тестирование занимает много времени. К тому же человек, скорее всего, при регрессионном тестировании что-то пропустит, и баги попадут в production. Особенно это актуально для больших проектов с большой кодовой базой.

• Без автоматических тестов страшно рефакторить код. А если нет выстроенной архитектуры с соблюдением low coupling/high cohesion, то этот страх вполне оправдан. А без регулярного пересмотра кода приложение рано или поздно превратится в большой комок грязи.

• У unit-тестов есть интересный побочный эффект. Если пользоваться подходом TDD и писать тесты сразу вместе с кодом (и даже перед написанием кода), то качество модулей и архитектуры в целом повышается. Это происходит, потому что с позиции написания теста мы думаем не только о том, как нам побыстрее завершить работу над модулем, но и о том, как этот модуль будет выглядеть снаружи, удобно ли будет его использовать внутри других модулей, так как тест в этом случае служит ещё и образцом вызывающего модуля.

• Тесты - это дополнительная документация к коду. Причём такую документацию не получится держать в неактуальном состоянии, иначе упавшие тесты не пропустят код в production при наличии настроенного шлюза проверки качества в CI/CD пайплайне.

Это всё прекрасно и, как показывает практика, работает, как ожидается, но остаются вопросы.

• Как тестировать уровень представления приложения? Например, в случае с каким-нибудь фреймворком с использованием React это будут React-компоненты, виджеты, представляющие отдельные элементы пользовательского интерфейса. Тестировать там, по сути, нужно функцию. Передали ряд аргументов (пропсов или состояний) - получили одно представление. Передали другие аргументы - другое. Зависимость результата от набора аргументов - однозначная. Чтобы это проверить, можно использовать тесты со скриншотами. Я предпочитаю snapshot-тесты, они дают больше контроля, но работают довольно медленно и могут быть хрупкими, если недостаточно грамотно отделять слой представления от логики.

• А что со временем написания кода вместе с тестами? Будем ли мы вовремя успевать сдавать новые модули и радовать наших пользователей и руководство? Я думаю, что это не совсем правильные вопросы. Спрашивать надо о том, сколько будут стоить ошибки, попавшие на production из-за отсутствия тестов? Если ваше приложение - landing page с минимумом логики, то вряд ли цена ошибки будет высока. В небольшой кодовой базе её будет легко локализовать и исправить. А если вы работаете с финансами и у вас миллионы пользователей? В этом случае цена ошибки на production будет намного выше.

• Как донести необходимость тестов до команды и правильно включить автоматизацию тестирования в процесс разработки? Это на самом деле серьёзный вопрос. Не все разработчики понимают, зачем вообще тесты на фронтенде и обоснование их необходимости может вылиться в не слишком продуктивный холивар. А если продавливать такое решение сверху, то без понимания и принятия командой этого решения будут попытки обойти систему и снижение мотивации. Мне когда-то в подобной ситуации помогла практика парного программирования и выстраивание инженерной культуры в команде (совместное чтение технической литературы, архитектурные встречи с использованием white board).

А какие практики для тестирования применяете вы?