Нещодавно я розповідав про такий метод 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