#нове_відео
Товариство, нове відео на каналі!

Вирішив розповісти трошки про події вказівника у бравзері. Що буде, якщо клацнуть, тицьнуть, скрольнуть і поводить — розповідаю, ще й показую на прикладах з кодом. А ще одним оком глянемо на Pointer Events. Приємного перегляду!

За підтримку й мотивацію зробити це відео дякую компанії Logitech.

https://www.youtube.com/watch?v=i0K3CMp8Ogc

#js_in_action
Pointer Events
В останньому відео про події миші я побіжно розглянув і Pointer Events, які стали логічним продовженням розвитку Mouse Events. Сьогодні ж хочу подивитися до них дещо детальніше (але не дуже).

Тривалий час, аби підтримувати пристрої з дотиком, нам доводилось користуватися одночасно двома різними інтерфейсами: Mouse Events та Touch Events. Це привносило додаткову складність та могло призводити до прикрих багів та халеп, найпростішою з яких було просто забути продублювати логіку.

І ось у 2013 році Microsoft, на диво для всіх, зробила щось неочікуване: створила Pointer Events — єдину модель взаємодій для всіх типів вказівників. Згодом її стандартизували у W3C, а нині її підтримують усі сучасні браузери, включно з Safari.

Що таке Pointer Events
Pointer Events — це уніфікована модель DOM-подій, у якій поняття "вказівник" (pointer) охоплює мишу, дотик та стилус. Замість трьох різних наборів подій ми маємо одну логічну систему:

element.addEventListener('pointerdown', e => {
  console.log(e.pointerType, e.pressure);
});

Події pointerdown, pointermove, pointerup, pointerenter, pointerleave працюють однаково для всіх пристроїв.

У кожної взаємодії є власний pointerId (щоб відстежувати кілька дотиків), pointerType ("mouse" | "touch" | "pen"), pressure (сила натиску), а також координати, кнопки, модифікатори — поєднуючи класичні MouseEvent та специфічні для дотиків властивості.

click, до речі, лишили як універсальну подію.

Один код — усі пристрої
Основна перевага Pointer Events — універсальність. Можна реалізувати drag’n’drop, малювання або будь-який інший інтерактив без окремих костилів для миші та дотиків.

Якщо користувач натискає пальцем, викликається pointerdown; якщо мишею — теж pointerdown.

Для мультитачу кожен дотик має свій pointerId, що дозволяє легко опрацьовувати складні жести чи визначати кількість активних точок.

Крім того, Pointer Events підтримують так званий pointer capture — механізм, який дозволяє "прив’язати" вказівник до елемента навіть після того, як курсор або палець вийде за його межі.

element.setPointerCapture(e.pointerId);

Тонке налаштування
Бравзери, що підтримують Pointer Events, усе ще генерують події миші (mousedown, mouseup, click) для сумісності.

Тобто при торканні кнопки може спрацювати і pointerdown, і mousedown. Якщо ви вже перейшли на нову модель, це може призвести до непотрібного дублювання.

Розв’язання просте: якщо викликати event.preventDefault() на pointerdown, браузер не згенерує певні сумісні мишачі події (принаймні для touch і pen). Але це стосується лише "контактних" подій на кшталт mousedown. Події штибу mousemove чи mouseenter в такий спосіб, на жаль, не блокуються.

Також системну взаємодію на кшталт zoom та panning через JS взагалі неможливо перехопити, лише за допомогою CSS:

canvas {
  touch-action: none; /* вимикає зум і прокрутку */
}

Mouse vs Pointer — що вибрати?
Якщо ваш застосунок орієнтований лише на десктоп — старі події миші цілком ок. Вони простіші, і багато бібліотек досі працюють саме з ними.

Якщо ж ваш продукт має мобільну авдиторію, або ви працюєте з Canvas, жестами чи стилусом — Pointer Events однозначно кращі.

Проте, якщо у вас є специфічні кейси (наприклад, HTML5 Drag’n’Drop), де Pointer Events ще не інтегровані — можна тимчасово поєднати обидві моделі.

Щодо drag'n'drop — щоб не заглиблюватись, гляньте в спеку, вони побудовані повністю на MouseEvents, dragstart стартує після звʼязки mousedown + mousemove.

Підсумок
Не варто сприймати Pointer Events як просто "ще один API". Це логічна еволюція, що прибирає штучний поділ між пристроями й робить взаємодію у вебі дійсно універсальною.

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

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

Що почитати:
📖 W3C Pointer Events Level 3
📖 MDN: Pointer Events
📖 Chrome Developers Blog: "Pointing the way forward"

@babichdev

#коштозбір
Коротенький апдейт по нашому збору на детектори дронів для 115 бригади.

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

В общім, зараз саме час закинути 20 гривень на збір, а взагалі було б файно його закрити, бо в черзі вже інші запити від військових.

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

Дякую вам за кожен донат!

#dom_api
Не буду стверджувати, що обхід DOM-дерева є повсякденною рутиною, але іноді така потреба постає, і тоді перед нами постає вибір: або ми це робимо рекурсивно і вручну, або нормально. Питання лише в тому, що про нормальний спосіб мало хто знає. От я знаю про нього вже кілька років, а на практиці довелося використати буквально днями.

Мова йтиме про TreeWalker. Як я вже казав, про його існування я знав давно, але прикладних задач для нього не мав. Аж тут сталося цікаве співпадіння: по-перше, Дмитро Тарасенко розповідав про свою маленьку бібліотечку для скрапінгу на React+ Fwdays'25, чим нагадав мені про існування TreeWalker взагалі, і, по-друге, днями я брав участь в досить цікавому лайвкодингу, де мені довелося в прямому етері, так би мовити, вперше з цим API попрацювати. Тож в двох словах розповім про нього.

Якщо коротко, то TreeWalker дозволяє послідовно обходити дерево вузлів DOM. Але є кілька дуже важливих нюансів. Перше, можна фільтрувати тип вузлів за власними правилами. Друге — він не обмежує нас в напрямку руху обходу, на відміну від рекурсії.

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

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

Виглядає ініціалізація приблизно так:

const walker = document.createTreeWalker(
  // корінь обходу
  document.body,
  // тип вузлів, які враховуємо
  NodeFilter.SHOW_ELEMENT,
  // кастомний фільтр
  {
    acceptNode(node) {
      return node.tagName === 'P'
        ? NodeFilter.FILTER_ACCEPT
        : NodeFilter.FILTER_SKIP;
    }
  }
);

і потім перебираємо як нам до вподоби:

let node = walker.currentNode;

while (node) {
  console.log(node.tagName);
  node = walker.nextNode();
}

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

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

Найчастіше TreeWalker використовується тоді, коли потрібний саме обхід дерева, а не просто querySelectorAll. Наприклад, коли нам потрібно знайти фрагменти дерева, що відповідає певній структурі, чи елемент за певними правилами, які не можна описати селектором. І так, на відміну від querySelector*, він дозволяє обходити саме вузли, не лише елементи.

Звичайно ж, без підводних каменів нікуди. По-перше, TreeWalker не бачить Shadow DOM. Ну, на те він і Shadow, звичайно.

По-друге, фільтр acceptNode викликається для кожного вузла, тому при великому DOM варто уникати зайвих перевірок.

І, по-третє, TreeWalker працює з живим DOM, тому, певно, варто уникати операцій з деревом під час обходу, інакше він може несподівано затягнутись.

TreeWalker — це маленький, але дуже потужний API. Він дозволяє пройтись DOM не "згори донизу", а саме так, як тобі зручно, дозволяючи самотужки задавати правила, перестрибувати від сусідів до сусідів, від батьківських вузлів до дочірніх і усе це — з кнопками "play", "pause", "rewind" і "forward" прямо з коробки. Така собі міжпросторова рекурсія з подорожами в часі (так, я полюбляю безглузді метафори).

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

Що почитати:
📖 MDN: TreeWalker
📖 MDN: NodeIterator

Що почитати душнілам:
📖 W3C: Document Object Traversal
📖 WHATWG: TreeWalker

P.S. Товариство, детектори дронів самі себе не куплять, запрошую закинути пару гривень на збір.

А я, між іншим, вже 14 років щабадабадабадабадада. З них щонайменше 5 алалалалалалала.

Як вважаєте, варто податися?

Щойно записав нове відео, що вийде на Геловін. Про що? Не буду відкривати усі таємниці, але вам від нього однозначно стане моторошно і ви точно почнете остерігатися слова "рефакторинг"… Бу!

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

Дякую за кожен ваш внесок, товариство!

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

Завтра буде трошки моторошно на ютубі. Бо підготував для вас страшні, кринжові і страшно кринжові історії про веброзробку.

А от щоб мені не було страшно прикро, хотілося б, щоб збір на детектори дронів для 115 бригади на Покровський напрямок хоча б трошки заворушивсь.

Наразі зібрано 26 062 гривні з необхідних 51 000. Буду вдячний за кожну гривню!

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

P.S. До речі, всі ж тут підписані на youtube.com/@babichweb ? Правда? ПРАВДА?!

Вітаю, товариство!

Чи готові ви лякатися, як ніколи в житті? Чи здатні ви постати перед надприродним жахом? Чи будете ви спроможні писати код і далі, знаючи, які моторошні наслідки він може спричинити?

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

Готові? Тоді не гаймо часу, моторошні історії про веброзробку чекають на вас!

https://youtu.be/XUwYZw48CXY

Senior Frontend. Запис ОНЛАЙН з живою авдиторією завтра. Не забудьте.

Проясню щодо реєстрації: вона треба, щоб ви собі додали подію до календаря і не забули про неї. Більш ніякої мети у неї нема. Я завтра перед записом скину сюди пряме посилання на ОНЛАЙН студію, бо вхід відкритий.

І я прямо дуже раджу прийти саме на запис. По-перше, ви так само зможете душнити в чаті. По-друге, разом з партнером ексклюзивно серед глядачів наживо ми розіграємо крутезний подарунок — рюкзак просто бомба. І розіграємо його за донати на ЗСУ. Раптом ви забули, у нас з вами збір іде.

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

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

📆 РЕЄСТРАЦІЯ НА ЗАПИС НОВОЇ СПІВБЕСІДИ

***
Партнером цього випуску є Universe Group — компанія, що створює технологічні бізнеси й перетворює ідеї на глобальні продукти. До групи входять Guru Apps, FORMA та Wisey — команди, чиї рішення об’єднують понад 200 мільйонів користувачів у 186 країнах світу, спрощуючи щоденні процеси та відкриваючи нові можливості для розвитку. Окрім цього, Universe Group розвиває власний R&D-центр, який досліджує нові ідеї, впроваджує інноваційні рішення та запускає бізнеси, здатні масштабуватися на глобальному технологічному ринку.

Вакансії Universe Group

Знаєте, як називається, коли тобі приходить пул-ріквест на 5000 рядочків, написаний без дотримання конвенцій?

«Review та стогну».

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

Важливо розрізняти, коли щось deprecated, а коли — obsolete чи removed. Наприклад, такі теги, як <font>, <center> чи <menuitem> — deprecated, вони можуть частково підтримуватись якимись бравзерами для зворотньої сумісності. Вжиток таких тегів втратив сенс через появу CSS, але їхнє використання в більшості своїй не сильно шкодить.

А от, до прикладу, <keygen> чи <applet> видалено зі специфікації повністю, і бравзери їхній функціонал не підтримують, навіть для зворотньої сумісності, бо ця підтримка ставить під сумнів кібербезпечність сторінки.

Коротко життєвий шлях HTML-тегу виглядає приблизно так: Proposed → Living Standard → Deprecated → Obsolete → Removed. Їхню ж долю вирішують WHATWG разом з W3C.

Приблизно причини депрекації можна розділити на такі умовні групи:

Представлення проти семантики.
HTML подолав шлях від того, як сторінка виглядає, до того, що означають її складові. Тому певні теги набувають статусу deprecated через те, що їхня роль тепер виконується CSS. Прикладом можна навести ті ж <font>, <center>, <marquee> та інші.

Безпека та підтримка
Деякі теги були покликані розширити функціонал сторінки та надати можливість декларативно його описувати. Але те, що на папері виглядало як чудове рішення, іноді на практиці ставало справжнім пеклом для підтримки. А часом — і суттєвою діркою в безпеці, як той самий <keygen>. Він був покликаний створювати public-private пару ключів у бравзері та надсилати публічний ключ при сабміті форми. Що ж могло піти не так? Питань, насправді, на практиці, виникло багато: різні бравзери могли генерувати ключі різної надійності, за бажання зловмисний код міг спокійно вставити власний <keygen> у сторінку, непрозорий механізм, відсутність API для керування ключами та інші.

Кращі альтернативи
Іноді призначення старого тегу ставало частиною ширшої специфікації нового, як у випадку з acronym, який рекомендується заміняти на abbr.

Чому нам важливо дотримуватися рекомендацій специфікації? Я знаю, бравзери відображають наші сторінки незалежно від того, чи дотримані найостанніші стандарти, а чи у вас там вилито три баняки div-супу. Але не варто забувати про асистивні технології, те саме SEO, та взагалі передбачуваність розмітки. Якщо ви раптом вирішите використати <center> для розмітки якоїсь центральної секції, ніхто не може гарантувати, що усі бравзери викинули його зворотню підтримку, і якийсь із них раптом не почне центрувати текст.

Так само це може перетворитися на "тихий" технічний борг, бо хто ж звертатиме увагу на якийсь там HTML? Але це може потягнути за собою такі самі "тихі" баги: відображення елементів може відрізнятися, ба більше, бравзери можуть включити quirks-mode, який може зламати ще більше.

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

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

До речі, зʼявилися думка присвятити цей тиждень HTML та зробити короткий огляд його основних версій, а також розібрати, чому світ ніколи не побачить HTML 6. Дайте знати в коментарях, чи хотіли б ви почитати про це якомога скоріше.

І не забувайте про вподобайки. І про донати на детектори дронів для 115 бригади на Покровський напрямок.

Всім цьом у лобіка і гарного початку тижня.

@babichdev

Товариство, тут, виявляється, відкрили подачу заявок на Премію DOU 2026.

Номінації цього року такі:
— Найпотужніша ініціатива від ІТ-компанії, що наближає перемогу
— Найпотужніша ініціатива від ІТ-спеціалістів, що наближає перемогу
— Найперспективніший проєкт у Defense Tech галузі
— Найкраща ініціатива, яка сприяє розвитку ІТ-галузі
— Найкраща соціально орієнтована ІТ-ініціатива
— Вони — надихають
— Стартап з найбільшим потенціалом

Подати свій проєкт, кандидатуру чи подати когось можна тут:
https://forms.gle/Rsq6TvjG2yLA7JRj7

Я, як і минулого року, свою кандидатуру не подаватиму. Якщо товариство вважає, що я усе ще гідний нагороди, то товариство скаже своє слово )

#css_in_action
Чи стикалися ви колись із тим, що задаєте елементу z-index: 9999, а він усе ніяк не хоче вигулькувати поверх іншого елементу? Якщо так, то вітаю — ви побачили, як на практиці працює stacking context.

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

Давайте розглянемо ось таку структуру для прикладу:

<div>1</div>
<div id="stack-1">
  <div>2</div>
  <div>3</div>
  <div>4</div>
  <div id="stack-1-1">
    <div>5</div>
    <div>6</div>
  </div>
</div>
<div id="stack-2">
  <div>7</div>
  <div>8</div>
  <div id="stack-2-1">
    <div>9</div>
    <div>10</div>
  </div>
</div>

А тепер уявіть собі стос папірців. Цей стос буде представляти відображення усіх елементів з числами всередині (але не самі елементи, це важливо). Отой stacking order визначатиме порядок цих папірців у стосі. За замовчуванням він відповідатиме порядку й вкладеності цих елементів в DOM. Проте, якщо, до прикладу, листку з номером 8 призначити z-index: 1, він одразу переміститься наперед.

Чому? Для цього треба зрозуміти, як саме визначається порядок всередині контексту. Так от, шари контексту впорядковуються наступним чином:

1. Фон і бордер елемента, що створює контекст;
2. Елементи з негативним z-index;
3. Блоки без позиціонування (static);
4. Елементи з z-index: auto;
5. Елементи з додатним z-index (у порядку значень).

А тепер нехай ми задамо елементу #stack-2 position: relative. Ми побачимо, що восьмий папірець уже не опиняється з самого верху стосу. Чому? Бо ми перетворили #stack-2 на прозорий файлик, і тепер папірці в ньому можуть змінювати свій порядок лише всередині нього. Ми створили новий stacking context.

Насправді, створити його набагато легше, ніж нам здається. Окрім усім відомого position зі значенням, відмінним від static (і то з умовами), до утворення нового контексту може призвести використання різноманітних стилів, про деякі з них ви й не могли подумати, що вони здатні на подібне.

Наприклад, елементи, що мають z-index (не auto) та знаходяться всередині flex чи ґріду. Або з mask. Чи з container-type з певними значеннями (не всіма!). Найпідступніше, напевно, це opacity зі значенням менше 1. А повний перелік умов можна буде знайти за прикріпленим посиланням нижче.

На сторінці завжди існує щонайменше один такий контекст, утворений кореневим елементом. І, що очевидно, ці контексти можуть вкладатися один в один, як ті самі прозорі файлики з папірцями. Це завжди варто мати на увазі, бо навіть найбільший z-index не зможе вирватися за межі свого контексту.

Тому найпершою порадою буде не зловживати position: absolute та особливо z-index, і вживати інших заходів для керування розташуванням відображення. Якщо ми говоримо про модалки та тултипи, то краще за можливості використовувати той самий dialog для модалок та властивість popover для других. Якщо показувати ці елементи за допомогою API showModal, showPopover, то вони тоді рендеряться в так званому top-layer, і відпаде потреба вручну керувати їхнім розташуванням.

В двох словах — слідкуйте за stacking context та памʼятайте, що загорнути купку елементів у файлик на ділі дуже просто, але — не завжди очевидно.

Що почитати:
📖 MDN: Stacking context
📖 MDN: Understanding z-index
📖 MDN: Top layer

Що почитати душнілам:
📖 W3C: z-index
📖 CSSWG: Containment Module Level 3

Як і завжди, з мене цікавий допис, а з вас вподобайка, поширення і донат на детектори дронів для 115 бригади на Покровський напрямок.

@babichdev

Доброго ранку, товариство.
Хочу нагадати, що у нас досі триває збір на детектори дронів для 115 бригади на Покровський напрямок.
Детектори необхідні для встановлення на бензовози, що завправляють важку техніку на передовій.

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

Наразі зібрано 32 456 гривень з необхідних 51 000. Буду вдячний за кожну гривню!

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

Не забуваймо, чому і для чого ми проводимо збори.

#думки_вголос
Де межа між фреймворком та бібліотекою?
Суперечка про те, чи є той же React фреймворком чи простою бібліотекою, точиться уже давно і з перемінним успіхом. Вона не така затята, як таби проти пробілів, але усе ж.

І цікавим аспектом є те, що в сучасній веброзробці поняття UI-бібліотеки стає дедалі розмитішим. Навіть в часи перших версій React не можна було б назвати чистою бібліотекою. Але й до фреймворка він не дотягував. Не дотягує він і досі, але різниця усе меншає.

Наприклад, той самий Inversion of Control. Якщо коротко, то це принцип, коли контроль за виконанням нашого коду передається зовнішній системі. І в React цей принцип певною мірою закладено ще з найперших версій.

Ми пишемо логіку рендеру та композиції. Однак ми не контролюємо життєвий цикл компонентів, не маємо влади над побудовою Virtual DOM, не впливаємо на те, як і коли саме викликаються хуки. Усе це виконується згідно внутрішньої логіки React і контрлюється саме ним.

Чи робить це React фреймворком? Тверде ні. Фреймворк це набагато складніше поняття, і його головний аспект — диктатура. Він диктує структуру та підходи. Він задає жорсткі рамки. І, що головне, фреймворк надає інструменти для забезпечення усіх цих обмежень.

Тому Angular — фреймворк. Попри те, що він дозволяє користуватися різними бібліотеками для розширення функціоналу, його ядро є незмінним. Роутинг, модульність, компоненти, модель роботи з даними — задано на рівні системи і є самодостатнім набором, аби будувати повноцінні застосунки.

React же з коробки вміє лише генерувати HTML і пропихувати пропси. Це якщо розглядати його в першому наближенні. Звичайно, якщо підійти до задачі нетривіально, то можна взагалі без зовнішніх залежностей створити робочий застосунок, і навіть із роутингом. Але, повірте, не варто, я свого часу розплутував такий код, переводячи його на роутер, і здається мені, що автор його не міг спати через гикавку кілька місяців то точно.

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

Але не реактом єдиним. Візьмемо, до прикладу, Vue. Це бібліотека чи фреймворк? Ви можете почути обидві відповіді. І, що цікаво, обидві будуть вірні. Адже самі автори визначають Vue як прогресивний JavaScript-фреймворк, де прогресивність означає не те, що він стоїть на чолі прогресу, а те, що його функціонал може варіюватися в залежності від ваших потреб.

Тобто Vue може працювати як проста UI-бібліотека, якщо це покриває ваші запити, а може бути потужним фреймворком з усім необхідним вбудованим функціоналом. І така поведінка залишає питання що є UI-бібліотекою, а що фреймворком, ще відкритішим.

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

На мою думку, важливо розуміти, що таке система, що таке її компоненти, і бачити їхні звʼязки без привʼязки до конкретних інструментів. Це означає, що застосунки на Angular та React мають виглядати для вас ідентично, якщо вони імплементують ідентичну систему. Тут стає трохи заплутано, розумію.

Ми маємо вміти розділяти наш код на абстракції. Бачити не react-компонент чи angular-компонент, а шар представлення. Бачити не redux-store чи ngrx-store, а шар даних. І так далі. Розуміти що таке MVC чи MVVM. І головне — бачити схоже в різних імплементаціях.

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

(цей допис — субʼєктивний настільки, наскільки це може в принципі бути)

@babichdev

***
З вас вподобайка з коментарем. І ще б пару гривень на збір на детектори дронів для 115 бригади на Покровський напрямок.
Дякую, і гарного вам усім початку тижня!

Дружнє нагадування про збір на детектори дронів для 115 бригади на Покровський напрямок.

Наразі зібрано 36 886 гривень з 51 000.

Лишається зібрати 14 114 гривень.

Дякую за кожну гривню!

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

Товариство, цей збір закрито! Незабаром почнеться наступний.

#css_in_action
Усі ми чудово знайомі з media queries — способом змінювати певні стилі в залежності від ширини вʼюпорту. Ще з 2001 року ми мали можливість визначати стилі для різних типів медіа, правда, без звичної на сьогодні гнучкості: просто screen чи print.

Але вже з 2002 року розпочалася робота над Media Queries Level 3, і підтримка так званих брейкпоінтів зʼявилася спочатку в Opera 7 2003 року, а трошки згодом її підхопили Safari 3, Firefox 3 та Chrome 1.

Проривом у використанні цього підходу можна вважати статтю Ітана Маркотта Responsive Web Design, що вийшла 2010 року та закріпила термін responsive design як один з головних підходів до побудови інтерфейсів.

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

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

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

Ідея container query зародилася ще 2009 року, але тривалий час перебувала лише ідеєю, не в останню чергу через технічні обмеження того часу. Адже це вимагало б постійної перевірки стану контейнерів та їхніх нащадків, що могло також призводити до нескінченних циклів. Тому роботу відклали майже на десятиліття, і лише 2018 року почалися перші цікаві досліди Google з ідеєю "Element Queries".

Це призвело до компромісної ідеї: до специфікації вводиться поняття CSS Containment, яке дозволяє обмежити вплив елемента на layout і тим самим зробити container queries можливими. І вже 2021 року в Chrome Canary зʼявляється перша підтримка @container.

Подальше прийняття відбулося фактично в два етапи: спочатку у червні 2022 року Chrome та Edge 105 впроваджують повну підтримку фічі (з очевидних причин ми якось пропустили цю новину), а згодом до них приєднуються Safari 16 та Firefox 110.

Якщо коротко, то за допомогою container query ми можемо визначати стилі для нащадків контейнера в залежності від його розмірів. Що цікаво, не лише від ширини, а й від висоти. Синтаксис простий, мінімально ми задаємо контейнеру його тип:

.card {
  container-type: inline-size;
}

А в запиті реагуємо на задані умови:

@container (min-width: 400px) {
  .card-content { display: grid; }
}

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

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

Що почитати:
📖 MDN: @container
📖 MDN: container-type
📖 MDN: container-name

Що почитати душнілам:
📖 CSS Containment Module Level 3 (W3C Draft)

@babichdev