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

Буде круто, незвично, цікаво й корисно. Словом, чекатиму на вас завтра!

https://secure.wayforpay.com/payment/lampa_senior_fe

Що для вас "тестове завдання"? А то мені тут запропонували приділити вісім (!) годин, а вимоги до завдання як до нормального такого PoC.

Хоча завдання саме прикольне, вимагає активне використання ШІ, тобто й сам процес буде цікавим. Але 8 годин? Це повноцінний стресовий насичений робочий день після якого зазвичай беруть довгі вихідні.

Ще й не оплачуване.

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

А от ви скільки часу готові приділяти тестовим?

Записати "говорящу голову" — година.
Почати записувати демки коду і зрозуміти, що вони хєрня собача — дві години.
Сісти фіксити демки і сценарій під них, захопитися і повністю все переробити — три години.

І тепер знову з нуля треба писати демки (

Отакі вони суворі будні ютубної сєлєби.

Прикликаю адмінресурс!
У мене шось на сайті прийдешньої конференції React+ fwdays'25 ну прямо замало вподобайочок.

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

Тому заходьте, тикайте пальцем або курсором в мою задоволену мармизу і княпайте "ХОЧУ ПОСЛУХАТИ".

Вам несложно, мені пріятно, як то кажуть.

https://fwdays.com/event/react-fwdays-2025

Так, я нарешті записую демки для наступного відео. А чим ще в суботу зайнятися, їй-богу?!

#js_in_action
Загальновідомо, що JS може працювати лише в одному потоці, тобто усі дії та обчислення ставляться в чергу. І коли вони виконуються, будь-які інші дії "блокуються", тобто мусять дочекатися, доки завершиться поточний обрахунок.

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

Чи є? Уже тривалий час ми маємо доступ до так званих воркерів — можливості запускати окремі ізольовані контексти виконання, з блекджеком власним потоком та чергою виконання. Це не фіча самого JS, а саме середовища виконання.

Перший драфт, до речі, зʼявився ще 2009 року. І того ж року його підтримку додали в Firefox 3.5 та Chrome 4. З тих пір можливості цього стандарту тільки зростали, як і поширення його запровадження в бравзерах. А з 2019 року стабільна підтримка воркерів зʼявилася і в NodeJS.

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

Але ж який в них тоді сенс, спитаєте ви? Ну, не такі вони вже й ізольовані. Існує спеціальний інтерфейс спілкування з воркерами, який підтримує метод postMessage для надсилання повідомлень і onmessage для їх обробки. Це викликає в голові мою улюблену аналогію з печерою, коли воркер весь час сидить в ній і виконує свою задачу, а ми в той час займаємось своїми справами. Коли нам треба щось — ми кидаємо в печеру записку із завданням, а через якийсь час воркер викидає з неї результат.

// main.js
const worker = new Worker('worker.js');
worker.postMessage('Зроби шось!');
worker.onmessage = e => {
  console.log(e.data);
}

// worker.js
onmessage = e => {
  postMessage(
    'Зробив шось, забирай'
  );
});

Наразі існує декілька видів воркерів, кожен з яких має своє призначення.

Почнемо з Dedicated Worker. Він належить тільки тій сторінці, яка його створила і закінчує своє існування разом з нею. Це якраз класичний приклад додаткового процесу, який обмежений однією вкладкою. Але якщо нам треба воркер, який вміє спілкуватися з кількома вкладками?

Для цього існує SharedWorker. Він поводиться рівно так само, як і звичайний, але при цьому до нього можуть підключатися різні вкладки з нашим застосунком. І "живе" він теж до останнього підключення.

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

Це свого роду наш кишеньковий сервер, який вміє працювати з фоновими завданнями, має доступ до великої кількості API, таких як Cache, Background Sync, Push та багатьох інших. Його основне завдання — виступати посередником між нашим застосунком, локальним кешем та мережею. Саме на ньому базується можливість створення offline-first застосунків.

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

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

Що почитати:
📖 MDN: Web Workers API
📖 MDN: SharedWorker
📖 MDN: Service Worker

Що почитати душнілам:
📖 WHATWG: Web Workers Standard
📖 W3C / WHATWG: Service Workers

Підписуйтесь: @babichdev

І ще навздогін — також ми з вами збирали й придбали Mavic для 183 навчального центру!

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

А на ділі — кожна, кожна гривня критично важлива.

Дякую вам, товариство!

— …так, ну шо, цей тест нарешті пофіксив, тепер треба про всяк випадок інші запустить…
— …
— …
— СССССУКА!

(з польових нотаток)

#мислення_розробника
Тести, тести, тести… Вони стали частиною моєї практики доволі нещодавно. На початку моєї карʼєри про них і не знали, а далі зазвичай все зводилося до класичного "у нас немає часу і ресурсів".

А потім вони зненацька увійщли в моє життя, як то кажуть — "увірвалися з ноги". Ми мали підтримувати 95% покриття тестами на UI, що призводило до доволі очікуваного результату — покривалися рядки коду, а не логіка чи поведінка. Відповідно, і якість таких тестів була передбачуваною.

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

Питання юніт та інтеграційних тестів на фронтенді доволі неоднозначне. Що тестувати? Як? Наскільки ретельно? Трактування може відрізнятися від команди до команди, від ліда до ліда. Але є дуже проста рамка, яка дозволяє мені лишатися в межах здорового ґлузду.

Почнемо з юнітів. Ними я покриваю саме логіку. Не поведінку. Для цього дуже зручно користуватися підходом "one hook to rule them all", бо в такому випадку я можу перевірити основні сценарії, не покладаючись на розмітку і .toBeInTheDocument, якщо мене цікавить, чи правильна комбінація даних на виході.

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

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

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

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

Щодо інтеграційних UI тестів. Тут дещо складніше скласти ту рамку, бо не завжди зрозуміла межа відповідальності. Ще менш зрозуміла межа між тим, де це ще інтеграційний тест кількох UI компонент, а де вже повноцінний end-to-end.

Якщо користуватися підходом з єдиним state-hook в компоненті, то мені не треба перевіряти UI-flow, аби дізнатися, чи змінює натискання кнопки видимість якогось елемента. Для цього є типу інтеграційний тест для цього хука, де я змінюю один набір даних і перевіряю, чи змінився стан потрібним мені чином.

І переконатися, що UI реагує правильно, дуже просто. Якщо тест, в якому ми перевірили зміну стану, працює правильно, то для перевірки UI нам достаньо просто замокати різні зліпки цього стану і дивитися, чи вірно відбувається рендер HTML. Це позбавляє мене необхідності емулювати e2e-тести.

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

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

Ну якось так. Пишіть тести, вчіть теорію тестування — ви собі потім подякуєте. А за нагоди поговоримо про тести та AI.

@babichdev

P.S. Росія — кончена країна кончених людей. Головне ж для нас — триматися купки. Обіймаю усіх.

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

Але тоді я навіть не здогадувався, яких зусиль коштував це ефект розробникам. В кращому випадку — noscript-фільтр, у гіршому — скриншот тла через canvas та розмиття вручну. Мені здається, я маю дякувати богам веброзробки, що свого часу мене оминула доля додавати розмиття на сторінку.

Проте час не стоїть на місці і, як багато інших поширених проблем, цю задачу тепер можна виршіти одним рядком CSS. Багато хто з вас уже знайомий з властивістю backdrop-filter, головною відмінністю якої від просто filter є те, що розмиття вмісту відбувається не всередині елементу, а поза ним.

Якщо не поставили вподобайку — далі читати не дозволяю.

Ця властивість відразу спростила код навколо наших модальних вікон (а dialog спрощує ще більше, але про це — іншим разом). Однак, як часто трапляється, далі цього конкретного використання справа не заходить.

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

… {
  backdrop-filter: blur(10px);
  backdrop-filter: brightness(150%);
  backdrop-filter: contrast(150%);
  backdrop-filter: grayscale(150%);
  backdrop-filter: invert(150%);
  backdrop-filter: opacity(0.6);
  backdrop-filter: saturate(200%);
  backdrop-filter: sepia(150%);
  backdrop-filter: hue-rotate(50deg);
}

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

backdrop-filter:
  contrast(150%)
  grayscale(150%)
  invert(150%);

Варто памʼятати, що аби ефект запрацював, елемент, у якого є backdrop-filter, не повинен мати суцільного тла. Якщо важливо явно відділити його від елементів поза ним, і при цьому застосувати якийсь цікавий фільтр, дещиця прозорості фону не завадить. А найкраще ефект від фільтрів видно саме при повністю прозорому тлі.

А ще надзвичайно важливо мати на увазі те, що backdrop-filter обчислюється в реальному часі на GPU, і може потребувати значний обʼєм ресурсів. Зокрема, якщо фільтр накладено на велику площу (так, той самий бекдроп під модалкою). Ситуація може поігршитись, якщо на тлі відбувається анімація, тоді бравзер змушений постійно оновлювати зображення позаду елемента, щоб відповідати цій анімації. Ну й трошки навантаження може додати тінь на цьому ж елементі — чим вона більша, тим більше ресурсів жує бравзер.

Це не означає, що ваш ноутбук згорить, щойно ви відобразите анімацію з фільтром (радше клієнтський), але зважати на це теж варто. Не у всіх же МакБуки з М4.

MDN: backdrop-filter

Маленьке демо: https://jsfiddle.net/b0Lry2jm/3

***
@babichdev

#коштозбір
Товариство, маємо новий запит від військових.

Для роти матеріально-технічного забезпечення 115 бригади потрібно два детектори дронів "Чуйка".

Детектори треба для бензовозів, які заправляють тяжку техніку на Покровському напрямку.

Наразі це 49 400 гривень, будем брати по мірі накопичення коштів.

Буду вдячним за кожну гривню, товариство!

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

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

#нове_відео
Товариство, вирішив оживити один зі старих дописів про aspect-ratio, і створив коротеньке відео. Запрошую до перегляду!

https://youtu.be/TxqfBsvJlC8

Там 4 хвилини всього, подивіться зараз, не відкладайте)

***
На детектори дронів зібрано 2 236 грн з 49 400 грн. Долучайтесь!

Якщо monobank після сьогоднішнього дня не зробить доповідь на Highload Fwdays, то я навіть не знаю, нашо це все було.

До речі, один з лимонів можна знайти, відкривши чиюсь банку. Можна і цю. Бо збір на детектори дронів для 115-ї бригади шось засмутивсь і стоїть.
https://send.monobank.ua/jar/AeXQ6YRf2X