Partie 8 — Symfony UX : Stimulus, Turbo, LiveComponents

Public : BookLab a un back-office Twig (Partie 7). Il est fonctionnel mais « statique » (chaque action recharge la page). On va le rendre réactif — sans écrire de SPA. Objectif de la partie : maîtriser Symfony UX : Stimulus (petits contrôleurs JS), Turbo (navigation et mises à jour partielles sans rechargement), LiveComponents (composants serveur réactifs), et savoir quand cette approche bat une SPA React — et quand elle ne la remplace pas.

Ce que vous saurez faire à la fin de cette partie

• Écrire des contrôleurs Stimulus pour ajouter du comportement JS ciblé.
• Utiliser Turbo Drive/Frames/Streams pour une navigation et des mises à jour fluides.
• Construire des LiveComponents : des composants Twig qui se re-rendent au serveur quand leur état change.
• Décider, en connaissance de cause, entre Symfony UX et un front Next.js/React.

L’enjeu pour vous, dev Next.js

Vous savez faire du React. La question de cette partie : quand ne PAS en faire ? Symfony UX propose une réactivité progressive (progressive enhancement) : on part de HTML serveur (SEO, robustesse) et on ajoute juste ce qu’il faut de JS. Pour un back-office ou un CRUD interne, c’est souvent plus productif qu’une SPA. Comprendre cette alternative fait de vous un architecte plus complet — et vous aide à placer la frontière entre « rendu serveur Symfony » et « SPA Next.js » (le vrai sujet de tout ce cours).

Chapitres de cette partie

1. Stimulus — des contrôleurs JS légers attachés au HTML (data-controller), l’approche « sprinkles of JS ».
2. Turbo — Drive (navigation SPA-like), Frames (fragments indépendants), Streams (mises à jour DOM poussées par le serveur).
3. LiveComponents — composants Twig réactifs : LiveProp, LiveAction, re-render serveur, sans écrire de JS.
4. UX vs SPA React — le comparatif décisif : quand choisir Symfony UX, quand choisir Next.js.

Prochain chapitre : 8.1 — Stimulus.