🚀 Великий апдейт LIVR: Type Inference та оптимізація

Вийшло важливе оновлення бібліотеки. Основний фокус - зручність типізації та перформанс. Що нового:

1️⃣ Повноцінний Type Inference. Тепер типи виводяться прямо зі схем, навіть для найскладніших правил. Працює з аліасами правил та кастомними розширеннями. 👉 Зацініть приклади: Simple | Complex

2️⃣ Design Decisions. Додав детальний опис архітектурних рішень. Розбираю, чому зроблено саме так, і порівнюю з альтернативами. 📖 Читати: DESIGN.md

3️⃣ Performance Boost. Оптимізував виконання правил. У деяких кейсах приріст швидкодії сягає +30% (👉 для динамічних схем в 94 рази швидший за Zod, який дуже повільно компілить схеми, що мене прям самого здивувало)

4️⃣ LIVR Extra Rules. Оновив пакет livr-extra-rules, щоб він також використовував новий рушій для Type Inference.

Як вам CVE-2025-55182 React2Shell? Вразливість в React на 10 з 10 (RCE). Просто передавай JS з клієнта й він виконується на сервері. Для SPA не критично, а от якщо у Nextjs й React 19+, то біда.

Повертаємося до причини, чому з'явився livr - ніколи не довіряй жодним даним, що прийшли від користувача.

Деталі React2Shell: https://x.com/rauchg/status/1997362942929440937?s=09

DHH (разом з chatgpt) про мікросервіси.
Сподобалася фраза "You are forced to define APIs before you understand your own business. ... In a monolith, wrong thinking is corrected with a refactor. In microservices, wrong thinking becomes infrastructure". Колись робив відео про головну проблему мікросервісів й якраз про це розповідав.
Власне пост від DHH: https://x.com/i/status/1998785569468399819

Це прекрасно 😁

Що сучасного є в світі JS/TS/Node розробки?

Накидайте в коментарях тули й підходи, які використовуєте для фронта й бекенда.

Почну з себе:
1. Vite для збірки.
2. Vitest для тестів фронта й бекенду.
3. React MUI для інтерфейсів.
4. MikroORM (поки ще тестую) для доменної моделі.
5. LIVR для валідації
6. chista - для шару сервісів
7. chista-express - замість шару контролерів

Цікавить чи хто юзав й які відгуки:
1. React compiler
2. Lit (веб-компоненти)
3. Bun

Також питання:
1. Які є гарні альтернативи React MUI?
2. Як тестуєте інтеграцію фронту й бекенду?
3. Що використовуєте на фронті для роботи з RestAPI/RPC/GraphQL? Чи генеруєте клієнти?
3. Які фреймворки на бекенді використовуєте?
4. Чи використовуєте DI й які ліби для цього?
5. Що для тестів бекенду?
6. Якісь корисні бібліотеки, які вам подобаються (наприклад, побудова графіків, робота з API, форматування дат й інше).

Що там нового в світі розробки окрім AI?)

Мобільний/десктопний додаток за два вечори
У мене камера від Blackmagic й там є rest api, але немає офіційного додаток. Я зазвичай через curl відправляв запит на автофокус, коли пишу відео. Й тут сів писати відео й відчуваю, що це не може бути так, треба зробити десктопний/мобільний додаток. Вирішив взяти повністю нову для мене технологію - Flutter, й відповідно мову програмування - Dart. Й спробувати зробити дадаток повністю на ШІ.

Ось, що вийшло - https://www.youtube.com/shorts/3J8VA4Y3Ba4

Й відповідно код на github - https://github.com/koorchik/blackmagic_camera_control

В 25 січня в 10:30 ранку лайв вайб-кодинг
У мене є ідея дуже цікавого пет-проекту, але поки для нього нічого немає. Буду з нуля в цю неділю вранці вайб-кодити. Доєднуйтесь до стріму, має бути цікаво. Окрім того, що поки ШІ думає, то завжди є час відповісти на питання в чаті.
https://youtube.com/live/BtHQyH6mniQ

Через годину починаємо. Налаштовую все 🙈

Дякую всім, хто доєднався. Завтра буде продовження

Сьогодні (26.01.2026) в 21:00 година вайб-кодингу

Друга частина стріма. Доєднуйтесь тут
https://www.youtube.com/watch?v=LtaOkeyq6Bc

Під час стріма питали про автоматизовані тести для фронтенду й я згадував саме цю свою доповідь

Доповідь про React, з якої все починалося
12 років тому Піт Хант зробив круту доповідь про React на 30хв, де він добре пояснює архітектурні рішення й підходи. Доповідь не втратила своєї актуальності на мою думку.

ДОПОВІДЬ: https://www.youtube.com/watch?v=x7cQ3mrcKaY

Все ще актуальна?

На тему заміни нас ШІ 😁

Вайб-кодера - новий канал про використанні ШІ
Тут мене Віталя попросив запостити посилання на свій новий канал про ШІ.
Зацініть - https://xn--r1a.website/vibe_codera

Як вам канал? Як контент? Чи читаєте ще щось схоже? Можете відразу писати в коментарі тут, що подобається, а що ні. Канал молодий й фідбек буде корисним

Чи готовий ШІ залишити нам наші робочі місця?
Продовжую спілкування з Gemini 🙈

Я вже думав, що все вийшло, але остання фраза ШІ... 😁
https://youtube.com/shorts/9PNO4P82xfU?si=JgB6rL5of4KQwZpr

Ярмарка вакансій в оборонному секторі 14-го березня в Києві.
Івент від DOU й Lobby X. Вхід за донат.

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

https://arsenal.talantiv.in.ua/

Було класне обговорення про фільми про хакерів. Ось обираю собі кіно на вечір. Можете теж глянути коментарі в п'ятничний вечір 🤓

Зарелізив дві бібліотеки для тестування UI-компонентів: dom-harness та mui-harness

В Google я постійно писав юніт-тести для фронта й основою було використання test harness. Я забув про біль від querySelector в тестах, type casts усюди, від того, що десь з'явився зайвий div, який ломає тести.

Що таке Test harness?
Це тонка обгортка навколо DOM-елемента, яка ховає селектори та взаємодії за чистим API. Саме так тестують компоненти в Angular CDK. Чомусь в світі React такого немає.

✳ dom-harness - базова бібліотека (~110 рядків), на основі якої ви будуєте харнеси для своїх компонентів. Працює з будь-яким фреймворком (є приклади в репі для React, Vue, Svelte, Angular, Solid, Preact). Під капотом - реальний DOM, реальні події, нічого замоканого.

❌ Як виглядає тест без харнесів:

const input = document.querySelector(
  '[data-testid="text-input"][name="username"]'
) as HTMLInputElement;
const button = document.querySelector(
  '[data-testid="button"]'
) as HTMLButtonElement;
await user.type(input, 'testuser');
await user.click(button);

✅ З харнесами:

const form = LoginFormHarness.first();
await form.usernameInput.type('testuser');
await form.submitButton.click();

Основна ідея, що для кожного компонента робиться харнес, який дає доступ до можливостей компонента через свій API. Тобто це, як Enzyme (який вмер вже), але працює з реальним DOM. Хоча найближча аналогія це PageObject патерн, але той не мав можливості композиції, а тут це основа. Тобто, компоненти вкладені один в одний й відповідно харнеси теж: LoginFormHarness містить TextInputHarness і ButtonHarness, з автоматичним скоупінгом запитів до this.root.

✳ mui-harness - колекція готових харнесів для Material UI: TextField, Button, Checkbox, Dialog, IconButton й інші. Побудований поверх dom-harness. Більше не потрібно лізти в MUI-шну розмітку з .MuiInputBase-root та іншими внутрішніми класами, які ламаються між версіями.

Коли це корисно:
- якщо ви пишете тести для фронту або хочете, щоб ШІ писав їх за вас й це було структуровано.
- якщо у вас в компанії є дизайн-система, то харнес до кожного компонента це взагалі must have.
- Команди, що мігрують між фреймворками. Якщо різні фреймворки рендерять ту саму розмітку, то харнеси не змінюються (тільки render).
- Якщо ти автор UI-бібліотеки, то мати харнеси до своїх компонентів це як types для TypeScript - без них можна, але з ними бібліотека стає значно зручнішою для тестування.

Отримав фідбек, що не відразу зрозуміло, що це таке. Тому написав три документи з детальним роз'ясненням концепцій:
1. https://github.com/koorchik/dom-harness/blob/master/docs/GETTING_STARTED.md
2. https://github.com/koorchik/mui-harness/blob/master/docs/GETTING_STARTED.md
3. https://github.com/koorchik/mui-harness/blob/master/docs/BEST_PRACTICES.md

Також заціність, як виглядає компонет форми логіну (й відповідно харнес й тест до нього) - https://github.com/koorchik/mui-harness/tree/master/examples/login-page/LoginPage/LoginForm

Чи зрозуміла ідея підходу? Діліться думками в коментарях.

PS: писав все AI-friendly, щоб агент міг зрозуміти, як цим користуватися. Також додав пакети до context7 індексу

Накидайте ваші улюблені тули під Linux
Особливо цікаво різні консольні. Я сьогодні відкрив для себе btop - не знаю чи зручно, але вигладає ефектно).
Моя перша рекомендація це ncdu - улюблена тула для пошуку, що займає місце на диску.

Пишіть в коментаряє, що під Linux використовуєте, як під десктоп, так й на сервері

Claude code генерує говнокод й що з цим робити.

Я використовую Claude Code й на існуючому проекті він генерує дуже крутий код й все добре працює. Також я пробив вайб-кодити додаток на Flutter й вийшло непогано, хоча довелося певну кількість разів змусити Claude рефакторити архітектуру.

Зараз я викладаю курс по React в університеті й студенти використовують ШІ (що й в вимагається) й їх проекти з одного боку відповідають формальним вимогам й треба ставити високий бал, а з другого боку - кожен проект це суцільний говнокод, який я би в житті не пропустив на код рев'ю.

Оскільки студентів багато, то вчити архітектурі кожного на курсі, де ми вчимо React, не виглядає реалістичним. Тому виникла ідея створити SKILL під Claude Code, який буде робити архітектурне рев'ю й давати конкретні рекомендації по змінам в коді.

Я зробив 7 ітерацій A/B тестування скілу й витратив десь 10-15 годин на це. Різниця між скілом й просто промптом з інлайн запитом на архітектурне рев'ю - космічна. Насправді, перші версії скліла могли навіть рекомендувати архітектурні антипатерни. Довелося повичитувати результати його роботи й модифікувати скіл ітарація за ітерацією.

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

PS: мабуть треба планувати продовження стрімів по вайб-кодингу для демонстарції ефекту на моєму пет-проєкті 🤓