Інженерна майстерність і карʼєра / крок 07
Голосове №2 — як швидше розробляти інтерфейс
Про що це відео
Другий випуск формату «голосових» (він перейменував подкаст із «5 хвилин про програмування», бо буквально записує ці випуски як голосові повідомлення на iPhone). Одна ідея для пришвидшення фронтенд-роботи: позичити концепцію редактора рівнів з ігор. Ігри відділяють рушій від контенту — Doom із першого дня будували разом із редактором рівнів (відредагував рівень → перезапустив → подивився → повторив), а редактор передбачає декларативний збережений опис рівня. Його теза: декларативні UI-білдери — схеми, що компілюються в низькорівневі компоненти — варто будувати не лише як кроспроєктні інструменти, а навіть усередині одного проєкту, де вони, за його словами, різко здешевлюють розробку і тримають UI консистентним (Абстракції).
Головне
- Готові декларативні адмінські інструменти (react-admin тощо) дозволяють швидко збирати екрани списків/CRUD/ґрідів/галерей — але вони стандартизовані й пасують не кожному проєкту чи компанії. webilab інвестував у власний кроспроєктний інструмент побудови адмінок; це окупається на багатьох проєктах, але вимагає серйозних вкладень.
- Його новіше усвідомлення: той самий підхід із білдером має сенс у межах одного проєкту. Виглядає як безглуздо дорогий хід, але проєктно-специфічний фреймворк набагато дешевший за кроспроєктний — а ці екрани все одно довелося б писати.
- Конкретний приклад із нещодавнього проєкту: ґрід React Material потужний, але доволі низькорівневий, тож він написав власний grid builder, який приймає схему; з ~2 його параметрів ініціалізується ~5 низькорівневих. Результат: ґрід, який він легко конфігурує на будь-якій сторінці, поводиться консистентно, зберігає налаштування там, де йому треба, сумісний із його API, підтримує кастомні дії по рядку через додаткову схему, показує підтвердження видалення та інтегрується з навігацією — усе те, що інакше писалося б руками на кожній сторінці.
- Поверх цього: form builder (форми в діалогах або на сторінках, викликаються з ґріда чи будь-звідки), а над усім — PageBuilder, який видає цілу CRUD-сторінку з однієї схеми. Для більш кастомних сторінок він спускається на рівень нижче і бере лише grid builder чи form builder — шари корисні й поодинці.
- Ключова перевага проєктно-специфічних білдерів (проти кроспроєктних): коли приходить нова фіча, він того ж дня просто розширює схему потрібними елементами. Увесь UI лишається консистентним усюди, що «сильно, сильно здешевлює» розробку і підтримку.
- Його дивує, що підхід не популярніший: люди беруть бібліотеку форм і використовують її «сирою» на кожному екрані, хоча в кожному проєкті є кастомні речі — наприклад, ваш API повертає помилки у певному форматі, який треба обробити і привʼязати до полів, — і ще один декларативний шар над бібліотекою закодував би це один раз (Проєктування програмного забезпечення).
- Звична для серії обмовка: це ідеї та роздуми, а не єдино правильний шлях — «може, на вашому проєкті це не полетить, а може, і на якомусь із моїх не полетить».