Бачили вже нову "магічну" фічу у 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 гривень? Якщо ні — не зволікайте!

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

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

Очевидно, що таблиця не підійде (але я б її не взяв і так). Тому вибір очевидний — CSS Grid.

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

І тут я згадав про subgrid:

.container {
  display: grid;
  grid-template-columns: min-content 1fr;
}

.card {
  display: grid;
  grid-template-columns: subgrid;
}

Тут нюанс — якщо між головною сіткою і "наслідувачем" є обгортки, їм усім треба так само “прокинути” цю сітку:

:where(.wrapper-1, .wrapper-2, …, .wrapper-n, .card) {
  display: grid;
  grid-template-columns: subgrid;
}

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

.card {
  height: max-content;
}

Voila! — картки в сітці кожна має свою власну висоту!

І от коли все стало на свої місця, клацнуло як останні детальки LEGO, от тоді я й відчув ту мимолітну ейфорію, про яку писав.

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

🔔 Тим часом розіграш квитка на DOU Day усього за 500 грн відбудеться уже сьогодні ввечері! Тож не зволікайте, аби не впустити таку нагоду!

@babichdev

.

#цього_тижня

— Зазирнули по той бік ViewTransition у React і зʼясували, що це всього-на-всього обгортка над браузерним View Transition API.

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

— Розібрали, чим корисний метод Element.matches() і чим він відрізняється від Element.closest().

— Я поділився, які маленькі речі приносять мені справжнє задоволення в коді.

— А наступного дня показав, який саме код надихнув мене на попередній допис.

✨ А ще — разом з вами ми зібрали 25 642 грн на користь ЗСУ!

Який із дописів цього тижня сподобався вам найбільше? Напишіть у коментарях 👇

👍@babichdev

.

Що приховують три крапки?
Вітаю, друзі! Сьогодні розповім вам про деякі неочевидні підводні камені так званого spread-оператора. Я сподіваюсь, ви вже в курсі, для чого він існує, тож перейду відразу до прихованих нюансів.

Порядок важливий
Коли ви "підмішуєте" обʼєкт, то значення будуть застосуватись в порядку додавання в новий обʼєкт:

{ a: 1, b: 2, ...{ b: 3 } } // { a: 1, b: 3 }

{ ...{ b: 3 }, a: 1, b: 2 } // { a: 1, b: 2 }

Останнє входження ключа перезаписує попереднє. Spread — це не злиття, а послідовне копіювання полів з обʼєктів у новий.

undefined в масивах і обʼєктах
Ви спокійно можете розгорнути той же undefined або null в обʼєкт, а от з масивом такий трюк не пройде.

{ ...undefined } // {}

[...undefined]   // 💥 TypeError

Усе через те, що масив вимагає, аби вхідний обʼєкт був Iterable, тобто такий, яким можна пройтися з Symbol.iterator, і nullish значення, очевидно такими не є. А от звичайний обʼєкт не такий вибагливий, і йому достатньо будь-якого значення, до якого можна застосувати Object.keys. У випадку з null та undefined цей метод просто поверне порожній список.

Object ⇄ Array? Ні.
Рівно з тієї самої причини ми можемо розмазати масив в обʼєкт, але не можемо зробити навпаки:

[...{ a: 1 }] // 💥 TypeError: object is not iterable

{ ...[1, 2] } // { 0: 1, 1: 2 }

Spread у масиві очікує ітерабельність — тобто наявність Symbol.iterator. Обʼєкти цього не мають (за замовчуванням), тому розгортання летить з помилкою.

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

... не любить порожнечі

const a = [1, , , , 5]; // [1, empty × 3, 5]
const b = [...a]; // [1, undefined, undefined, undefined, 5]

console.log(1 in a); // false
console.log(1 in b); // true

Spread-оператор не просто “копіює” масив — він перетворює його дірки на явно присутні undefined.

У масиві a на індексах 1, 2, 3 немає значень — це так звані дірки (sparse elements). Але при ...a вони ущільнюються: JavaScript вставляє на їхнє місце undefined, і ці індекси стають реально присутніми в структурі масиву.

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

const original = {
  value: 1,
  nested: { deep: true },
};
const copy = { ...original };

copy.nested.deep = false;
console.log(original.nested.deep); // false

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

***
Якщо дізналися щось нове — напишіть у коментарях, що саме здивувало чи стало у пригоді.

А далі — обирати вам! Про що буде наступний допис?

🔥 — Дірки в масивах: як вони зʼявляються і що ламають
❤️ — Symbol.iterator: ітерабельність під капотом
🤔 — Чи настільки різні масиви та обʼєкти?

✅@babichdev
.

Порожнеча дивиться на тебе.

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

let arr = ['one', , 'three'];
// ['one', empty, 'three'];

arr[100] = 'value';
// ['one', empty, 'three', empty × 97, 'value']

Дірка — не undefined! Хоча при звертанні до "дірки" вам і поверне undefined, насправді в самому масиві його не буде. Дірка означає повну відсутність значення за індексом, він просто не ініціалізований. Це випливає з того, що масив — це підвид обʼєкту, просто з певним інтерфейсом для впорядкування ключів.

По факту, масив з діркою, наприклад той самий ['one', ,'three'], у обʼєктному записі виглядатиме так:

{ 0: 'one', 2: 'three' }

Індекс 1? Його просто немає.

Дірява поведінка
Дірки поводяться по своєму, і не завжди передбачувано. Візьмемо до прикладу масив [1, , 3] та порахуємо квадрати його значень:

[1, , 3].map(x => x * x) // [1, empty, 9]

А тепер точнісінько такий масив, але замінимо дірку явним undefined:

[1, undefined, 3].map(x => x * x) // [1, NaN, 9]

Помітили різницю? Так от, map, forEach, filter, reduce, every, some просто ігнорують дірки, перестрибують їх. А for...of, for навпаки — зазирнуть у кожну дірочку.

А JSON.stringify взагалі перетворює дірки в масиві на… null.

До речі, як визначити, що це саме дірка, а не просто undefined? Перевірити наявність індекса в масиві. Якщо ключа немає, то це — дірка:

const arr = ['one', , 'three'];
1 in arr; // false

Дірка як палиця в колесі.
Така поведінка, очікувано, може призводити до багатьох дивних ситуацій, особливо при клонуванні чи порівнянні масивів. Ще більше збиватиму з пантелику той факт, що [].length віддає не фактичну кількість ключів, а "найбільший індекс + 1", що теж не додає впевнености при роботі з дірявими масивами.

Також JavaScript рушії не дуже полюбляють діряві масиви, бо робота з ними вимагає відмови від багатьох оптимізацій, які можна застосувати до безпереревних масивів. Я не буду вдаватися в деталі, лише зазначу, що це дійсно впливає і на споживання памʼяті, і на внутрішню швидкодію. Звичайно, ви не помітите різниці на масиві з десятком дірок, але якщо їх 100 000, 1 000 000, то втрати будуть відчутні.

Заштопати всі дірки!
Найочевидніша порада — не допускайте дірок. Якщо вам потрібна подібна структура, краще використати обʼєкт з власним ітератором. Якщо ж в руки потрапив такий масив, то його краще ущільнити: чи то зібрати лише реальні значення в інший масив, чи то заповнити дірки явним undefined — у будь-якому разі рушій вам подякує, а потім подякуєте і ви собі.

💬 А ви стикались із дірками в проді?
Чи, може, самі колись ненароком залишили? Поділіться досвідом у коментарях!

І якщо було цікаво — не забудьте поширити допис або кинути лінк колезі.

🔗 @babichdev
.

Синьйор мусить знати все!
Ні. Не все.

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

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

Так, є база, без якої нікуди, і яка постійно змінюється. Є зони відповідальности. Є глибина, яку справедливо очікують від розробника певного рівня. Але навіть у синьйора в голові не вміщається весь Intl API, увесь Grid, або всі edge-кейси WebRTC. І це — нормально.

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

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

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

Між “я не знаю, як дізнатися” і “я не знаю, але розберусь” — ціла прірва. І справжній фахівець — це той, хто цю прірву давно перейшов.

Ти не мусиш усе знати.
Ти мусиш вміти дізнатися.

💬 А ви як ставитеся до моментів, коли чогось не знаєте?
Чи було таке відчуття, що «мусив же це знати!» — і що з ним робили?

P.S. На fwdays за 100 гривень?! Це можливо взагалі? Я кажу — так!

🔗 @babichdev