Présentation
Symfony UX, un pont entre PHP et JavaScript
Notions théoriques
Qu'est-ce que Symfony UX ?
Symfony UX est une initiative officielle du projet Symfony lancée en 2020 par Fabien Potencier et l'équipe de Symfony. Son but est simple mais ambitieux : permettre aux développeurs PHP de créer des interfaces web riches et interactives sans avoir à maîtriser un framework JavaScript complexe comme React, Vue.js ou Angular.
Concrètement, Symfony UX est une collection de packages PHP/JavaScript qui s'intègrent directement dans une application Symfony. Chaque package apporte une fonctionnalité front-end prête à l'emploi : graphiques, chargement de fichiers, gestion du temps réel, animations, etc.
Symfony UX repose sur Stimulus, une bibliothèque JavaScript légère créée par Basecamp (les créateurs de Ruby on Rails). Stimulus associe des comportements JavaScript à des éléments HTML via des attributs data-*, sans avoir besoin de remplacer tout le HTML de la page.
Le problème que Symfony UX résout
Pendant longtemps, un développeur Symfony devait choisir entre 2 mondes :
- Le monde PHP/Symfony : puissant, structuré, mais limité côté interactivité.
- Le monde JavaScript : riche en interactions, mais complexe à intégrer avec le backend.
Cette séparation forçait les équipes à maintenir 2 codebases distinctes, à gérer des APIs REST, à synchroniser des données entre le serveur et le client. C'était long, coûteux et source d'erreurs.
Symfony UX casse cette frontière. Il permet d'écrire la logique dans PHP et de laisser le framework gérer automatiquement les interactions côté navigateur.
L'architecture de Symfony UX
Symfony UX s'appuie sur 3 piliers technologiques :
- Stimulus (JavaScript)
- Webpack Encore / AssetMapper
- Les composants UX
1. Stimulus (JavaScript)
Stimulus est le moteur JavaScript de Symfony UX.
Stimulus suit un principe simple :
- On écrit un contrôleur Stimulus (un fichier
.js) - On connecte ce contrôleur à un élément HTML via
data-controller="nom-du-controleur" - Stimulus se charge d'attacher le comportement JavaScript à cet élément
2. Webpack Encore / AssetMapper
Pour compiler et distribuer les fichiers JavaScript et CSS, depuis Symfony 6.3, il est consseilé d'utiliser AssetMapper, une solution moderne qui ne nécessite pas Node.js.
AssetMapper est une alternative à Webpack Encore, qui était la solution de build recommandée dans les versions précédentes de Symfony. AssetMapper permet de gérer les assets (JS, CSS) sans configuration complexe et sans dépendance à Node.js, ce qui simplifie grandement le développement.
De nombreux projets utilisent encore Webpack Encore, un wrapper simplifié autour de Webpack, pour gérer les assets.
3. Les composants UX
Symfony UX propose une bibliothèque de composants officiels, chacun étant un package Composer indépendant :
| Composant | Rôle |
|---|---|
symfony/ux-stimulus-bundle | Base de Symfony UX |
symfony/ux-turbo | Navigation sans rechargement de page |
symfony/ux-chart-js | Graphiques via Chart.js |
symfony/ux-dropzone | Zone de dépôt de fichiers |
symfony/ux-cropperjs | Recadrage d'images |
symfony/ux-autocomplete | Champs de recherche autocomplete |
symfony/ux-live-component | Composants Twig réactifs |
symfony/ux-notify | Notifications en temps réel |
symfony/ux-twig-component | Composants Twig réutilisables |
Il n'est pas nécessaire d'installer tous les composants. Chaque package s'installe séparément selon les besoins du projet. C'est le principe de modularité de Symfony UX.
Les avantages de Symfony UX
Productivité accrue Un développeur PHP peut ajouter des interactions riches sans écrire une seule ligne de JavaScript complexe. L'intégration d'un graphique interactif peut se faire en quelques lignes de code Twig et PHP.
Cohérence avec l'écosystème Symfony Les composants UX s'installent via Composer, se configurent comme n'importe quel bundle Symfony, et respectent les conventions du framework (services, configuration YAML, templates Twig).
Pas de séparation frontend/backend Avec des composants comme Live Component, il devient possible de créer des interfaces réactives (filtres, formulaires dynamiques, compteurs en temps réel) entièrement en PHP/Twig, sans écrire d'API REST.
Maintenance simplifiée Un seul langage, une seule logique. Les mises à jour sont gérées via Composer, ce qui simplifie considérablement la maintenance du projet.
Performances natives Symfony UX n'est pas un framework JavaScript complet. Il injecte du comportement sur des pages HTML existantes, ce qui signifie que les pages restent légères et rapides, avec un bon référencement naturel (SEO).
Les inconvénients de Symfony UX
Moins adapté aux SPAs Si le projet nécessite une Single Page Application (SPA) très complexe, avec une logique front-end élaborée (exemple : un éditeur de document collaboratif, un jeu en ligne), Symfony UX montre ses limites. React ou Vue.js seront plus adaptés.
Dépendance à Stimulus Stimulus a ses propres conventions. Pour les développeurs habitués aux frameworks JavaScript modernes (React, Vue), la courbe d'apprentissage peut sembler étrange au début.
Écosystème encore jeune Certains composants sont encore en version bêta. La documentation, bien que sérieuse, est parfois moins fournie que celle de React ou Vue.js.
Débogage parfois complexe Le débogage d'interactions entre PHP et Stimulus peut être moins intuitif que dans un environnement 100% JavaScript.
Comparaison avec d'autres bibliothèques
| Critère | Symfony UX | React | Vue.js | Alpine.js |
|---|---|---|---|---|
| Langage principal | PHP + JS minimal | JavaScript | JavaScript | JavaScript |
| Courbe d'apprentissage | Faible (pour dev PHP) | Élevée | Moyenne | Faible |
| SPA complexe | Moyen | Excellent | Excellent | Moyen |
| Intégration Symfony | Native | Manuel | Manuel | Manuel |
| Taille des bundles JS | Très légère | Lourde | Moyenne | Très légère |
| SEO | Excellent | Moyen (SSR requis) | Moyen (SSR requis) | Excellent |
| Temps réel | Via Live Component | Via hooks/state | Via Vuex | Limité |
- Alpine.js est souvent comparé à Symfony UX car les deux ont une philosophie similaire : enrichir le HTML plutôt que le remplacer.
- La différence majeure est que Symfony UX s'intègre nativement dans Symfony avec des outils PHP, tandis qu'Alpine.js est un outil JavaScript pur.
Symfony UX n'est pas un remplacement de React ou Vue.js. C'est un outil complémentaire qui excelle dans les applications Symfony où l'on veut de l'interactivité sans basculer vers une architecture full-JavaScript.
Quand utiliser Symfony UX ?
Symfony UX est idéal pour :
- Des applications Symfony classiques (sites d'entreprise, back-offices, plateformes e-commerce) qui ont besoin d'interactivité sans refonte complète
- Des équipes composées majoritairement de développeurs PHP
- Des projets où le SEO est important (pages indexables par les moteurs de recherche)
- Des formulaires dynamiques, des tableaux filtrables, des graphiques de données
Symfony UX est moins adapté pour :
- Des applications nécessitant une navigation entièrement côté client (SPA pure)
- Des projets avec une équipe front-end dédiée maîtrisant React ou Vue.js
- Des applications mobiles (React Native, Ionic, etc.)
Test de mémorisation/compréhension
TP pour réfléchir et résoudre des problèmes
L'objectif de ce TP est d'explorer concrètement la structure d'un projet Symfony UX :
- en clonant le dépôt officiel,
- en analysant l'organisation des fichiers
- et en comprenant comment les composants PHP et JavaScript s'articulent.
Aucune installation complète de l'application n'est requise : il s'agit d'une exploration guidée du code source.
Étape 1 — Vérifier les prérequis et préparer l'environnement
Avant de cloner le dépôt, assurez-vous que Git est disponible sur votre machine Windows.
Ouvrez un terminal et exécutez la commande suivante :
git --version
Si Git n'est pas reconnu, téléchargez et installez-le depuis https://git-scm.com/download/win. Laissez toutes les options par défaut lors de l'installation, puis fermez et rouvrez votre terminal.
Vérifiez également que PHP est disponible :
php --version
Vous devriez obtenir une version PHP 8.1 ou supérieure. Vérifiez enfin que Composer est installé :
composer --version
Avant de démarrer un projet ou de cloner un dépôt, toujours vérifier que les outils nécessaires sont installés et à la bonne version. Un environnement mal configuré provoque des erreurs difficiles à diagnostiquer. Consacrer 2 minutes à cette vérification peut éviter des heures de débogage.
Étape 2 — Cloner le dépôt officiel de Symfony UX
Dans votre terminal, placez-vous dans le dossier de vos Documents.
Clonez ensuite le dépôt officiel de Symfony UX :
git clone https://github.com/symfony/ux.git
Une fois le clonage terminé, ouvrez le dossier dans VS Code :
code ux
Prenez le temps d'observer l'arborescence générale affichée dans l'explorateur de fichiers de VS Code avant de passer à l'étape suivante.
Cloner et explorer le dépôt d'une bibliothèque que l'on utilise est l'une des meilleures façons de progresser. On comprend les conventions, l'architecture, et les patterns appliqués par les auteurs. C'est bien plus formateur que de se limiter à la documentation.
Pour la suite du TP, vous devrez créer un fichier notes.md à la racine du projet.
Quand vous serez invité à répondre à des questions, écrivez vos réponses dans ce fichier notes.md en utilisant un format clair (numérotation, titres, etc.).
À la fin du TP, vous aurez un document de notes complet que :
- vous devrez envoyer à votre enseignant, par EcoleDirecte, pour validation,
- vous pourrez relire pour réviser les concepts clés de Symfony UX.
Étape 3 — Analyser la structure du composant Chart.js
Dans VS Code, naviguez vers le dossier src/Chartjs/.
Dépliez l'arborescence complète de ce dossier et identifiez les fichiers présents.
Répondez par écrit (dans votre fichier notes.md à la racine du projet) aux questions suivantes :
- Combien de fichiers
.phpcontient le dossiersrc/Chartjs/src/? - Quel est le rôle supposé du fichier
ChartExtension.phpd'après son nom et son emplacement ? - Quel fichier JavaScript constitue le contrôleur Stimulus de ce composant ?
- Que contient le fichier
composer.jsonà la racine desrc/Chartjs/? Identifiez notamment la clénameet la clérequire.
Chaque composant Symfony UX est un package Composer indépendant avec son propre
composer.json. La clé name est ce que l'on utilise dans composer require.
Prendre l'habitude de lire le composer.json d'une bibliothèque permet de comprendre
ses dépendances, sa version minimale de PHP, et son périmètre fonctionnel.
Étape 4 — Lire et comprendre le contrôleur Stimulus
Ouvrez le fichier src/Chartjs/assets/src/controller.ts dans VS Code.
Lisez attentivement son contenu, puis répondez dans votre fichier notes.md :
- De quelle classe ce contrôleur hérite-t-il ?
- Quelle méthode est appelée automatiquement par Stimulus lorsque l'élément HTML associé est inséré dans le DOM ?
- Comment les données du graphique (type, labels, datasets) sont-elles transmises depuis PHP vers ce fichier JavaScript ?
- Quelle ligne instancie réellement le graphique Chart.js ?
Ajoutez ensuite un commentaire sur chaque ligne significative du fichier controller.ts directement dans votre fichier notes.md, en expliquant ce qu'elle fait avec vos propres mots.
Dans Symfony UX, PHP encode les données en JSON et les place dans des attributs data-*
lors du rendu Twig. Stimulus les récupère côté navigateur avec JSON.parse().
Ce pattern évite les appels AJAX et garantit que les données sont disponibles
dès le chargement de la page. C'est simple, performant, et SEO-friendly.
Étape 5 — Comparer la structure de 2 composants différents
Pour comprendre la cohérence architecturale de Symfony UX, comparez la structure du composant Chartjs avec celle du composant Dropzone (src/Dropzone/).
Dans votre fichier notes.md, remplissez le tableau suivant :
| Critère | Chartjs | Dropzone |
|---|---|---|
| Nom du contrôleur Stimulus (fichier .js) | ||
| Présence d'une extension Twig | ||
| Dépendance JavaScript tierce | ||
Nom du package Composer (name dans composer.json) |
Après avoir rempli le tableau, rédigez un court paragraphe (5 à 8 lignes) dans notes.md sur ce que cette comparaison vous apprend sur l'architecture de Symfony UX.
Quand on retrouve exactement la même structure dans tous les composants d'une bibliothèque (même nom de fichier, même emplacement, même convention), c'est le signe d'une architecture intentionnelle. Cette cohérence réduit la charge cognitive : apprendre un composant, c'est apprendre tous les composants. Reproduire ce principe dans ses propres projets facilite l'onboarding et la maintenance.
Une solution
Vous devez être connecté pour voir le contenu.