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

#думки_вголос Що таке код-ревʼю і кому воно потрібне? Особливо сьогодні, в часи LLM, які прямо все-все можуть робити за нас.Я стикався з різними підходами, які варіюються від "нафіг воно кому треба", "ревʼювить тільки тімлід" і до "поки не отримаєш тисячу зелених галочок, твої два рядочки в стейдж не попадуть".З деякими я не погоджуюсь, деяким лишаю право на існування, деякі підтримую беззаперечно. І з плином часу мій цей розподіл змінюється. Але одне залишається постійним — я вважаю, що код-ревʼю необхідні і потрібні.В першу чергу це спосіб не пропустити сумнівні рішення не лише в кодову базу, а й у голову автора. Адже схваливши такі пул-ріквести, ми прямо кажемо — "молодець, нам норм". І якщо таке рішення проходить раз, другий, то на третій автор уже буде впевнений, що його підходи до коду — правильні.Далі — код-ревʼю це чудовий спосіб для обміну досвідом. До того ж, попри поширену думку, старші колеги теж іноді можуть чогось навчитися від менш досвідчених, але часто більш жадібних до знань розробників.Це, певно, одна з найперших порад, які я даю щодо покращення процесу ревʼю — вчіться один у одного. Код-ревʼю це чудова нагода для цього.Щодо LLM в код-ревʼю. Це прекрасний інструмент для визначення механічних хиб — потенційних багів чи відхилень від конвенцій. В цьому плані використання LLM не відрізняється від того ж лінтера чи ще якого статичного аналізатора. Усе, що може бути автоматизоване — має бути автоматизоване.Але й повністю віддати на плечі алгоритму весь процес ревʼю мені не видається можливим. Він може покрити більшість речей, які можна формалізувати, а от відкриті до дискусій питання будуть приречені на довічне лімбо "це вже майже ідеальний варіант, але…". З LLM дуже важко сперечатися, воно завжди знайде до чого доколупатися. Навіть у рішеннях, запропонованих ним же.Насправді, на мою думку, головна причина неможливості повної автоматизації код-ревʼю LLM — це відповідальність. У LLM її немає. "Так, дійсно, я пропустив цей PR. Хочеш, більше не буду його пропускати?".Тому людське ревʼю має обовʼязково бути. Це засіб для обміну досвідом, для навчання, місце для дискусій й спільних рішень.Хороше код-ревʼю має шукати відповідь на питання "Чому автор зробив саме так?". Не "чому тут let а не const", не "Boolean() vs ||", чи ще якесь технічне душнільство, яке має бути знайдено пайплайном. А саме "Чому автор обрав цей шлях?".Хороше код-ревʼю заохочує. До дискусії, до обміну знаннями, до професійного росту.Хороше код-ревʼю — спільна справа. Джуни мають ревʼювати техлідів, так само як і мідли — синьйорів. Одним словом — усі мають ревʼювати усіх.Хороше код-ревʼю важко зробити. Погане — взагалі не вимагає зусиль. Тому я часто чую історії про те, що ревʼю проводить тільки техлід за попереднім записом, чи що джуни не ревʼювлять нікого, зате їх — усі. І так далі.Код-ревʼю — це точка росту не лише для одного розробника, а й для усієї команди, продукту.P.S. Цієї середи, до речі, відбудеться онлайн-зйомка "Вайбкод-ревʼю для трейні". Деталі згодом ;)

#html_in_action Тривалий час сценарій взаємодії з кнопкою був дуже простий — ми вішаємо event listener на натискання і "обробляємо" його — виконуємо якусь логіку, викликаємо якийсь функціонал чи змінюємо стан елементів. По суті, кнопка завжди виступала як ініціатор дії, але при цьому знала забагато про цю дію.Зараз же зʼявилась можливість змінити цей підхід на декларативний в певних випадках. Мова йде про Invoker Commands API.Якщо коротко, то це дозволяє зробити кнопку декларативним тригером, який не знає про те, яку саме логіку він запускає. Його обізнаність обмежується лише командою, яку треба передати, і пунктом призначення, який цю команду отримає. Виглядає це так:<button command="..." commandfor="..."></button> Де command це імʼя команди, яку ми передаємо, а commandfor має відповідати id елемента, якому цю команду призначено. Ви вже могли бачити деякі приклади, наприклад, відкриття dialog через команду show-modal.Це, насправді, одна з суттєвих переваг цього API — для вбудованих команд тепер не потрібен JS взагалі, як в тому ж прикладі з dialog.Важливо зрозуміти, що обробка цих команд відбувається не на кнопці по натисканню, а саме на *target* — самим бравзером для вбудованих команд, або користувацьким кодом для кастомних команд. Це дещо інша парадигма, ніж звична нам обробка кліку. Тепер сам елемент відповідає за логіку всередині себе, а кнопка лише передає команду.До речі, так, саме *передає* напряму, а не *транслює*. Одна кнопка може передати команду лише одному цільовому елементу. Тому, до речі, подія command не спливає, і викликається виключно на самому елементі.І Invoker Commands API підтримує користувацькі команди, які визначаються через знайомий уже нам префікс --. Ось приклад:<button command="--toggle" commandfor="target"> TRIGGER</button><p id="target">TARGET</p> document .getElementById('target') .addEventListener('command', event => { if (event.command === '--toggle') { event.target.classList.toggle('foo') }}) Демо на JSFiddleЯк бачимо, саме елемент параграфу відповідає за зміну свого стану, а кнопка лише передає команду в момент натискання. До речі, обʼєкт події тут — CommandEvent, а не PointerEvent. Окрім command можна дізнатися, хто саме відправив команду через властивість source.Ми можемо мати скільки завгодно тригерів, але лише один цільовий елемент. Тобто нашим target може командувати безліч кнопок, але одна кнопка не може командувати більш ніж одним елементом. Звичайно, було б зручно саме транслювати команди в певних випадках, але поки як є. Можливо, згодом зʼявиться і така можливість.Поки ж Invoker Commands API уже зробив надзвичайно важливу річ — надав можливість декларативного підходу для опису взаємодії з UI. Тепер control flow виглядає логічніше: ініціатор — ціль — намір, де обробка наміру відбувається саме ціллю.Що дуже важливо — не варто сприймати це як "заміну" кліку. Також не варто відкидати це в сторону, бо "дуже мало вбудованих команд, нашо воно мені треба". Головна цінність Invoker Commands API саме у зміні парадигми того, як взаємодіють елементи інтерфейсу між собою у відповідь на дії користувача. Тобто ми передаємо обробку від кнопки до самого елемента.І для цього цей API надає зручніші, простіші й логічніші інструменти.До речі, ви вже пробували Invoker Commands API чи плануєте спробувати? Поділіться досвідом в коментарях.P.S. Не буде вподобайок — не буде дописів. Я серйозно.Що почитати:MDN: Invoker Commands APIЩо почитати душнілам:WHATWG: "command" attribute WHATWG: "commandfor" attribute@babichdev***Збір на РЕБ для 115 ОМБр: 36_871 / 300_000грн

#html_in_actionЗдається, що <button> існував завжди. Відверто, з точки зору більшости веброзробників, так і є. Цей тег зʼявився в специфікації HTML 4.0 1997 року, і старший за багатьох з моїх любих читачів.А ще ми нерозривно повʼязуємо його з формами, адже як іще можна надіслати дані з нашої сторінки, як не за допомогою <button>? І ось ці два моменти часто складаються в хибну думку, що кнопки зʼявилися в HTML разом з формами, і є їхньою невідʼємною частиною. Чому ж ця думка хибна?Річ у тім, що форми випереджають <button> на цілих два роки і дві версії HTML: вони зʼявляються в стандарті HTML 2.0 від 1995 року. І це вже спростовує другу тезу про невідʼємність кнопки від форми.А як же так сталося, і як відправлялися форми в той час? Дуже просто — input. Кнопки як окремого примітива чи сутності не було, а бідолашний інпут віддувався за все, що не було select чи textarea. І саме тоді й зʼявилися різні типи інпутів, серед яких були й submit, reset та button.До речі, про reset я й сам чи то не знав, чи то забув до цього часу. Він, виявляється, скидає стан форми до значень за замовчуванням.input цілком собі вдало виконував функції кнопки, але button, як я зазначив на початку, досить швидко зʼявився в специфікації. Не братимусь розбирати причини, але вони, як на мене, доволі очевидні з різниці між інпутом і кнопкою.Якщо дуже стисло окреслити різницю між button та input, то всередину button можна додавати розмітку, а всередину input — не можна.Тепер поглянемо на типи: submit, reset, button.submit є значенням атрибуту type за замовчуванням, і саме тому будь-яка кнопка без явного значення цього атрибуту, поміщена всередину форми, буде її "сабмітити". Я певен, що кожен з нас бодай раз стикався з цією поведінкою, і Ґуґл памʼятає саме ваш запит "button form prevent submit".Я памʼятаю, наскільки це дратувало. Але зараз розумію, що це роздратування насправді було викликано не якоюсь не такою поведінкою кнопки, а саме моїм незнанням та нерозумінням, як вона насправді працює.Виправити таку поведінку дуже просто — явно вказати type="button". І тоді наша кнопка перетвориться на… кнопку-кнопку. Саме той інтерактивний примітив, про який я говорив минулого разу. В цьому випадку бравзер прибирає з кнопки "очікувану" поведінку в контексті форм. Якщо простіше, то кнопка більше не сабмітить.Про type="reset" я вже побіжно згадав, і тут немає ніяких підводних каменів — просто скидання стану до початкових значень.Є ще один цікавий момент, про який я колись розповідав: кнопку можна звʼязати з формою через атрибут form, і тоді її можна розмістити поза нею, і все працюватиме. Так от. Виявляється, ця поведінка притаманна усім елементам форми, не лише кнопкам. Але я розберу цей курйоз іншим разом.Тож, якщо підбити підсумки:- Кнопки — логічне продовження інтерактивності, закладеної input;- Мають три значення атрибуту type: submit, reset, button;- За замовчуванням тип кнопки — submit;- Якщо треба кнопка всередині форми, що має робити щось інше, то це type="button"Але HTML не стоїть на місці, і сьогодні button вміє набагато більше, ніж сабмітити форму і бути безвольним гачком, до якого ми чіпляємо свої onClick. Про що мова? Можливо, ви вже здогадалися, тож пишіть в коментарях. А я вже готую наступний допис.MDN: button type@babichdev***Збір на РЕБ для 115 ОМБр: зібрано 30 731 / 300 000грн. Долучайтесь!

Кнопка.Будьмо відверті — мало хто з нас сприймає елемент <button> інакше, ніж просто засіб запуску якогось коду по кліку. І саме тому багато хто не бачить і різниці між кнопкою й просто дівом з addEventListener. А це, в свою чергу, призводить до хибного бачення <button> як просто клікалки з тупими стилями за замовчанням.Але це не так. Якщо заглянути далі цього сприйняття, то виявиться, що кнопка — це дещо більше. Насправді це справжній інтерактивний примітив бравзера, що не лише дозволяє себе натискати, але й володіє багатьма іншими аспектами — власною семантикою, очікуваною бравзером поведінкою, повною підримкою клавітурної взаємодії, власними правилами доступности, врешті-решт.Якщо не зважати на це уваги, розробники рано чи пізно починають займатися "цікавими дослідами" і городити те, що має бути простою кнопкою, за допомогою дівів чи спанів. А іноді — десятків дівів чи спанів. Тут примітно, що насправді дуже легко знехтувати саме <button>, адже на поверхні ми бачимо лише блок, який треба натиснути. І це чудово вміють усі інші елементи: навісимо onClick чи що у вас там у вашому улюбленому фреймворку, і задача ніби вирішується.Але згодом таке рішення часто вилазить боком, і ось розробник уже починає додавати те, що вже й так існує у простої кнопки: той самий правильний фокус, ту саму клавіатурну взаємодію, стани, а на завершення поринає з головою в імітацію доступности.Взагалі, я раджу завжди ставити собі питання — чи є вже в бравзері те, що я намагаюсь зробити? Відверто, в більшості випадків відповідь однозначна — так. Звичайно, я розумію, що навіть зараз багато нативних контролів у бравзері не надають достатніх засобів для такої стилізації, яку часто вигадують наші любі дизайнери. Чи такого функціоналу, який вигадують наші любі стейхолдери.І це підіймає доволі цікавий аспект розробки — ми часто сприймаємо інтерактивні елементи через призму того, як вони виглядають, а не що вони роблять. Несвідомо в такий спосіб ми жертвуємо і ефективністю інтерфейсу, і зручністю розробки. Бо замість того, аби узяти те, що вже працює і так, нам доводиться вигадувати колесо заново. Або кнопку.<button> в цій історії є дуже цікавим прикладом, бо цей елемент або ігнорують, або використовують замість усього, що бодай якось клікається. Так, я про <a> в якості кнопки і <button> в якості гіперпосилань. Повірте, я таке бачив на власні очі.Я спеціально не говорю про поведінку <button> в формах в цьому дописі, бо планую детальніше зупинитися на цій темі у наступному. Чому перезавантажується сторінка, якщо натиснути в кнопку всередині форми, чим це зумовлено, чому це не баг, і як зробити так, щоб цього не відбувалося — про це наступного разу.А сьогодні були просто ліричні роздуми про елемент <button> і його роль в ширшій картині Всесвіту.Просто запамʼятайте — якщо, дивлячись на дизайн, у вас виникає підсвідоме бажання тицьнути в щось мишкою, то швидше за все це звичайна кнопка, а не оріґамі з <div>.@babichdevЗбір на РЕБ для 115 ОМБр — кожна гривня важлива!

#css_in_action Навіть у 2026 році люди не перестають дивуватися, що відносні (тобто відсоткові) вертикальні margin та padding насправді рахуються не від висоти, а від ширини (насправді ширини containing block) елемента). 100% розуміння, 0% засудження — свого часу для мене це теж стало неприємним відкриттям.Тож чому так? Насправді, це один з моїх улюблених випадків, коли "так історично склалося". Той факт, що ця поведінка зафіксована в CSS2.1, не означає, що вона просто прийшла комусь в голову і її затвердили по приколу. Річ у тім, що цей документ значною мірою був радше не оновленим стандартом, а таким собі "зліпком" того, що коїлося в дивовижному світі веброзробки на той час. І саме така поведінка була вже усталеною.Існує припущення, що причина полягає в доволі складних алгоритмах обрахунку загального макету, і це було свідоме спрощення. Зазвичай ширина елемента доступна раніше за його висоту, особливо в класичній флоу-моделі, де висота залежна від вмісту. І розрахунок вертикальних відступів від ширини дозволив уникнути зациклених обрахунків в ранніх рушіях.Відверто, дуже багато речей, які здаються нелогічними чи незрозумілими в CSS, насправді спричинені ось такими непростими рішеннями, бо на світанку веброзробки доводилося шукати шляхи, аби обійти нестачу обчислювальних ресурсів та недосконалість алгоритмів. От такий hack driven development.Попри те, що такий підхід досить контрінтуїтивний, він усе ж спромігся породити бодай одне непогане рішення (читай — хак): попередника aspect-ratio, що дозволяє втілити співвідношення сторін за допомогою вертикального падингу. Про нього я вже колись розповідав.Тож якщо коротко — логічного пояснення цьому немає. Така поведінка зафіксована в специфікації, а пошук її істинних причин, відчуваю, може затягнути нас у пригоди, яким позаздрив би сам Індіана Джонс.Але лишається відкритим питання — чи можемо ми усе ж задавати відносні відступи залежно від висоти? Відповідь — нуууууууу… майже.Відносно самого елемента? Тверде ні. Відносно чогось іншого? До вибору, до кольору.Як мінімум, тепер можна використовувати vh та dvh. Так, це відносно висоти вʼюпорту, і я не дуже уявляю, кому треба такий падинг чи маржин, але суть від того не змінюється — це відносна величина, яка рахується від потрібної нам вісі.І, звичайно, сьогодні ми маємо контейнерні одиниці. cqh, cqb, cqi, cqw. Цікавлять нас cqh — 1% від висоти контейнера, та cqb — 1% від блочного розміру. За замовчуванням ці напрямки співпадають, але є нюанси при зміні напрямку письма.Проте з cq* одиницями є надзвичайно важливий момент — вони рахуються від найближчого query container, а не від безпосереднього батьківського елемента. Це, якщо спрощено. Взагалі, тема container queries доволі цікава, і беззаперечно потребує окремого допису. Що скажете?Однак на даний момент саме container query units виглядають як найбільш надійний спосіб вирішити давню проблему — задавати вертикальні відступи відносно вертикальної вісі. І щодо підтримки перейматись не варто, згідно Can I Use це майже 95% сучасних бравзерів.Взагалі, оця історія з відносними відступами чудово ілюструє те, як розвивається веб в цілому: обмеження стає домовленістю, домовленість породжує хаки, хаки стають поширеною практикою, а з часом вже платформа реагує та пропонує нове рішення у відповідь.Хотів би написати "…рішення, що робить хак непотрібним", але ми усі розуміємо, що це не так. В деяких випадках, як з aspect-ratio, хак дійсно розчиняється в небутті, але часто, як із cq* одиницями, ми отримуємо рішення, що лише частково закриває початкову проблему. Але при цьому — дозволяє вирішити ще низку проблем, про які ми й не здогадувались.Що почитати:MDN — Layout and the containing blockMDN — paddingMDN — CSS container queriesЩо почитати душнілам:W3C — CSS 2.2 Box modelW3C — CSS Containment Module Level 3@babichdev

#js_in_actionВ кожній мові програмування існує безліч способів вистрілити собі в ногу, і JavaScript — не виключення. Буквально днями мені пригадався один з таких способів, який я навіть колись (дуже давно) використовував в продакшн-коді.Мова йде про оператор with.const user = { name: "Elvira" };with (user) { console.log(name); // Elvira} Якщо спробувати пояснити це явище швидко й просто, то нічого не вийде. Але я спробую. В першу чергу нам потрібно пригадати поняття scope chain. Це ланцюжок контекстів, у якому рушій шукає змінну, до якої ми звертаємось у коді.І зазвичай мова йде про лексичні скоупи, створені або функціями, або іншими блоками коду за допомогою фігурних дужок. А with просто ніби "пристібає" свій обʼєкт у ланцюжок пошуку імен, тому всередині блоку прості звертання можуть неочікувано резолвитись у властивості цього об’єкта.with втручається саме в звертання до простих імен. Усередині такого блоку JavaScript спочатку намагається трактувати name як властивість переданого об’єкта, і лише потім шукає це ім’я далі по scope chain. Звертання через явний об’єкт, як-от user.name, цієї проблеми не мають.const user = { name: "Elvira" };const name = "Oliver";with (user) { console.log(name);} У цьому прикладі буде виведено "Elvira", а не "Oliver", тому що with змушує JavaScript спочатку шукати name у user.Вам уже мало стати очевидним, що with має набагато більше недоліків, аніж сумнівних вигод. І це правильне відчуття. Він вносить сумʼяття на усіх рівнях: людині важко зрозуміти, що ж мав на увазі автор — чи локальну змінну, чи властивість, чи змінну глобальну; рушій не може оптимізувати такий код, бо не може безпечно припускати, до чого саме посилається кожне імʼя всередині with; лінтери й інші інструменти також можуть сумніватися в тому, до чого саме звертається просте ім’я всередині блоку.Яскравим прикладом є потенційне перекриття глобальних та локальних імен:const user = { name: "Elvira", console: true };with (user) { console.log(name);} Проблема тут полягає в тому, console буде резолвитись як user.console, а не як глобальний об’єкт console. Насправді, існує механізм обходу глобальних імен через [Symbol.unscopables], але розібратися з ним я залишаю моєму цікавому читачу.Хоч with і не вилучено зі специфікації ECMAScript повністю, його використання, мʼяко кажучи, не заохочується. В strict mode він заборонений, і лишається лише як частина зворотньої сумісності.Якщо вважати, що призначенням with було спрощення доступу до властивостей обʼєкту на письмі, то нині у нас є набагато кращі й надійніші способи спрощено звертатися до таких властивостей, наприклад, та сама деструктуризація:const user = { name: "Elvira"};const { name } = user;console.log(name); Попри добрі наміри, with виявився конструкцією, що втручається в один із фундаментальних механізмів JavaScript — пошук ідентифікаторів через scope chain. І через це привносить неочікувану невизначеність, через що код стає неочевидним і складним для аналізу.Що почитати:MDN: with statementMDN: JavaScript Guide — Working with objectsЩо почитати душнілам:ECMAScript: with statementECMAScript: Object Environment RecordsECMAScript: GetIdentifierReferenceP.S. Навіщо я взагалі вирішив розповісти про таку стародавню й дивну чудасію? Бо одним з моїх принципів є чергове складне речення: "треба знати не лише як правильно, але і як не правильно, щоб не писати неправильно, не знаючи, що це неправильно".@babichdev

floatПобутує думка, що CSS float — це щось дуже застаріле, а його використання вважається ледь не богохульством. Ну бо для лейауту ж маємо і flex, і grid. І частково з цим можна погодитись — для лейауту це дійсно моветон.Але й в епоху свого розквіту цей підхід теж був не best practice, а банальним костилем через відсутність притомних інструментів.Справжнє ж призначення float просте як дрова — відтворювати типографський принцип "обтікання" зображення текстом. І все.Принцип дії також не складний — float-елемент приклеюється до лівого або правого краю контейнера, а будь-який наступний вміст бравзер намагатиметься відобразити поруч із ним. На "новий рядок" наступний вміст перенесеться з однієї з трьох причин: текстовий вміст досягне нижньої межі float-елементу, блочний елемент не вміщатиметься в доступну ширину, або ж якийсь із наступних елементів матиме відповідний clear.У сучасній верстці використання float цілком собі виправдане. Але, як завжди, за умови одного суттєвого "але" — для відтворення друкарських принципів. Для створення лейауту, як уже зазначалося вище, є спеціальні інструменти.Чого ж тоді його взагалі використовували для цих задач? Це були темні часи. Таблиці впали в немилість, сходила зірка CSS 2.1, дизайнери вигадували нові, досі небачені структури сторінок, але над усим цим бовваніла одна величезна проблема — стандарти досі сприймали html-сторінки як документи, а не як інтерактивний інтерфейс для взаємодії з вебом.Тому веброзробники зробили те, що у них виходить найкраще — вигадали новий костиль. Головною фішкою float є те, що він може виставити декілька блокових елементів в один ряд, якщо у них є ширина, та ще й без додаткових обгорток, якими по суті були таблиці. Тобто зробити їх колонками. Тож дивовижний світ веброзробки став ще дивовижнішим, і інтернет заполонили легіони сайтів із багатоколонковою структурою.Однак усе не було таким райдужним, як уявлялося. Навіть простенький лейаут на дві колонки міг несподівано розʼїхатись, якщо сумарна ширина колонок виходила бодай на нанопіксель більшою за 100%. Рахувати і прописувати ширини колонок потрібно було вручну, і розробники часто йшли безпечним шляхом, недотягуючи до 100%. Особливо підступним це було для трьох рівноширинних колонок. 33.33% — це найкраще, що ми могли запропонувати світу.Є проблеми й окрім цього — наприклад, батьківський контейнер за замовчанням не підхоплює висоту float-елементів. І для вирішення цієї проблеми зʼявилися нові хаки: так званий clearfix, чи танці з overflow.З іншого боку оця вся чудасія з float та спроби на їх основі будувати гнучкі й динамічні лейаути стали одним із чинників, що врешті призвели до появи flex, а згодом і до grid. Саме в епоху float зʼявилися CSS-фреймворки, які принесли у розробку поняття "12-колонкова сітка", що стала основою для макетів безлічі сайтів, і де-факто золотим стандартом дизайну.Отут можна глянути як воно працює.Якщо ви в очі не бачили float, і верстаєте виключно з flex та grid, ставте 🔥, ну а як ви такі самі динозаври, як і я, та провели не одну безсонну ніч, намагаючись зверстати той самий "священний Ґрааль", то ставте ❤️ і не забудьте випити таблетки від тиску ;)Що почитати:MDN — floatMDN Learn — floatsЩо почитати душнілам:W3C — CSS 2.1 FloatsW3C — CSS Display Module [email protected]. Квитки на нову "Співбесіду на сцені" скоро здорожчають. Заберіть вже.

#dom_in_actionDOM Node у вакуумі.DOM API дозволяє нам створювати вузли, що не приєднані до документа. І поки ми їх туди не вставимо, вони просто висять у памʼяті та не впливають на рендеринг сторінки.Тому будь-який вузол може перебувати фактично у двох станах — приєднаний до живого DOM та, очевидно, відʼєднаний. І так, ми можемо саме відʼєднати елемент, не знищуючи його.Для цього навіть існують спеціальні методи: removeChild(childNode) аби прибрати з дерева дочірній вузол, та node.remove() для самоусунення. Що важливо — вузол при цьому залишається в памʼяті.На практиці це дозволяє робити складні дії над елементом, а то й цілим піддеревом, не вбиваючи швидкодію сторінки. Операції з DOM-деревом часто призводять до суттєвого навантаження на рендеринг. А так — можна зібрати в памʼяті фрагмент дерева будь-якої складності, і потім вставити в фактичний DOM за один раз, зменшивши кількість потенційних викликів reflow та repaint до мінімуму.Є й інший бік медалі. Уявімо, що у вас є елемент і два скрипти. Один, до прикладу, змінює властивості його батька, додає й прибирає дочірні елементи. А другий, припустимо, тримає постійне посилання саме на цей вузол і читає розмір та розташування елемента на сторінці.І от якщо перший скрипт для оптимізації вилучає елемент з DOM для операцій, а другий у цей час намагається прочитати його геометрію, то результат буде дещо передбачуваним. Скрипт не впаде — він має посилання на вузол, тож усе буде чудово. Просто розміри й розташування будуть часто нульові — наприклад, у getBoundingClientRect(). Халепа?Може й так, але запобігти їй можна за допомогою однієї-однісінької властивості будь-якого DOM-вузла — Node.isConnected. Цей ґеттер повідомляє нам, чи вузол зараз знаходиться в живому DOM, а чи теліпається в памʼяті.І, що особливо зручно, isConnected працює й для вкладених вузлів. Тобто це не заміна !!Element.parentElement, повноцінний сигнал — піддерево, у якому знаходиться вузол, зараз не вDOMа. І додавши перевірку на те, чи елемент приєднаний до DOM, ми можемо знати, чи варто в цей момент здійснювати обчислення.Ось тут невеличка стіна консольлогів, яка демонструє, як працює isConnected:console.group('1. Create element in memory:');const element = document.createElement('section');console.log(`element.parentNode: ${!!element.parentNode}`);console.log(`element.isConnected: ${element.isConnected}`);console.groupEnd();console.group('2. Add child:');element.innerHTML = '<div><p>Hello</p></div>';const p = element.querySelector('p');console.log(`p.parentNode: ${!!p.parentNode}`);console.log(`p.isConnected: ${p.isConnected}`);console.groupEnd();console.group('3. Append element to live DOM:');document.body.appendChild(element);console.log(`p.isConnected: ${p.isConnected}`);console.groupEnd();console.group('4. Remove p:');p.remove();console.log(`element.isConnected: ${element.isConnected}`);console.log(`p.isConnected: ${p.isConnected}`);console.groupEnd(); Ставте 🔥, якщо дізналися про isConnected лише сьогодні, і ❤️, якщо знали про це давно[email protected]. І заберіть уже ті кілька квитків на запис нової Співбесіди на сцені.

Чи може фронтенд-розробник зробити просто сайт?Натрапив на просторах тредсу на допис, у якому авторка дещо висміює свою обізнаність про ІТ фразою "…спитала у front-end developer: «А в тебе є хтось, хто сайти робить?🤦‍♀️»". І подумав — так це доволі собі нормальне питання. От я не зможу.Ну як «не зможу». Ручками лендос зверстаю. Чи там для себе якийсь статичний блоґ на якомусь реактоподібному фреймворку. А от так шоб «під ключ», на вордпресі, щоб клієнт не смикав мене за кожну зміну в тексті — тверде й рішуче ні.Сфера веброзробки уже давно переросла просто сайти. Ба більше, те, що ми можемо щось відкрити в бравзері, зовсім не значить, що це щось — саме сайт. Це може бути цілком собі повноцінний застосунок з офлайн режимом і так далі.Я до чого. Як і будь-яка галузь, веброзробка з часом розгалужується, створює нові спеціалізації у відповідь на запит бізнесу, а нові можливості платформи формують ці майбутні запити. І так далі.Але при цьому і «старі» напрямки нікуди не діваються. І, повірте мені на слово, їхня частка не збирається падати. Усілякі реакти, анґуляри, вʼю — це, звичайно, чудово й цікаво, але вони часто не є рішенням проблеми. А іноді вони є її причиною. Тому досі процвітають і джумли, і вордпреси, і жиквері не збирається йти зі сцени. Бо існують величезні галузі, потреби яких чудово закриваються цими інструментами.І я особисто в цих інструментах — дуб дерево хвойне. Мої глибокі (але далеко не повні) знання вебплатформи дозволяють мені бути хорошим, а іноді навіть компетентним розробником у своїй галузі — складних вебзастосунках, вебінтерфейсах і так далі.Щодо цього у мене постійно крутяться недоречні аналогії, але давайте спробую навести хоч одну. Уявімо собі галузь, припустимо, кораблебудування. Ніби ж просто — човен є човен, його задача — плисти. Але от один проєктувальник спеціалізується на вантажних кораблях, а інший — на вітрильниках. І от питання — чи зможуть вони виконати роботу один одного?Мені здається, що так само як і з веброзробкою — до певної міри. Там, де прицнипи схожі, проблем не виникне, тим паче, що основи кораблебудування вони вивчали однакові. Але щойно почнуть виникати специфічні питання, я більш ніж впевнений, що робота крепко забуксує.Тобто ззовні ж воно як: тут ніби шо то, шо то — корабель, у нас ніби шо то, шо то — сайт. Але якщо копнути бодай трошечки глибше, на світ божий вилізе стільки нюансів, що доведеться знову назад закопувати те кубло.Спеціалізація — це добре. Але, як я завжди кажу — лише на рівні галузі. Спеціалізацію на рівні React vs Vue я вважаю смішною і безглуздою (це так, шоб ви не забували, з яким душнілою маєте справу).Тому так, «А в тебе є хтось, хто сайти робить?» — це абсолютно правильне і слушне питання до веброзробника.@babichdev

#нове_відеоЩо стоїть між вами та офером з іншого континенту? Це не дотягуєте ви, чи проблема таки в фільтрах, рекрутерах, хибних очікуваннях з обох сторін, або, борони боже, в ШІ?У новому випуску "Подкасту у нас вдома" разом з Ольгою Базуріною розкладаємо заокеанський найм по кроках: де вас може зрізати ATS/AI, чому «креативне» резюме інколи зводить нанівець усі шанси, і як читати сигнали компанії ще до призначення технічної співбесіди.📺 Дивіться новий випуск вже:АМЕРИКАНСЬКА МРІЯ В ІТ: як (не) дійти до офера з-за океануОльга — Global Talent Acquisition Manager із 10+ роками досвіду в США, Європі, Україні та LATAM; будує й масштабує технічні та C-level команди (зокрема Fortune 500); співвласниця міжнародної рекрутингової агенції, експертка з HRTech і Talent Intelligence.Партнер випуску — RNRS Solutions: міжнародний рекрутинг для технологічних компаній — точковий підбір і побудова команд з нуля (IT, Miltech, FinTech, Data, Cloud, Telecom) у LATAM, США, ЄС, Великій Британії та MENA. Деталі — на сайті й у LinkedIn.⚡️⚡️⚡️А серед тих, хто дивитиметься дуже уважно, ми разом з RNRS Solutions розіграємо подарунки!Умови прості: уважно слухайте, давайте правильні відповіді на запитання по відео, і дочекайтесь розіграшу.⚡️⚡️⚡️ Приємного перегляду!