KRUHLYK 🇺🇦

Погнали!

Добре, трохи більше половини все ж за стрім, тому сьогодні проведемо невеличкий стрім. Чекатиму всіх о 14:00 🙂 https://www.youtube.com/watch?v=bVmWzRg1ImE

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

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

Як ви, народ? Кияни, як ви? Сьогодні буду вас трохи питаннями замахувати, ок? 😉 Пʼятниця, не працювати ж...

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

Однозначно мені потрібна ця книжка. Make Coding Fun Again. Раночку, панство! Майте смачну каву та гарний настрій!

Ну і вечірнє 😁

Я вирішив розібратись із сучасним станом роботи з 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, тому навіть коли запитів кілька - це не проблема для сучасних серверів, бо браузер їх оптимально групує. Більш детально хочу розповісти у відео, яке вже почав готувати 😉

Є ідея завести нову рубрику на каналі. Давайте будемо розбирати ваш код. Проводитимемо код-ревʼю ваших проєктів? 🤙 Зі свого боку я зобовʼязуюсь не називати автора за вашим бажанням і давати лише конструктивні коментарі по вашому коду. Матюкати не буду 😁 Надсилайте заявки в особисті! Буде цікаво, а головне корисно всім!

Нарешті це сталось! В документацію Laravel додали сторінку з ченджлогами https://laravel.com/docs/changelog

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

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

Понеділкове. Смачної кавусі, гарного настрою та вкочуємось в робочий тиждень ☕️

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

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

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

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