vue-why-render 0.8: граф реактивности, WASM-ядро и VS Code-плагин

Что произошло, почему это важно и что взять в работу.

Отладка причин ререндера во Vue уходит от ручного поиска к карте зависимостей «компонент ↔ источник», а WASM-ядро и мост в VS Code делают инструмент пригодным для крупных проектов с сотнями компонентов.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Самая дорогая минута фронтенд-отладки

Вы точно знаете, что компонент перерисовался. Вы не знаете почему. Дальше начинается ручная работа: DevTools, вкладка Components, щелчок по пропсу, поиск по коду, гипотеза, перезагрузка. На крупном проекте такой поиск съедает не минуту, а полдня, и обычно заканчивается фразой «ну, наверное, стор дёрнулся».

Независимый разработчик dadash_i1 выкатил версию 0.8 своего open-source отладчика vue-why-render для Vue 3. Первая версия умела называть причину конкретной перерисовки: не «прокси сработал», а «prop badge: {text} → {text}, новая ссылка при том же значении», «store cart.items: Array(1) → Array(0), action clear()», «route.params.id: "1" → "2"». Версия 0.8 добавляет к этому карту зависимостей целиком, ядро на Rust/WASM и мост в редактор.

За месяц пакет набрал 668 загрузок на npm, попал в каталог модулей Nuxt. Охват скромный, и это честный сигнал: перед нами инструмент одного автора, а не корпоративный продукт. Читать его стоит не как новость про хайп, а как про смену оптики в отладке реактивности.

Граф Deps: от вопроса «почему» к вопросу «кто на кого»

Главная фича 0.8 — вкладка Deps, живая карта «компонент ↔ реактивный источник». Автор формулирует сдвиг так:

Раньше vue-why-render отвечал на вопрос «почему этот компонент перерисовался?». Теперь он отвечает на вопрос «кто от чего зависит?».

Что это значит на практике. Два режима. Components показывает, какие ref, prop, store и computed читает выбранный компонент. Sources работает в обратную сторону: кто зависит от этого ref. На каждом ребре графа висят два счётчика — чтений и триггеров.

Вот здесь и появляется то, чего раньше не было ни в Vue DevTools, ни в профайлере. Если UserAvatar читает user.name 47 раз, а это дало 2 рендера, чтения безвредны и трогать код незачем. Если CartBadge дёргается от cart.items на каждое нажатие клавиши в поисковой строке, вы видите это за один клик, без гипотез. Отладка превращается из перебора в чтение карты.

Техническая деталь, которая делает вкладку пригодной для больших проектов: renderTracked собирается лениво, только для открытой вкладки, и дедуплицируется на лету. В первой версии автор сознательно отказался от этого хука — слишком много вызовов, приложение тормозит. Теперь цена уплачена точечно, а не постоянно.

WASM-ядро: зачем Rust в отладчике

Первый релиз был на чистом JS. Для десятка компонентов нормально. Когда их сотни и тысячи, три операции начинают заметно мешать: построение дерева компонентов, дедупликация причин рендера, дифф двух отчётов между собой. Их переписали на Rust и скомпилировали в WebAssembly.

Устройство аккуратное. WASM-модуль грузится лениво отдельным чанком, бандл приложения не растёт, пока инструмент не понадобился. Если WASM недоступен — SSR, jsdom, строгий CSP — сам включается JS-фолбэк. Конфигурировать нечего, подключающий код разницы не замечает: две строки scan(app, {panel: true}) для обычного проекта, одна строка в конфиге модулей для Nuxt.

Оговорка, без которой было бы враньём: на небольшом приложении разница в скорости неощутима. WASM здесь не про «стало быстрее в 10 раз», а про то, что инструмент вообще не начинает мешать на масштабе.

VS Code, DevTools и Nuxt: убрать переключение контекста

Расширение для VS Code работает через WebSocket-мост: сканер в браузере стримит данные прямо в редактор. В сайдбаре появляется дерево компонентов, отсортированное по числу рендеров, дерево зависимостей, CodeLens над <script setup> с количеством рендеров и средней длительностью, живой счётчик в статус-баре и команды pause / resume / reset из палитры.

Плюс интеграция с Vue DevTools: собственный инспектор с деревом реактивных источников и цветными метками ref, prop, store, computed, а также второй слой на таймлайне, где каждый триггер записан событием.

Ценность здесь не в самих фичах, а в исчезновении прыжков. Инженер, который двадцать раз за день переключается между Chrome и редактором, теряет не время на клик, а контекст. Данные, лежащие там, где пишется код, экономят именно его.

Что это даёт бизнесу и где подвох

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

Подвохов три. Первый — проект держит один автор, у него нет SLA и поддержки в привычном смысле. Второй — 668 загрузок за месяц означают мало боевых проверок: на экзотической сборке или нестандартном плагине поведение может удивить. Третий — сам инструмент встраивается в приложение, и хотя чанк ленивый, подключать его в прод без нужды не стоит.

Часть рисков снимает лицензия MIT и ноль зависимостей: код можно форкнуть, а зависимость не тянет за собой полдерева npm. Vue 3.3+ — единственное требование к стеку. Это мусором не назовёшь, но и в базовый набор каждого проекта я бы его не ставил. Ставить — когда приложение перевалило за сотню компонентов и вопросы «откуда ререндер» стали регулярными.

Что сделать на этой неделе

1. Найти в своём проекте компонент, который перерисовывается чаще остальных (по ощущениям команды этого обычно достаточно).
2. Поставить vue-why-render на ветку, подключить двумя строками и открыть вкладку Components на этом компоненте.
3. Переключиться в Deps и посмотреть на счётчики чтений и триггеров: где чтений десятки, а рендеров единицы — там трогать нечего.
4. Проверить ребро с наибольшим числом триггеров. Если оно уходит в частый ввод или в стор, который пишется на каждый keystroke, — это и есть задача на спринт.
5. Прогнать отчёт до и после правки, сравнить дифф. Если экономия не видна, откатить и не тащить инструмент в прод.
6. Проверить поведение на SSR или jsdom, если они есть в пайплайне: убедиться, что JS-фолбэк подхватился и ничего не падает в CI.

Вывод

0.8 закрывает разрыв, который в Vue держался годами: DevTools показывали состояние, профайлер показывал время, и никто толком не показывал причинно-следственные связи между источником и компонентом. Теперь карта есть. Вопрос только в том, насколько крупным должен быть ваш проект, чтобы её захотелось открыть.