Lo UNICO que le falta a Laravel Livewire para ser perfecto... Un gestor de Estado

Por aquí quería traer otro video de opinión, relacionado con uno que publiqué recientemente. Como siempre digo, puedes buscarlo en mi canal de YouTube si no lo has visto. Y si ya lo viste, sabes que suelo compartir mis impresiones sobre tecnologías, especialmente del ecosistema de Laravel, que es donde estoy más enfocado actualmente.

Inertia y su enfoque

Ya he comentado en otros videos algunas cosas que no me terminan de convencer de Inertia. Lo considero más que todo una tecnología útil si lo que quieres es trabajar directamente con Vue y listo, lo cual ya es bastante. Pero, fuera de eso, no creo que Inertia tenga algo especial que tú digas: "esto me viene perfecto para tal caso", salvo que, repito, quieras usar Vue.

Livewire: ¿más todo terreno?

Por otro lado, Livewire me parece más "todo terreno" si lo comparamos con Inertia. No es que uno diga "necesito crear este proyecto con Alpine y punto", pero sí destaca por la flexibilidad que ofrece.

Ya con esto resumo un poco lo que he comentado en otros videos. Sin embargo, quería tocar un aspecto que para mí marcaría una diferencia clave y que haría que Livewire fuera casi perfecto.

Alpine vs Vue: lo que me gustaría ver

Antes comenté que me encantaría que Livewire empleara Vue en vez de usar Alpine, Livewire usara Vue, porque Alpine a veces me resulta un poco engorroso. Sirve para cosas sencillas, pero cuando intentas escalar, puede volverse algo molesto. Quizás es solo mi percepción porque he trabajado mucho más con Vue, pero igual quería mencionarlo.

Todo esto surgió a raíz de un comentario que recibí recientemente. Como siempre, cuando hablas de una tecnología, aparecen sus defensores —lo cual está bien, cada quien tiene su punto de vista—. Uno de esos comentarios me llamó la atención: la persona decía que no le parecía complejo trabajar con Livewire.

Y tiene razón, todo es cuestión de percepción. Yo digo que es complejo porque he trabajado con muchas tecnologías, y sé cómo hacer la misma lógica en otras herramientas donde resulta más sencillo. Y el punto que siempre menciono es: la comunicación entre componentes en Livewire puede ser una pesadilla.

Comunicación entre componentes: el verdadero dilema

Cuando tienes varios componentes anidados —no solo padre e hijo, sino nietos o bisnietos—, como mostramos en el curso básico de Livewire, se vuelve muy engorroso. Tienes que pasar mensajes mediante eventos, registrar los listeners en el padre, y desde ahí lanzar los eventos. Todo eso puede ser muy abstracto y poco claro para otro desarrollador que llegue al proyecto.

Entonces, me puse a pensar: ¿cómo hacen esto otras tecnologías?

Comparación con otras tecnologías: Vue y Flutter

Yo principalmente trabajo también con Vue y Flutter, tecnologías fuertemente modulares y basadas en componentes (o widgets, en el caso de Flutter).

En ambas, la comunicación padre-hijo-nieto no es problema, pero también llega un punto donde la jerarquía crece y la cosa se complica. En ese momento, lo que se recomienda es usar un gestor de estado.

En Flutter
Flutter tiene muchas opciones:

1. Provider
2. Bloc
3. Redux
4. Riverpod

Yo he trabajado principalmente con Provider y algo de Redux. Bloc nunca me convenció, pero es una opción válida y usada.

En Vue
En Vue también tenemos gestores de estado:

1. Vuex
2. Pinia, que es más moderno y mucho más intuitivo.

Personalmente, prefiero Pinia por su simplicidad.

¿Qué es un gestor de estado?

Un gestor de estado es simplemente una capa superior que configuras sobre tu aplicación para compartir y modificar datos entre componentes.

Por ejemplo, supongamos que tienes el nombre del usuario en el layout principal, y lo quieres modificar desde un componente que está tres o cuatro niveles abajo. Con un gestor de estado:

• Colocas el nombre en el store.
• Cualquier componente puede acceder a ese dato (getter).
• Y también puede modificarlo (setter).

El cambio se refleja automáticamente en todo el árbol de componentes.

Esto se puede hacer sin tener que propagar eventos de bisnieto a nieto, de nieto a hijo, de hijo a padre y así sucesivamente, como ocurre en Livewire.

¿Por qué Livewire necesita esto?

Livewire no tiene un gestor de estado. Y eso complica mucho las cosas cuando tu proyecto crece.

Imagínate pasar datos desde un componente bisnieto al layout principal, pasando por toda la jerarquía intermedia… Es simplemente poco sostenible.

Es por eso que en Vue, React, Angular, Flutter y otros frameworks surgen los gestores de estado, para evitar este lío. Y por eso creo que Livewire también lo necesita urgentemente.

¿Cómo podría implementarse?

Idealmente, Laravel Livewire podría incorporar algo como:

• Un componente especial que funcione como store.
• O una capa adicional que sirva para centralizar el estado.

No necesariamente debe ser un componente visual, sino algo que se configure y permita compartir información de forma más clara entre cualquier parte de la jerarquía.