<b>Livewire ломают не компоненты, а границы между UI и состоянием</b>

<b>Livewire ломают не компоненты, а границы между UI и состоянием</b>

Livewire удобен там, где хочется держать Blade и логику рядом, но именно это создаёт типовые ошибки. Компонент начинает расти как мини-страница: запросы, валидация, фильтры, модалки, загрузки — и всё в одном классе.

Есть наблюдение которое стоит проверить: если компонент сложно тестировать, он уже перегружен. Разделяйте ответственность:
— отображение в Blade;
— состояние в компоненте;
— бизнес-логику в сервисе или action-классе.

Второй частый провал — лишние запросы в рендере. Любой `render()` должен быть почти тупым: без тяжёлых вычислений, без `N+1`, без сборки сложных коллекций на каждый чих. Всё, что можно посчитать заранее, выносите в свойства или отдельный слой.

Третий момент — события и entangle. Их легко использовать как магию, но потом сложно понять, кто меняет состояние и почему UI ведёт себя не так. Для сложных сценариев лучше явные методы и предсказуемые payload’ы.

Если проект на Livewire начинает «скрипеть», проверьте сначала не фреймворк, а архитектуру компонентов. Чем меньше магии в состоянии, тем дешевле поддержка.