Livewire ломается не в компонентах, а в границах состояния

Livewire ломается не в компонентах, а в границах состояния

Главная ошибка — считать Livewire «магией, которая сама всё синхронизирует». На деле у вас есть серверное состояние, публичные свойства и DOM, который может жить своей жизнью.

— Не храните в public-свойствах то, что нельзя безопасно сериализовать: модели с тяжёлыми связями, сервисы, объекты запроса.
— Для списков и форм держите примитивы и явные массивы, а сложные данные пересобирайте в методах.
— Любой input с динамическим рендером проверяйте на конфликт с diff-механикой: если элемент меняется по key, состояние улетает.
— Если компонент начинает «дергаться», сначала смотрите не в Blade, а в частые перерендеры и лишние запросы.

Вторая типовая ошибка — тащить в один компонент всё подряд: фильтры, таблицу, модалки, сайдбар и бизнес-логику. Такой компонент трудно тестировать, а проблемы с производительностью потом маскируются под «особенность Livewire».

Разделяйте ответственность: один компонент — одна интерактивная зона. Если есть повторяющиеся части, выносите их в дочерние компоненты или обычные Blade partials. Для тяжёлых действий используйте явные методы, а не цепочку реактивных триггеров.

Если Livewire ведёт себя странно, сначала упростите состояние и DOM — в этом почти всегда и лежит причина.