Що ви зазвичай робите, коли треба сабмітнути форму? Дайте вгадаю. У вас є кнопка, на яку повішено onClick, і десь усередині в кращому випадку викликається form.submit(). В гіршому дані ви збираєте ручками. І валдуєте ручками. Зізнайтеся. Навіть якщо ви користуєтесь бібліотекою для форм, структура приблизно та сама.

Ну а якщо ваша кнопка знаходиться не всередині форми, а поза нею, то, відчуваю, я правий на всі 100%. Бо фреймворки привчили нас не думать, а вирішувати усі задачі в один звичний спосіб, хоча завжди існують гнучкіші підходи.

Як і існують можливості самої платформи, як то вбудоване HTML API, чи ті ж фокуси з CSS. До прикладу, як вирішити питання з кнопкою поза формою, щоб на неї не вішати взагалі ніяких обробників? Елементарно:

<form id="form" onSubmit={…}>…</form>
<button type="submit" form="form">
  Зберегти
</button>

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

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

І таких прикладів безліч. У HTML є <details> і <summary>, які дають розкривні блоки без жодного JS — ідеальні для табів, акордеонів, спойлерів. Є <dialog> із декларативним станом. Є form.reset(), який робить саме те, що написано. Просто, надійно, без костилів.

Тому кожного разу, коли рука тягнеться до addEventListener, зупиніться. Може, цей сценарій уже реалізовано в HTML або CSS — просто ви про нього не знали. Або знали, але забули. Чи забили.

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

P.S. Це не про You Might Not Need JS, який безбожно вже застарів, це про здоровий ґлузд та знання платформи, якою ви користуєтесь щодня.

🔥 Дивовижний світ веброзробки

1000!
Ми перетнули позначку в 1000 підписників — і хочеться відзначити це маленьким подарунком. А який подарунок тут має справжню вагу? Правильно — знання.

Часом ви питаєте мене: як я стежу за всім, що відбувається у вебі? Як примудряюся бути в курсі? Відповім чесно: бути в курсі всього — неможливо. Але те, що знаю — значною мірою дякую ось цим джерелам. І ними я хочу сьогодні поділитися.

Frontend Focus
Розсилка, зосереджена на новинах про фронтенд загалом. Таке собі "Все про все", і часто перетинається з іншими, більш спеціалізованими листами, однак як точка входу до дайджесту новин підходить чудово.

CSS Weekly
Новини CSS, приколи CSS, статті про CSS. Це очевидно, тому нема сенсу пояснювати, про що ця розсилка.

JavaScript Weekly
Так само, не бачу причин детально розписувати, про що цей лист. Новини, статті, релізи — усе в одному місці.

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

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

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

web.dev
Віднедавна також я почав напряму читати блоґ від web dev, в якому публікуються дуже корисні зведення нових фіч, оновлення Baseline та інші цікаві новини.

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

***
Це мій список — але створіть свій. Знайдіть авторів, які вам пасують. Підписуйтесь на ті розсилки, які вас розвивають. А може, колись заведете й власну — і вже вас хтось згадає в такому ж дописі.

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

Підписуйтесь і на мене:
⚙️@babichdev
.

Бачили вже нову "магічну" фічу у React 19 — View Transition? А знали, що це усього-навсього обгортка над цілком собі бравзерним API? Як ні, то я вам трошечки зараз розповім.

У всіх бравзерах, окрім, очевидно, Firefox, можна користуватися не таким уже й новим View Transition API, яке, по суті, дозволяє створювати красиві анімації переходу між станами сторінки без застосування складних бібліотек.

Під капотом усе настільки просто, що аж трохи нудно. Коли ви ініціюєте View Transition, бравзер просто робить знімок поточного вигляду сторінки, потім — нового стану (після оновлення DOM або переходу на інший документ), і між цими двома “картинками” програє анімацію.

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

Це можна зробити або за допомогою CSS, задаючи анімацію як усій сторінці, так і певним її регіонам:

.fade {
  view-transition-name: fade;
}

::view-transition-old(fade) {
  animation: fade-out 0.3s ease;
}

::view-transition-new(fade) {
  animation: fade-in 0.3s ease;
}

Або за допомогою JavaScript:

document.startViewTransition(() => {
  // оновлення DOM
});

React у цьому плані нічого кардинально нового не вигадує. Він просто пропонує синтаксичний “цукор” у вигляді функції startViewTransition та експериментального компонента unstable_ViewTransition. По суті — той самий document.startViewTransition() під капотом.

import { unstable_ViewTransition as ViewTransition } from 'react';

<ViewTransition>
  <div>...</div>
</ViewTransition>

Попри те, що View Transitions поки підтримуються лише в Chromium-бравзерах — таких як Chrome, Edge чи Opera — це не причина уникати їх використання. У бравзерах без підтримки (наприклад, Firefox) анімації просто не спрацюють, якщо задавати їх через CSS, ну а для JS треба просто перевіряти підтримку фічі. Тобто функціональність залишається незмінною, а View Transitions виступають як прогресивне покращення. Їх можна сміливо впроваджувати вже зараз, не хвилюючись про деградацію UX.

За вподобайки й поширення окремо нагадати, чи самі все знаєте?

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

🔗 MDN
🔗 Smooth transitions with the View Transition API
🔗 React <ViewTransition>

@babichdev

.

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

І це — Element.matches, який просто перевіряє елемент, на якому він викликаний, на предмет відповідності селектору:

<div class="container">
  <div class="my-element"></div>
</div>

<noscript>
el.matches('.container .my-element'); // true
</noscript>

Якщо повного співпадіння не буде, то й поверне він false:

el.matches('.container'); // false

На відміну від closest, matches перевіряє суто цільовий елемент і не шукає інших збігів. Звичайно, якщо обом методам дати однаковий і точний селектор — обидва спрацюють позитивно. Але якщо селектор “не точний”, closest цілком може повернути когось із батьків, а от matches скаже чітке “ні”.

Поки ми тут, не забудьте поставити вподобайку та поширити допис ;)

Що цікаво, обидва методи працюють зі складними селекторами, включно з псевдокласами, тобто чудово справляться з отаким:

:not(.container:first-child):hover .my-element

Але у випадку з тим же :not можуть бути нюанси. Коли я бавився з цим прикладом, то селектор вище чудово спрацьовував, а от ось такий:

.container:not(:first-child):hover .my-element

уже чомусь ні, хоча в CSS цей селектор працює без проблем

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

Звичними нам методами це вимагало б купу переборів DOM і перевірок, а так — один кучерявий селектор і справу зроблено!

Підтримується абсолютно всіма актуальними бравзерами і є частиною Baseline.

🔗 MDN

⚡️@babichdev

***
P.S. До речі, ви вже взяли участь в розіграші квитка на DOU Day усього за 500 гривень? Якщо ні — не зволікайте!