Real-time props with Inertia 3.11

When polling stops being the right answer

Some screens need to reflect changes without waiting for the user to do anything. Job queues, deployment status, and homelab metrics are obvious examples. With Inertia, the usual solution used to be polling the server on an interval, even when there was nothing new to display.

Polling is simple and still makes sense for data that changes infrequently or is not especially important. The problem appears when several screens keep asking for the same information and most responses are unchanged. That is where Inertia 3.11 live props fit well: the server signals a change, and the client refreshes only the affected prop.

A prop that listens for events

The goal is not to turn an application into a set of manually managed WebSockets. In Laravel, a prop becomes live with Inertia::live(), using a broadcast event as its trigger. Inertia reads the channel from the event itself, so the page response does not need to repeat that setup.

This example shows a detail page that fetches the order again when Laravel broadcasts OrderUpdated. The update happens through a partial reload of the prop, not a full page navigation. Laravel remains the source of truth, while the frontend receives the resolved state.

use App\Events\OrderUpdated;
use Inertia\Inertia;
 
return Inertia::render('Orders/Show', [
    'order' => Inertia::live(
        fn () => $order->fresh(),
        on: new OrderUpdated($order),
    ),
]);

->live() can also be used with props built through Inertia::defer(), Inertia::once(), Inertia::optional(), or Inertia::always(). That is useful when an expensive section should not load during the first visit but should stay current afterwards. An activity feed, for example, can be deferred initially and then react to new events.

Echo links the browser to broadcasting

On the client side, Inertia needs a real-time transport when the application is created. In Laravel projects, the echo() adapter uses the Echo instance configured through Laravel’s Vue, React, or Svelte Echo packages. Reverb fits this setup when Echo is configured with reverb as its broadcaster.

import { createInertiaApp } from '@inertiajs/vue3'
import { echo } from '@inertiajs/vue3/echo'
import { configureEcho } from '@laravel/echo-vue'
 
configureEcho({
  broadcaster: 'reverb',
})
 
createInertiaApp({
  live: echo(),
})

Once that is in place, Inertia reloads only the props associated with the incoming channel and event. If several props share the same signal, they are refreshed through one partial request. That matters for operational dashboards, where each widget should not have to manage a separate subscription path.

Skipping the partial reload too

The default behavior is sensible: an event says something changed, and Laravel recalculates the prop. Sometimes, though, the event already contains the exact value the page needs. In those cases, Inertia::broadcastProps() can attach props to the broadcast payload so the client applies them without another HTTP request.

use App\Http\Resources\OrderResource;
use Inertia\Inertia;
 
public function broadcastWith(): array
{
    return [
        ...Inertia::broadcastProps([
            'order' => OrderResource::make($this->order),
        ]),
    ];
}

This is useful for small, frequent updates such as job progress or a deployment result. It does not replace event design or remove the need to decide what data the UI needs. It simply avoids an extra server round trip when the value is already available and is appropriate for every subscriber on that channel.

A practical homelab use case

A personal dashboard could broadcast an event when a backup completes, a container changes state, or an automation finishes. An Inertia page can expose the latest known state as a prop and refresh it only when that event arrives. The result is calmer than a dashboard polling every few seconds.

The same approach works well for internal tools in small teams. A deployment board can update a run status, a queue view can show pending work, and an operations screen can display new alerts. Not every part of the application needs to be real-time; it is better to use it where immediate changes add context or remove manual work.

The fine print

Live props are not automatic synchronization for arbitrary browser state. They need broadcast events, a configured transport, and a prop explicitly marked as a listener. If the event never arrives, the prop will not update on its own.

By default, an event triggers a partial reload so the server can resolve the prop again. Inertia::broadcastProps() skips that request, but its payload is delivered to every subscriber on the channel. It should therefore only contain data that is identical and authorized for all of them, not a resource variant based on individual permissions.

There are compatibility limits worth understanding before building a screen around this feature. Merge props cannot be live props. Inertia can also hold live reloads while a tab is hidden and process them once it becomes visible again; pauseWhenHidden: false changes that behavior, but it also means more background network activity.

Frequency control matters as well. You can set throttle per prop or on the transport, preventing a busy stream of events from turning a dashboard into a constant flow of requests. Before replacing polling with events, I would check how often the state actually changes and whether broadcasting is justified for that particular screen.

Source: Laravel News

Official documentation: Inertia.js v3.11.0