А вам вже страшно стало? 😜

У MacPaw є цікава думка. І знаєте що?.. я з нею повністю погоджуюсь 🤙

Вирішив спробувати зарефакторити робочий проєкт разом з Claude Code.
А потім ще в пʼятницю задеплою. Горить хлів - гори і хата.

Щоб ви розуміли обʼєми проєкту

Один я відоси по 15 хвилин роблю, дурачок. Треба курс по ларці на 5 хвилин зробити 🙄

Програмісти майбутнього be like…

Коли починаєте новий проєкт, завжди робіть глибокий ресьорч потрібного функціоналу на стадію MVP хоча б.

Інакше ви стикнетесь з неправильним вибором і стеку, і архітектури, і з неправильною оцінкою витрат на розробку.

А якщо скласти JS та TS, то взагалі буде 2225%

Нарешті це сталось!

В документацію Laravel додали сторінку з ченджлогами

https://laravel.com/docs/changelog

Є ідея завести нову рубрику на каналі.

Давайте будемо розбирати ваш код. Проводитимемо код-ревʼю ваших проєктів? 🤙

Зі свого боку я зобовʼязуюсь не називати автора за вашим бажанням і давати лише конструктивні коментарі по вашому коду. Матюкати не буду 😁

Надсилайте заявки в особисті! Буде цікаво, а головне корисно всім!

Я вирішив розібратись із сучасним станом роботи з Livewire.

І мене певні речі у Livewire v3 дійсно здивували по-хорошому.

Перше, з чим я вирішив розібратись - це підтвердити чи розвінчати міф, що Livewire компоненти спамлять бекенд.

Звідки взявся цей міф?

У Livewire v1–v2 дійсно була така поведінка:
Кожна зміна інпуту (через wire:model) одразу відправляла AJAX-запит на сервер. Не було debounce або defer за замовчуванням, тому навіть швидкий набір тексту міг породжувати десятки запитів на секунду. Також старі версії не використовували оптимізоване "DOM diffing" - кожен запит міг повертати досить великий HTML-фрагмент.

Результат: у великих формах або таблицях справді з’являвся "спам" запитів і додаткове навантаження на бекенд.

Як працює Livewire v3 (реальність 2024–2025)

Починаючи з Livewire v3, механізм реактивності став набагато ефективнішим:

1. Лише цільові оновлення
Livewire не оновлює весь компонент - лише ті частини DOM, які реально змінилися, використовуючи "morphdom"-подібний підхід.
Передається мінімальний HTML-патч, а не повна розмітка.

2. Синхронізація стану відкладена
wire:model має режими:
- wire:model.lazy - оновлює стан лише після втрати фокусу.
- wire:model.debounce.500ms - дебаунсить зміни на 0.5 секунди.
- wire:model.defer - синхронізація лише після дії (наприклад, сабміту).
Ти сам контролюєш частоту оновлення.

3. Сервер не "пушить" нічого постійно
Livewire не тримає постійне з’єднання (як WebSocket чи polling), якщо ти сам цього не налаштуєш (wire:poll, наприклад).
Тобто:
Livewire не створює постійних запитів у фоні.
Кожен запит - це реакція на конкретну дію користувача (клік, зміна інпуту тощо).

4. Wire-події "групуються"
Livewire може "об’єднувати" кілька змін стану в один запит, якщо вони трапляються одночасно.

5. Використання Fetch + кешування
У v3 використовується fetch() API з HTTP/2 multiplexing, тому навіть коли запитів кілька - це не проблема для сучасних серверів, бо браузер їх оптимально групує.

Більш детально хочу розповісти у відео, яке вже почав готувати 😉

Ну і вечірнє 😁

Однозначно мені потрібна ця книжка.

Make Coding Fun Again.

Раночку, панство! Майте смачну каву та гарний настрій!

Каву, серіальчик, в шось пограти, а не отой ваш деплой в пʼятницю.

Бережіть себе від непотрібних рішень сьогодні!

Як ви, народ? Кияни, як ви?

Сьогодні буду вас трохи питаннями замахувати, ок? 😉

Пʼятниця, не працювати ж...

Отримав першу заявку на розбір проєкту у форматі кор-ревʼю.
Але, такий формат - це або довге відео, або довгий стрім.
І тут дилема: довге відео дивитись не будуть. Треба різати на декілька. Стрім не зробить охоплення аудиторії, якій то було б цікаво... Дилема.

Давайте ще півгодинки голосуємо і приймаємо рішення щодо стріму сьогодні