Single File Components en Laravel: La forma más rápida de programar hoy

▶

Me están empezando a gustar mucho los Single File Components (SFC) y quiero explicarte mis razones. Si has estado viviendo bajo una piedra, me refiero a la funcionalidad de Livewire en Laravel donde la lógica (PHP) y la vista (Blade/HTML) residen en un único archivo:

resources\views\pages\dashboard\category\list.blade.php

<?php
new #[Title('Categorías')] 
class extends Component {
    

    function with(): array
    {
        return [
            'categories' => 
            $this->getPaginatedResults(),
        ];
    }
}
?>

<div class="space-y-6">
    <flux:card>
        
    </flux:card>  
</div>

Al principio no me convencía. De hecho, hace un año publiqué que no me gustaba el enfoque de Volt (cuya característica principal es precisamente el archivo único). Sin embargo, he cambiado de opinión debido a cómo está evolucionando el ecosistema y la eficiencia que aporta al flujo de trabajo.

Migrar desde cero: La oportunidad de limpiar el código

Actualmente, estoy migrando mi plataforma, Desarrollo Libre, de Laravel 12 a Laravel 13. Aunque funcionalmente es la misma aplicación, hacer una migración desde cero me permite corregir errores de organización que arrastraba desde hace años.

Cuando eres un desarrollador solitario y tu aplicación crece, es fácil terminar con un desastre de archivos mal nombrados o carpetas desorganizadas. Migrar poco a poco, empezando por lo más pesado (como el Dashboard), me ha permitido apreciar las ventajas de los SFC.

1. Organización y eficiencia en el scroll

En el esquema antiguo, tenía la clase principal en un lugar y la vista en otro. Si quería buscar un archivo para guardar datos, escribía "Save" y me aparecía un listado enorme de archivos llamados igual: save.php y save.blade.php repartidos por decenas de carpetas. Era un engorro.

Con los Single File Components, todo está a la mano:

• Menos archivos abiertos: No tienes que saltar entre la carpeta app/Livewire y resources/views/livewire.
• Menos navegación: He reducido a la mitad el recorrido que tengo que hacer en el explorador de archivos en vez de los de tipo NO single que tengo que buscar la clase por un lado y la vista por otro con ubicaciones MUY distintas:
  • app\Livewire\Dashboard\Books\BookSave.php
  • resources\views\livewire\dashboard\book\save.blade.php
• Modularización: Es mucho más sencillo crear componentes reutilizables y limpios.

2. Enrutamiento más limpio

En Livewire moderno, el enrutamiento de componentes tipo página es mucho más directo. Antes, dependíamos de importaciones de clases constantes. Ahora, podemos definir la ruta de esta forma:

Route::livewire('/uri', 'nombre-del-componente');

Al ser una referencia basada en texto, si renombras un archivo o cambias su ubicación, actualizar la ruta es extremadamente sencillo. Todo queda más legible y menos propenso a errores de namespace o importaciones fallidas lo cual sucede en el esquema tradicional al tener que cambiar los use y el namespace…

El debate: ¿Actualizar o empezar de cero?

Laravel ofrece herramientas como Laravel Boost para automatizar actualizaciones, pero yo sigo prefiriendo la migración manual en proyectos grandes por varias razones:

1. Eliminación de "Paquetes Zombi": Un proyecto actualizado desde Laravel 6 puede arrastrar paquetes antiguos como laravel/ui, conviviendo con Breeze o Jetstream. Es un Frankenstein. Al empezar de cero, solo instalas lo que realmente necesitas (como Flux o las versiones más modernas de Fortify).
2. Migraciones de Base de Datos: Aprovecho para limpiar mis migraciones. En lugar de tener 50 archivos de add_column_to_table_x, prefiero consolidar la estructura de la tabla en un solo archivo, generar el SQL y ejecutarlo. Al migrar de cero, compruebas que tus migraciones están bien estructuradas y no referencian columnas que aún no existen.
3. Configuraciones Modernas: Laravel 13 incluye por defecto mejoras (como los scripts de Livewire inyectados automáticamente) que a veces se pierden o se vuelven un lío de configurar manualmente en un proyecto viejo.

No todo es perfecto: Los puntos negativos

A pesar de las ventajas, hay algo que todavía me frustra de los SFC: la ayuda del editor (IntelliSense).

He notado que en VS Code se pierde mucha potencia de autocompletado y detección de errores. A veces me falta un punto y coma y el editor no me "grita", o las importaciones automáticas fallan porque el editor se confunde entre el bloque Blade y el bloque PHP. Es algo que seguramente mejorará con el tiempo, pero actualmente es un punto en contra para quienes dependemos mucho de la ayuda visual del IDE.

Conclusión

Si estás trabajando en un ecosistema que cambia tan rápido como Laravel, Livewire o Inertia, mi consejo es: cada 2 o 3 años, considera reconstruir tu proyecto base desde cero. Te da un control total, eliminas basura técnica y te obliga a aprender las nuevas convenciones del framework.

Si quieres aprender más sobre cómo gestionar estos cambios, recuerda que tengo mis cursos y libros actualizados sobre el ecosistema de Laravel, donde grabo todo desde cero para que no te pierdas en versiones antiguas.

Te dejo el articulo anterior:

NO me gusta Laravel Livewire Volt

▶

Quería comentar rápidamente mi opinión sobre Laravel Livewire Volt, esta tecnología que Laravel nos ofrece. No es obligatoria todavía; al menos, te la propone al crear un proyecto en Livewire, preguntándote si quieres utilizarla o no. Una vez elegida, la instala y a partir de ahí la utiliza.

Básicamente, Volt permite crear en un solo archivo Blade tanto la lógica como la parte visual, es decir, la interfaz. Funciona como un componente en Vue, donde conviven la lógica y la vista en el mismo archivo.

use function Livewire\Volt\{state};
 
state(['count' => 0]);
 
$increment = fn () => $this->count++;
 
?>
 
<div>
    <h1>{{ $count }}</h1>
    <button wire:click="increment">+</button>
</div>

Mis opiniones sobre Volt

• Dificulta la lectura: Al tener archivos más densos que combinan el Blade y la capa de control, se complica leer el código, sobre todo en proyectos grandes.
• Dificulta el mantenimiento: Puedes tener componentes tradicionales en Livewire o con Volt, lo que genera el mismo problema que con los componentes anónimos en Laravel: bifurcaciones dentro del proyecto sin un motivo claro.
• Bifurcación innecesaria: Un mismo componente puede existir en tu proyecto con dos archivos: el Blade y su clase separada, o todo en un solo archivo. Esto puede depender de la cantidad de líneas, pero es subjetivo: ¿cuántas líneas son muchas? ¿cuántas son pocas? La lógica puede ser pequeña, pero la vista puede ser extensa, y eso puede confundir sobre si debes dividir el archivo o no.
• Inconsistencia en el patrón de componentes: Personalmente, prefiero que todos los componentes sigan un mismo patrón, en lugar de tener algunos en un solo archivo y otros divididos. Esto es cuestión de gusto, pero considero que aporta más claridad y consistencia al proyecto.
• Problemas con componentes anónimos: Los componentes anónimos son archivos Blade que no tienen lógica adicional. Son útiles para elementos simples, como botones, pero a veces es confuso identificar si un componente tiene una clase detrás o es totalmente anónimo. Esto genera cierta incertidumbre al leer o mantener el código.
Aplicaciones web y herramientas online

Conclusión

No estoy diciendo que Laravel Livewire Volt sea una mala tecnología ni que deba evitarse, pero considero que puede generar confusión y dificultades de mantenimiento en algunos proyectos. Simplemente quería compartir mi opinión y las razones por las que personalmente no suelo utilizar Volt en todos mis desarrollos.