Розробка високопродуктивного фронтенду на Solid.js

Solid.js розробка: де ламається продуктивність

Solid.js будує інтерфейс на тонкій реактивності: сигнали знають, який вузол від них залежить, і оновлюють лише його — віртуального дерева, яке треба перезбирати й порівнювати, тут немає.

Тому продуктивність інтерфейсу на формах і картках залишається рівною навіть на слабких пристроях, а ламається все на конкретних ділянках коду.

Перша ділянка — важкі списки й таблиці. Поки рядків десятки, все передбачувано; коли в таблицю потрапляють тисячі записів із фільтрами, сортуванням і розкривними деталями, вузьке місце фронтенду зміщується до створення вузлів і перерахунку порядку.

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

Друга — часті оновлення стану. Живі показники, стрічка повідомлень, перетягування елементів: кожен запис сигналу синхронно тягне за собою похідні обчислення й ефекти, і без групування оновлень швидкість відгуку просідає на рівному місці.

Третя — зайві перемальовування через завеликий стан. Один спільний сигнал на сторінку змушує перераховуватися всі підписки: правка поля в шапці зачіпає таблицю внизу. Лікується гранулярністю — станом на рівні компонента, винесеними мемоізованими похідними й точковими підписками.

Четверта — час до першого відгуку: на слабкому пристрої він складається з обсягу розмітки, її оживлення на клієнті та роботи коду до першого дотику. Розбираємо, як це закривається: що профілювати, де віртуалізувати й як декомпозувати стан, щоб інтерфейс відповідав одразу.

Що змінюється в цифрах: відгук, обсяг коду й збірка

Реактивна модель Solid.js не будує проміжного дерева подання: обчислення прив'язуються до конкретних вузлів, тому при зміні даних оновлюються лише залежні від них ділянки розмітки.

З цього випливають три вимірювані наслідки — час відгуку на дію, обсяг підсумкового коду й час збірки проєкту.

Час відгуку на дію падає, бо зникає каскадне перемальовування. Клік по фільтру раніше запускав перезбирання блоку цілком, тепер перераховується лише рядок результату — кількість операцій із розміткою скорочується в рази.

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

Обсяг підсумкового коду зменшується разом із шаром, який більше не потрібно постачати в браузер.

Частина логіки переїжджає в шар даних і перестає дублюватися в компонентах, збірка збирається з меншої кількості модулів — звідси й менший час збірки проєкту, і компактніший артефакт для викату.

Стабільність інтерфейсу — наслідок того самого порядку оновлень: стан змінює один вузол, сусідні не перестворюються, і інтерфейс не «перескакує» при швидких діях користувача.

Кожну зміну ми фіксуємо замірами до й після: знімаємо профіль відмальовування на типових сценаріях, рахуємо частку оновлюваних вузлів, обсяг збірки та тривалість її проходження. Так зміна архітектури підтверджується цифрами, а не обіцянками.

Solid.js розробка: порівняння підходів до рендерингу

Вибір режиму рендерингу — це не питання смаку, а наслідок того, як швидко має з'являтися перше відмальовування і скільки логіки реально живе в браузері.

У Solid.js точкова реактивність перемальовує лише змінений вузол, тому той самий код працює і при серверному рендерингу, і при поступовому оживленні сторінки — змінюється лише спосіб доставки розмітки клієнту.

Нижче — чотири робочі варіанти, між якими ми обираємо на старті проєкту. Межа між ними проходить по інтерактивності: чим більше блоків оживає на клієнті, тим дорожче розбиття коду на частини й тим акуратніше потрібно проєктувати відкат.

Режими сумісні між собою: статичні розділи віддаються готовою розміткою, а пошук і кабінет підключаються окремими частинами зі своїм оживленням. Такий набір знижує обсяг клієнтського коду на першому екрані й залишає простір для поетапного ускладнення інтерфейсу.

Етапи роботи: від профілювання до впровадження у збірку

Реактивність Solid.js дає виграш лише там, де заздалегідь видно, які вузли оновлюються при кожній зміні стану. Тому починаємо не з переписування розмітки, а із замірів: без них правки перетворюються на перестановку коду без перевірюваного результату.

1. Профілювання інтерфейсу. Знімаємо заміри на реальних екранах: як швидко з'являється перший відгук, скільки триває кадр при фільтрації довгих списків, де перемальовування зачіпає зайві гілки дерева.
2. Схема залежностей. Будуємо граф сигналів, обчислюваних значень і побічних ефектів — стає видно, які дані тягнуть за собою каскад оновлень, а які живуть ізольовано.
3. План впровадження. Розбиваємо перехід на кроки так, щоб кожен можна було викотити й відкотити окремо, не зупиняючи роботу над іншими частинами продукту.
4. Переробка компонентів. Переносимо важкі ділянки на точкове оновлення, піднімаємо стан із глибокої вкладеності, прибираємо зайві підписки й повторні обчислення.
5. Інтеграція з наявним бекендом. Контракти, авторизація й схеми відповідей залишаються попередніми — новий шар відповідає лише за стан і відображення.
6. Перевірка на реальних сценаріях. Проганяємо типові та пікові користувацькі шляхи, звіряємо заміри до й після, закриваємо знайдені регресії автотестами.
7. Передача. Віддаємо команді правила роботи зі станом, схему залежностей і набір перевірок, щоб ефект зберігався при наступних доопрацюваннях.

Артефакти передачі: схеми, правила збірки, документація

Після здачі все залишається в репозиторії замовника й у документації, прив'язаній до коду. Передача проєкту — це не архів і не дзвінок на пам'ять: будь-який інженер, що відкрив репозиторій, має зрозуміти, як збирається застосунок, де живе стан і що можна змінювати без ризику.

• Схема реактивних зв'язків: які сигнали породжують обчислення, де зберігається стан, які вузли оновлюються від однієї зміни — у вигляді діаграми й таблиці «джерело → споживачі».
• Конфігурація проєкту й правила збірки: параметри компіляції, розділення серверної та клієнтської частин, змінні середовища за стендами, команди збірки й локального запуску.
• Домовленості щодо компонентів: де допустимий локальний стан, як оформлюються властивості, як називаються файли й модулі, що заборонено всередині обчислюваних значень.
• Каталог готових компонентів з описом властивостей, прикладів використання й нотатками про те, які зміни безпечні, а які ламають споживачів.
• Регламент підтримки: порядок і частота оновлення залежностей, критерії відкату до попередньої збірки, відповідальні за модулі.
• Регламент перевірок: які автоматичні перевірки проходять до випуску — типи, тести поведінки, бюджет розміру збірки.
• Навчальні матеріали: запис розбору коду з командою замовника й короткі інструкції під типові задачі — додати сторінку, змінити форму, підключити новий запит.

Передаємо на живому коді: розбираємо будову разом з інженерами замовника, відповідаємо на питання щодо кожного пункту списку. Доступ до репозиторію й документації — у команди замовника, без прив'язки до нас.

Кейс: важка панель управління й метрики до та після

Панель управління збирала дані з кількох джерел: зведені графіки, журнал подій і таблицю на десятки тисяч рядків із фільтрами.

Кожне оновлення потоку перемальовувало дерево цілком — вкладка підвисала на кілька секунд, а агрегати в шапці на короткий час розходилися з вмістом таблиці. Користувачі переставали довіряти цифрам і оновлювали сторінку вручну, що повертало їх до того самого стану.

Що змінили

Стан перевели на дрібнозернисту реактивність Solid.js: підписки прив'язали до конкретних зрізів даних, а не до кореневого сховища. Таблицю віддали віртуалізації, важкі похідні значення — мемоізації, оновлення потоку — пакетній обробці в одному кадрі відмальовування.

Віджет оновлюється лише тоді, коли змінюється його власне джерело, а не будь-яке з десятків сусідніх.

Відгук повернувся в частки секунди, панель тримає живий потік без блокування інтерфейсу. Головне — пішов клас відмов, який ми називаємо розсинхроном подання: розходження зведених цифр і деталізації більше не виникає.

Цей сценарій закріпили в регресійних перевірках, щоб він не повернувся разом із наступними доопрацюваннями.

Що робити, якщо фронтенд уже написаний на іншому стеку

Переписувати все одразу не потрібно, і найчастіше це найгірший із варіантів. Поступовий перехід вигідніший там, де продукт живе й приносить виручку: старий код продовжує обслуговувати трафік, а новий шар вмикається посторінково, за маршрутами.

Перший крок — розділити сторінки за критичністю й пов'язаністю. Насамперед переносять ділянки з високим навантаженням і слабкими зв'язками з рештою застосунку: каталог, лістинги, картки товару, окремі кроки оформлення замовлення.

Особистий кабінет і адмінку залишають на потім — там більше станів і прав, і помилка коштує дорожче.

Новий шар вводять на межі маршруту, а не всередині наявних екранів. Обидва застосунки живуть поруч під одним доменом, ділять сесію, авторизацію й шар запитів до сервера, а переходи між ними залишаються непомітними для користувача.

Спільна дизайн-система й один контракт із серверною частиною — те, що утримує сумісність шарів і не дає інтерфейсу роз'їхатися за зовнішнім виглядом і поведінкою.

Продукт при цьому не зупиняється: релізи йдуть як завжди, перемикання сторінки на нову реалізацію робиться правкою маршруту, а відкат — поверненням попереднього.

Solid.js на такій міграції фронтенду показує себе добре: він підключається до окремих вузлів сторінки, не вимагаючи єдиного кореневого застосунку на весь сайт.

У часткової переробки є ціна. Якийсь час живуть дві збірки, частина залежностей дублюється, команда тримає в голові обидві моделі.

Тому ми заздалегідь рахуємо частку сторінок, які реально переїдуть, і говоримо прямо, коли вигідніше переписати цілком, ніж роками підтримувати сумісність.

Технічні сумніви: індексація, залежності, підтримка

Заперечення до фронтенд-стеку зазвичай зводяться до чотирьох: чи потраплять сторінки в індекс, що буде з оновленням залежностей, хто підтримає код і як швидко в нього ввійде нова команда. Розберімо кожне з інженерного боку, без загальних слів.

Оновлення залежностей не зламає проєкт?

Ядро Solid.js навмисно невелике, і більша частина логіки живе в прикладному коді, а не в дереві пакетів. Оновлення виходять рідше й дедалі рідше зачіпають публічні інтерфейси.

Мажорні переходи плануємо окремою задачею з прогоном автотестів на копії збірки — реліз не залежить від того, чи встигли оновитися сторонні бібліотеки.

Чи зможе підтримка чужого коду йти без автора?

Компоненти — звичайні функції з явними залежностями: немає прихованого життєвого циклу, який потрібно тримати в голові. Логіка винесена з розмітки в окремі модулі й покрита перевірками, тому новий інженер змінює поведінку, а не розбирає побічні ефекти. Плюс передаємо схему даних і карту компонентів.

Наскільки високий поріг входу для команди?

Синтаксис близький до того, що розробники вже бачили в інших бібліотеках, тому перехід займає дні, а не місяці. Основна відмінність — управління станом на сигналах; його освоюють на першому ж невеликому модулі. Далі команда працює у звичному ритмі: компонент, тест, рев'ю.

Обговоримо задачу: як ми починаємо роботу

Щоб оцінка спиралася на факти, а не на здогади, нам потрібен мінімум контексту: що за продукт, які сценарії критичні й що вже реалізовано. За цим описом ми розбираємо задачу й повертаємося з планом робіт за етапами, складом команди й строком кожного етапу.

Що надіслати або розповісти:

• опис продукту й три-п'ять головних сценаріїв, якими користуються люди;
• макети, прототип або посилання на поточну версію;
• які екрани мають відгукуватися миттєво навіть на слабких пристроях і повільному зв'язку;
• перелік зовнішніх сервісів для інтеграції: оплата, вхід в акаунт, аналітика, обмін даними;
• що вже написано і на чому це працює — якщо частина інтерфейсу зроблена на Solid.js, подивимося, що перевикористаємо;
• обмеження: жорсткі дати, вимоги до розміщення, до доступів і до захисту даних;
• хто з вашого боку приймає етапи й перевіряє результат.

У відповідь ви отримуєте не вилку «від і до», а розбір: на які етапи поділяється робота, скільки триває кожен, хто в команді за нього відповідає і в якій точці ви приймаєте результат.

Якщо по ходу розбору спливають ризики — наприклад, вузьке місце в обміні даними або нестабільний постачальник послуг — називаємо їх одразу, до старту, а не в середині робіт.

Опишіть задачу в двох абзацах або надішліть перелічене — повернемося з оцінкою й планом робіт.