Volver al blog
LaravelPHPDevOps

Props en tiempo real con Inertia 3.11

Inertia 3.11 permite refrescar props de Laravel con eventos broadcast y sin recurrir al polling.

Por Isma5 min de lectura

Cuando el polling empieza a ser una mala solución

Hay pantallas que necesitan reflejar cambios sin que el usuario pulse nada. Una cola de trabajos, el estado de un despliegue o unas métricas del homelab son ejemplos claros. Hasta ahora, la salida habitual con Inertia era consultar el servidor cada cierto tiempo, aunque no hubiese nada nuevo que mostrar.

El polling es sencillo y, para datos poco críticos o poco frecuentes, sigue siendo una opción válida. El problema llega cuando varias pantallas consultan lo mismo de forma periódica y la mayoría de respuestas no traen cambios. Ahí es donde las live props de Inertia 3.11 encajan mejor: el servidor avisa cuando hay una novedad y el cliente actualiza solo la prop afectada.

Una prop que escucha eventos

La idea no es convertir toda la aplicación en una colección de WebSockets manuales. En Laravel, se marca una prop como viva con Inertia::live() y se indica el evento broadcast que debe activarla. Inertia obtiene el canal desde el propio evento, por lo que no hace falta duplicar esa configuración en la respuesta de la página.

Este ejemplo muestra una página de detalle que vuelve a obtener el pedido cuando Laravel emite OrderUpdated. La actualización se realiza mediante una recarga parcial de esa prop, no con una navegación completa. Eso mantiene la responsabilidad donde debe estar: Laravel sigue siendo la fuente de verdad y el frontend recibe el estado resuelto.

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

También se puede aplicar ->live() a props que ya usan mecanismos como Inertia::defer(), Inertia::once(), Inertia::optional() o Inertia::always(). Esto es útil si una sección costosa no debe cargarse al abrir la página, pero sí debe mantenerse actualizada después. Por ejemplo, un historial de actividad puede diferirse en la carga inicial y reaccionar luego a nuevos eventos.

Echo conecta el navegador con el broadcast

En el cliente hay que proporcionar un transporte de tiempo real al crear la aplicación de Inertia. Para un proyecto Laravel, el adaptador echo() usa la instancia configurada con los paquetes de Laravel Echo para Vue, React o Svelte. Reverb encaja en este flujo al configurarse como broadcaster de Echo.

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

A partir de ahí, cuando llega el evento correspondiente, Inertia solicita de nuevo únicamente las props que comparten ese canal y evento. Si varias props deben actualizarse por la misma señal, Inertia las agrupa en una única recarga parcial. Es un detalle importante para paneles operativos: se evita montar lógica de suscripción distinta para cada widget.

Evitar incluso la recarga parcial

El comportamiento normal es razonable: el evento indica que algo cambió y Laravel recalcula la prop. Pero hay casos donde el evento ya conoce exactamente el valor que debe aparecer en pantalla. Para esos casos, Inertia::broadcastProps() permite incluir props en el payload broadcast y aplicarlas en el cliente sin lanzar otra petición HTTP.

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

Esto puede venir bien para estados pequeños y frecuentes, como el progreso de una tarea o el resultado de un despliegue. No sustituye el diseño del evento ni elimina la necesidad de decidir qué datos necesita la interfaz. Simplemente evita una vuelta adicional al servidor cuando el dato ya está disponible y es válido para todos los suscriptores del canal.

Un caso práctico para un homelab

En un panel propio podría emitir eventos cuando termina un backup, cambia el estado de un contenedor o finaliza una automatización. La página de Inertia puede mostrar una prop con el último estado conocido y refrescarla solo cuando llega ese evento. El resultado es una interfaz más tranquila que un panel haciendo consultas cada pocos segundos.

También lo veo útil en herramientas internas de equipos pequeños. Un panel de despliegues puede actualizar el estado de una ejecución, una cola puede reflejar trabajos pendientes y una vista de operaciones puede mostrar alertas nuevas. No hace falta que todo sea tiempo real: basta con elegir las zonas donde el cambio inmediato aporta contexto o reduce acciones manuales.

La letra pequeña

Las live props no son una sincronización mágica de cualquier estado del navegador. Necesitan eventos broadcast, un transporte configurado y una prop declarada explícitamente para escuchar esos eventos. Si el evento no llega, la prop no se actualiza por sí sola.

Por defecto, recibir un evento provoca una recarga parcial para recalcular la prop en el servidor. Inertia::broadcastProps() evita esa petición, pero el payload se entrega a todos los suscriptores del canal. Por eso solo debe transportar datos idénticos y autorizados para todos ellos; no es el lugar para enviar una variante del recurso según permisos individuales.

Hay límites de compatibilidad que conviene conocer antes de diseñar una pantalla alrededor de esta función. Las merge props no pueden ser live props. Además, Inertia puede pausar las recargas mientras la pestaña está oculta y procesarlas cuando vuelve a estar visible; se puede cambiar ese comportamiento con pauseWhenHidden: false, pero hacerlo tiene coste de red y de trabajo en segundo plano.

También hay control de frecuencia. Se puede definir throttle por prop o en el transporte para evitar que una secuencia intensa de eventos convierta el panel en una sucesión de peticiones. Antes de cambiar polling por eventos, revisaría qué frecuencia real tienen los cambios y si la complejidad de broadcasting compensa para esa pantalla concreta.


Fuente: Laravel News

Documentación oficial: Inertia.js v3.11.0

Newsletter

Lo que aprendo programando con IA, cada dos semanas en tu correo.

Cifras reales, errores incluidos. Sin spam y te das de baja con un clic.

Sin spam y te das de baja con un clic. Uso tu correo solo para enviarte esto y la newsletter. Más en la política de privacidad.