🧊 siberiacancode x IT-ХОЗЯЕВА

Подготовка к докладу HolyJS ⭐️ Часть 4

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

Моки можно и нужно разделять на два уровня. Первый — моки для разработки приложения: когда вы реализуете фичу, собираете демо заказчику или отдаёте сценарий на ручное тестирование. Второй — моки непосредственно для автотестов. Это разделение важно: попытки объединить оба сценария обычно приводят только к переусложнению моков.

Сегодня говорим про первый тип. Пример можно посмотреть в репозитории в папке mock. Здесь важно понимать задачу: нам нужен простой и понятный серверный код, достаточно близкий к реальному API, но не его полная реплика. Тратить ресурсы на воспроизведение всего бэкенда просто нет смысла.
export const postOtpsOtp = [
rest.post(
'/otps/otp',
{
match: {
body: {
phone: '77777777774'
}
},
response: {
success: false,
reason: 'Не удалось отправить код'
}
},
{ status: 400 }
),
rest.post('/otps/otp', {
success: true,
retryDelay: 30_000
})
];

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

Отдельная проблема — данные для моков. Их тоже важно раскладывать структурно и не заполнять руками всё подряд. Тут хорошо работает связка автогенерации из apicraft и faker: мы указываем только поля, которые важны для конкретного сценария, а всё остальное генерируется автоматически.
let cards = Array.from({ length: 5 }, () =>
createCardFake({
panMasked: faker.string.numeric(4)
})
);
В итоге мок остаётся коротким, сценарий читается сразу, а изменение API не превращается в ручное переписывание десятков объектов.

CSS получит новый селектор по префиксу 👋

В Selectors Level 5 добавили новый селектор .prefix-*, который позволит выбирать сразу все классы с определённым префиксом. Например, .btn-* сможет выбрать .btn-primary, .btn-secondary и .btn-large. Сегодня для этого приходится использовать менее читаемую комбинацию вроде [class^="btn-"] и [class*=" btn-"].

Фидбек по докладам с митапа 📰

▪️ «Factory store: масштабирование без компромиссов» — На самом деле доклад про довольно простую инженерную практику — буквально про фабрику на реальном примере. Но тут я бы хотел отметить две вещи. Первое: если вы начинающий спикер, не надо фокусироваться на этом — это очень сильно влияет и на вас самих, и на доклад. Второе: izede написал мне, что во Vue такой проблемы вообще нет, и был прав. Если коротко, понадобилось сделать шаринг глобального стейта с подпиской по id. В React такое нормально не сделать — почти наверняка понадобится external state manager. Ну и всё.

▪️«Две доки, чтоб править всеми» — Я не понял доклад. Во-первых, человек явно не из фронтенд-среды, а во-вторых, половина того, о чём говорил спикер, сегодня заменяется RAG-сервисом. Я не работал с техписателями, поэтому, возможно, просто не понимаю часть их процессов, но то, что было показано в докладе, для меня выглядит как дефолт индустрии, если у вас больше одного микросервиса. При этом сам посыл про документацию правильный.

▪️ «Синхронизация между устройствами: все не так просто, как кажется» — Спикер рассказывает, как синхронизировать корзину продуктов между вебом, мобилкой и бэком. Казалось бы, обычная задача, но в итоге мне понравилось, как доклад развернулся в сторону алгоритмов и решений команды. Чуть-чуть микрофронтендов, чуть-чуть алгоритмов, чуть-чуть собственных решений — хорошо.

▪️ «Вкусы реактивности» — Ну маэстро. Мне очень нравится, когда в докладе есть параллель с чем-то ещё: например, сеансом у психолога, созвездиями или, как здесь, фломастерами. Такие ассоциации реально помогают воспринимать материал. Сам доклад при этом сложный: чтобы его понять, надо нормально погрузиться в реактивность. Но это ещё одна хорошая история про то, что на самом деле происходит в вебе. Единственное — мы со спикером делали стрим на эту тему, и я очень на него обиделся, что он его не вставил и QR-код в презу не добавил.

Огромное спасибо ребятам из MoscowJS, которые позволяют мне стримить и проводят митапы в таком количестве. Если хотите выступить — пишите им сюда. Ребят, знаю лично, помогут подготовиться и выступить, так сказать, получить свой первый опыт.

Подготовка к докладу HolyJS 🎧 Часть 3

Чтобы доклад был полезным, важно дать практику. Мы уже говорили про unit-тесты, теперь пора немного затронуть интеграционные и их высшую степень — e2e. Но чтобы нормально показать такие автотесты и тест-кейсы, нужно приложение.

Показывать всё на очередном todo-листе глупо, а читать доклад без реальных примеров ещё хуже. Поэтому специально для доклада готовится довольно большой репозиторий с одним из заданий Juniors Bootcamp. Само приложение тоже полностью захостим, чтобы его можно было открыть и руками пройти весь флоу.

Мы с командой bootcamp изначально проектируем задания так, чтобы они были максимально приближены к реальным продуктам: основной пользовательский флоу, UI-стандарты, дизайн-система, layout, авторизация, оплата и другие типичные вещи. В итоге это, во-первых, хороший кодовый пример приложения на react hooks, а во-вторых, уже совсем скоро в репозитории начнут появляться тесты. И за счёт реалистичности проекта на нём можно будет действительно показательно разобрать интеграционные и e2e-тесты, а не тестировать кнопку в вакууме.

Сам проект готов на ~90%, надо поправить некоторые вещи и баги. Но это все мелочи, уже можно стартовать настройки harness для моих тестов (иницилизация, ии скиллы, тесткейсы).

React Compiler теперь можно проверять через Oxlint 🎤

Oxlint получил нативную реализацию правила react/react-compiler, которое запускает анализ React Compiler прямо во время линтинга. Раньше для этого приходилось использовать JS-плагин и Babel, а теперь проверка работает внутри Rust-инструментария Oxc. На проекте автора это ускорило lint примерно с 29 до 9 секунд, а после удаления оставшихся JS-плагинов — почти до 3 секунд.

Но интереснее даже не скорость. У Oxlint есть опция reportAllBailouts, которая показывает не только ошибки Rules of React, но и места, где React Compiler просто отказался оптимизировать компонент или хук. То есть можно постепенно смотреть, какая часть приложения реально готова к компилятору и почему остальной код не оптимизируется.

Возможно, именно это поможет react compiler стать стабильней и начать массово использоваться.

Debounce и throttle сложнее, чем кажется 👌

Обычно debounce и throttle показывают как небольшие функции на несколько строк, но в реальном приложении быстро появляются leading, trailing, cancel(), maxWait и другие нюансы. В статье как раз постепенно разбирают эти кейсы, а также показывают, когда вместо throttle для визуальных обновлений лучше использовать requestAnimationFrame.

Есть и более практичные проблемы: debounce уменьшает количество запросов, но не отменяет уже запущенные, поэтому для поиска может понадобиться ещё и AbortController. Плюс отдельно разобраны React, stale closures и очистка таймеров.

React Compiler теперь включён по умолчанию в @vitejs/plugin-react 👋

Новинки Firefox 154 🦊

В Firefox 154 много нового именно для CSS. Добавили sibling-count() и sibling-index(), с помощью которых можно узнать количество соседних элементов и позицию текущего элемента среди них. Также появилась поддержка text-box-trim, text-box-edge и сокращённого text-box для более точного контроля пространства вокруг текста.

В JavaScript появились новые методы итераторов: includes(), join(), chunks() и windows(). Из экспериментального — line-clamp без -webkit-, проценты для text-decoration-inset, CSS-функция progress() и CSS Typed OM. Плюс обновили WebRTC: появился getSelectedCandidatePair() и дополнительные метрики транспорта и сертификатов.

Подготовка к докладу HolyJS 📰 Часть 2

Как я и писал ранее, доклад затронет все уровни тестирования. Думаю, сейчас мы пропустим static types и сразу перейдём к unit-тестам.

Чтобы показать, как правильно покрывать код тестами unit-уровня, сначала нужно разобраться с одной проблемой: зачастую то, что называют unit-тестами, на самом деле является функциональными тестами. Тут как раз можно показать простой пример с cn.

import { cn } from '@siberiacancode/reactuse';

export const Button = ({ className }) => (

);

В идеальном unit-тесте все внешние зависимости должны быть изолированы или замоканы. В нашем случае cn — отдельная зависимость, и тест Button не должен одновременно проверять ещё и корректность работы cn. Мы проверяем именно поведение нашего юнита, а всё остальное подменяем. Но это геморно, буквально не имеет смысла и мы понимаем, что это не большой риск работать с cn напрямую.

В том числе поэтому мне всегда немного странно слышать «у нас много unit-тестов на Vitest», а потом внутри теста увидеть рендер целой страницы со всеми зависимостями. Это уже скорее интеграционный тест. Сам подход при этом вполне имеет смысл: интеграционные тесты действительно можно запускать через vitest ради скорости и удобства. Просто важно правильно понимать, какой уровень тестирования мы в этот момент используем.

Дальше уже на хороших примерах разберём, как писать unit-тесты. Для этого я буду reactuse и тесты его хуков, тесты компонентов из собственного UI Kit и обычные функции непосредственно из проекта.

🍌

Next.js 16.3 перформанс и роутинг 😎

В Next.js 16.3 основной фокус снова на производительности и DX. В dev-режиме команда заявляет до 90% меньшего потребления памяти, ускорение сборок и улучшения серверного рендеринга — в некоторых сценариях он способен обрабатывать до 22% больше запросов. При этом большая часть изменений не требует переписывать приложение и должна просто улучшить повседневную работу с фреймворком.

Отдельно прокачали навигацию. Instant Navigations должны сделать переходы между страницами заметно быстрее, а Partial Prefetching дает Next.js больше контроля над тем, что и когда предзагружать. Очень важно теперь понимать, что такое static shell и какие его варианты есть. Для диагностики появились Instant Insights и Navigation Inspector, которые помогают понять, почему конкретный переход оказался медленным. Развитие девтулзов это очень положительный момент.

Еще из интересного — экспериментальный React Compiler на Rust и работа над устойчивостью приложений при проблемах с сетью в офлайн режиме.