Inertia.js отримала першу вбудовану реалтайм-можливість. Клієнт v3.11.0 і серверний адаптер inertia-laravel v3.7.0, що вийшли 2 листопада, додали live props: пропси, які самі перезавантажуються, щойно сервер надсилає подію через бродкастинг, без жодної дії користувача. Статус замовлення, лічильник непрочитаних, метрики на дашборді тепер оновлюються одним викликом на сервері та однією опцією на клієнті.
Досі для такого доводилося вручну підписуватися на канал через Echo в компоненті й викликати router.reload({ only: [...] }) з обробника, а потім не забути відписатися при переході. Або обходитися polling, який ми вчора розбирали разом з його новою паузою у фонових вкладках, у пості про v3.10. Live props - наступний крок: замість опитування за таймером сторінка реагує на подію.
Серверний бік: Inertia::live()
Пропс позначають через Inertia::live() і передають подію, яка має його оновлювати. Канали Inertia бере з методу broadcastOn() самої події, тож повторювати їх не треба:
use App\Events\OrderUpdated;
return Inertia::render('Orders/Show', [
'order' => Inertia::live(fn () => $order->fresh(), on: new OrderUpdated($order)),
]);
Аргумент on приймає і масив подій, кожна з яких слухається на своїх каналах:
'order' => Inertia::live(fn () => $order, on: [
new OrderUpdated($order),
new OrderShipped($order),
]),
Якщо подія надсилається на кілька каналів, скажімо orders.1 і orders, пропс слухатиме всі. Звузити це можна аргументом channel. Він же потрібен, коли подію задано рядковою назвою, бо з рядка канали не дістати:
Inertia::live($value, on: 'order.updated', channel: new PrivateChannel('orders.1'));
Замість екземпляра можна передати ім'я класу, OrderUpdated::class, але лише тоді, коли канали й назва з broadcastAs() не залежать від даних події: Inertia створює об'єкт без виклику конструктора. Канал на кшталт orders.{$this->order->id} так не спрацює, і пакет кине LogicException з підказкою передати екземпляр або channel.
Підтримуються всі типи каналів Laravel: публічні (рядок або Channel), PrivateChannel, PresenceChannel і EncryptedPrivateChannel. Авторизація приватних каналів іде як завжди, через routes/channels.php.
Клієнтський бік: live: echo()
На клієнті Inertia отримує події через транспорт, який передають в опцію live у createInertiaApp. Для Laravel-застосунку це хелпер echo(), що бере екземпляр, налаштований через configureEcho():
import { createInertiaApp } from '@inertiajs/vue3'
import { echo } from '@inertiajs/vue3/echo'
import { configureEcho } from '@laravel/echo-vue'
configureEcho({ broadcaster: 'reverb' })
createInertiaApp({
live: echo(),
// ...
})
Для React і Svelte імпорти ті самі з @inertiajs/react/echo та @laravel/echo-react або @inertiajs/svelte/echo та @laravel/echo-svelte. Пакети @laravel/echo-{vue,react,svelte} - опційні peer-залежності, тож застосунки без live props нічого нового не тягнуть. Якщо Echo створено інакше, наприклад напряму через laravel-echo, його віддають колбеком resolve:
createInertiaApp({
live: echo({ resolve: () => window.Echo }),
})
Підписки й відписки при переході між сторінками Inertia робить сама. Крім Echo, є транспорти pusher() для будь-якого клієнта з протоколом Pusher і actionCable() для Rails та AnyCable, а за потреби можна написати власний транспорт для WebSocket чи SSE.
Що відбувається під капотом
Коли подія приходить, Inertia робить звичайне часткове перезавантаження (Partial Reload) лише тих пропсів, що її слухають. Клієнт отримує те, що контролер повертає саме в цей момент, тож логіка й авторизація лишаються на сервері.
- Пропси, що слухають один канал і одну подію, оновлюються разом, одним запитом.
- Одна дія часто надсилає кілька подій поспіль, тому Inertia чекає кілька мілісекунд і збирає всі зачеплені пропси в один запит.
- Якщо пропс уже перезавантажується іншим запитом, Inertia дочекається його і перезавантажить пропс ще раз, бо відповідь могла бути сформована до події.
- Після обриву з'єднання Inertia оновлює всі live props, бо події, що прийшли за цей час, загубилися.
Для фонових індикаторів є новий хук useProp: він повертає значення пропса та прапорці loading і loaded, тож замість повноекранного лоадера можна злегка пригасити блок, поки дані оновлюються.
Throttle і фонові вкладки
Типово кожен live-пропс оновлюється не частіше разу на секунду. Глобальне значення в мілісекундах змінюють в опціях транспорту, а для окремого пропса - аргументом throttle:
createInertiaApp({
live: echo({ throttle: 2000 }),
})
'metrics' => Inertia::live(fn () => Metrics::today(), on: new MetricsUpdated, throttle: 5000),
Кожен пропс обмежується окремо, тож «гарячий» пропс не гальмує решту сторінки, а події, що прийшли у вікно throttle, зводяться до одного запиту в його кінці. Ручний router.reload() throttle не зачіпає.
Поки вкладка прихована, оновлення стоять на паузі й виконуються, коли користувач повертається. Це вимикає опція pauseWhenHidden:
createInertiaApp({
live: echo({ pauseWhenHidden: false }),
})
Разом з defer, once, optional і always
Inertia::defer(), Inertia::once(), Inertia::optional() і Inertia::always() отримали метод ->live() з тими самими аргументами. Найкорисніша комбінація - пропс, відкладений на першому завантаженні й живий після нього:
'activity' => Inertia::defer(fn () => $order->activity)->live(on: new ActivityLogged($order)),
Опційний live-пропс оновлюється лише після того, як сторінка сама його завантажила: подія ніколи не підвантажить те, чого сторінка не просила.
Обмеження одне, і воно жорстке: merge-пропси live бути не можуть. У коді адаптера і ->live() на merge-пропсі, і ->merge() на live-пропсі кидають LogicException, тож нескінченну прокрутку чи стрічку з Inertia::merge() так оновлювати не вийде.
Скільки коштує кожна подія
За замовчуванням подія - лише сигнал: кожна відкрита сторінка йде на сервер по нове значення, і дашборд у тисячі вкладок перетворює одну подію на тисячу запитів. Щоб цього уникнути, подія може нести значення сама через Inertia::broadcastProps():
public function broadcastWith(): array
{
return [
'order_id' => $this->order->id,
...Inertia::broadcastProps([
'order' => OrderResource::make($this->order),
]),
];
}
Тоді Inertia записує значення в сторінку без запиту. Але дані отримує кожен підписник каналу, а авторизація каналу виконується лише при підписці, тож надсилати так варто тільки те, що однакове для всіх на каналі. Документація радить ресурси замість моделей: модель віддає всі атрибути, не приховані через $hidden.
Ще дві корисні деталі. Inertia передає ID сокета заголовком X-Socket-Id у кожному запиті до свого origin, тож broadcast(...)->toOthers() працює як звичайно і автор зміни не отримує зайвого перезавантаження. А скасовувана подія live у router.on('live', ...) дає змогу пропустити оновлення і, скажімо, показати кнопку «Є нові дані».
Що потрібно, щоб почати
- Оновити обидва пакети: клієнт
@inertiajs/* до v3.11.0 і inertiajs/inertia-laravel до v3.7.0.
- Мати налаштований бродкастинг: Reverb, Pusher-сумісний сервер чи інший драйвер, і події, що реалізують
ShouldBroadcast.
- Для Echo-транспорту встановити
@laravel/echo-vue, @laravel/echo-react або @laravel/echo-svelte.
Якщо у вас уже є сторінки, що тримають usePoll заради свіжих даних, а події в застосунку вже надсилаються, live props - очевидна заміна: менше запитів і миттєва реакція замість чекання наступного інтервалу. Якщо бродкастингу в проєкті ще немає, polling лишається простішим вибором, а live props - вагомий аргумент нарешті підняти Reverb. Повний опис з усіма транспортами - на сторінці Live Props документації та в PR #3232 і inertia-laravel #901.
