А от як назвати протилежне мислення, я ще не знаю. Суть його полягає в тому, що замість робити ВСЕ на умовному реакті, спочатку треба трошки подумати — "а може HTML/CSS/JS вже самі таке вміють?".
Дивіться, я тут останнім часом ношусь і з
dialog, popover, @layout, @scope, всякими приколами з Browser API, що аж примудрився зібрати цілком собі робочий застосунок чисто на нативці. І поки я робив ту альфа-версію, усе частіше ловив себе на думці, що величезну кількість речей ми досі робимо максимально складно. Просто за звичкою.Я якось сів і почав прикидати, що можна теоретично викинути або зробити по іншому в будь-якій бібліотеці компонент. І перше, що спадає на думку — усілякі тултипи, таби, закривайки-випадайки і тому подібний дрібʼязок чудово робляться за доповогою нативних елементів.
А що не дуже робиться, то для того є Custom Elements. Готуючись до доповіді на fwdays, я зрозумів одну цікаву річ — коли мова йде про нативні вебкомпоненти, усі думають про страшний Shadow DOM, з усіма його ізоляціями, інкапсуляціями, шаблонами та іншими страхіттями. Хтось просто боїться класів. Ну але то таке.
Річ у тім, що нам геть не обовʼязково використовувати Shadow DOM і мудохатися з ізоляцією стилів. Custom Elements чудово себе почувають в так званому Light DOM (неофіційна назва), коли вони виступають просто такою собі обгорткою для відкритого фрагменту дерева.
Так от. Custom Elements виявились дуже зручними для невеличких "тупих" компонентів, задачею яких є якийсь простенький функціонал, наприклад, перемикання активного елемента всередині в залежності від значення атрибуту. Чи той же collapse/expand, але з зовнішнім керуванням. У мене взагалі є компонентик, який просто показує поточний слайд у вигляді "7/8", склеюючи два значення докупи.
В чому ж, на мою думку, вигода? По-перше, Custom Elements підтримуються сьогодні будь-яким відром. По-друге — сумісність. Ваш фреймворк не зможе відрендерити Custom Element лише в одному випадку — він не вміє рендерити усі інші теги. По-третє — зменшення залежності на внутрішні приколи вашого стеку, кастомні елементи залежать тільки на вебстандарти і бравзери. По-четверте — якщо засукати рукави і перенести всі банальні й прості рішення з фреймворку на Custom Elements, то можна нічогенько так скоротити фінальний розмір бандлу.
Загалом, ідея цього допису полягає в тому, щоб за нагоди почати практикувати таку собі трирівневу систему прийняття рішень при створенні нового компонента:
1. Чи вміє це HTML/CSS/JS?
Ви будете приємно здивовані тим, скільки всього сьогодні вміє платформа. Я й сам час від часу роблю для себе приємні відкриття, буду відвертим. Загалом, якщо вам треба щось просте, спочатку пошукайте, чи нема такого вже в бравзері.
2. Чи треба мені для цього мій фреймворк?
Нативна платформа, хоч і вміє вже багато, усе ж дає нам радше кубики з леґо аніж готові рішення. І часто рішення треба зібрати самим. Але тут теж є певний простір для маневру — часто певні рішення цілком собі складаються докупи без залучення додаткової складності. Ті самі Custom Elements — це той шар, який дозволяє зібрати певний функціонал, надаючи вам і реактивність, і інструменти для DOM, і події, і команди, і ще купу всього просто з коробки.
3. Чи можу я не все зробити з фреймворком?
Тут більше задача на декомпозицію. Часто, дійсно, новий компонент може видаватися складним, залежним на глобальні стани, завʼязаним на інші компоненти і так далі. Але, якщо подихати носом і подивитися зі сторони, можна побачити як страшна велика задача розкладається на оберемок маленьких нестрашних. І тоді ми можемо спокійно повертатись до питання №1.
Я би радив спробувати розглядати ваш фреймворк як такий собі оркестратор, який відповідає за складні композитні задачі, а прості речі він віддає на відкуп бравзеру і вашим знанням платформи.
Якщо спробувати зібрати це все в один афоризм — не сапайте вазони комбайнами.
@babichdev