Sylius 2 : adapter le frontend existant à Symfony UX ?

On adapte un frontend existant à Symfony UX en réécrivant chaque comportement jQuery dans la bonne brique : un contrôleur Stimulus pour une interaction locale (ouvrir, filtrer, basculer), un composant Twig ou un Live Component quand l'élément dépend de données du serveur (panier, prix d'une déclinaison, adresse), et un contrôleur Stimulus qui enveloppe la bibliothèque tierce que l'on ne peut pas remplacer. On ne traduit pas le code jQuery ligne à ligne : on repart du comportement attendu, parce que Sylius 2 a retiré jQuery et les routes partielles sur lesquelles ces scripts s'appuyaient.

Je suis développeur Sylius indépendant et j'ai mené des montées de version 1.x vers 2.x de boutiques en production. Sur une boutique qui vit depuis plusieurs années, le JavaScript s'est accumulé partout : dans les fichiers du thème, dans des balises script au milieu des gabarits, dans les plugins. C'est ce code éparpillé qui rend l'adaptation à Symfony UX plus longue qu'elle n'en a l'air.

Que dit la documentation officielle sur Symfony UX dans Sylius 2 ?

Le guide officiel UPGRADE-2.0 indique que l'essentiel du JavaScript existant a été remplacé par Symfony UX avec Stimulus, Live Components compris, ce qui a permis de retirer jQuery. Il précise aussi que toutes les routes partielles rendues dans les gabarits ont été supprimées et remplacées par des composants Twig. Le même guide fait enregistrer dans le projet les bundles TwigComponent, StimulusBundle, LiveComponent et Autocomplete de Symfony UX.

Dans le code de Sylius 2, le panier et le tunnel de commande reposent sur ces composants. Les notes de sécurité du guide citent par exemple le composant de formulaire d'adresse du tunnel et les composants de résumé et de widget du panier, et la liste des routes supprimées comprend sylius_shop_ajax_cart_add_item et sylius_shop_partial_cart_summary. Un script maison qui appelait ces routes en Ajax ne reçoit donc plus de réponse.

Comment inventorier le JavaScript à adapter ?

Je cherche dans tout le projet trois familles de code : les appels jQuery ($(document).ready, $.ajax, les sélecteurs), les modules Semantic UI initialisés en JavaScript (menus déroulants, fenêtres modales, onglets, accordéons), et les appels vers des routes Sylius, en particulier les routes partielles et Ajax. Chaque script trouvé reçoit une fiche : ce qu'il fait pour l'utilisateur, sur quelle page, et de quelles données il a besoin.

Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, repère les gabarits surchargés et les classes Semantic UI, et chiffre chaque problème en heures. Je complète à la main pour le JavaScript glissé dans les gabarits et pour les plugins, que l'analyse statique ne décrit pas toujours finement.

Quelle brique Symfony UX pour quel comportement ?

Réécrire une interaction en contrôleur Stimulus

Un contrôleur Stimulus est une classe JavaScript reliée à un élément par l'attribut data-controller. Il démarre quand l'élément apparaît dans la page et s'arrête quand il disparaît, ce qui règle d'office le problème classique des scripts jQuery qui ne s'appliquent pas aux éléments ajoutés après le chargement. La documentation de StimulusBundle décrit les fonctions Twig stimulus_controller, stimulus_action et stimulus_target, qui produisent ces attributs dans vos gabarits.

// assets/shop/controllers/stock_alert_controller.jsimport { Controller } from '@hotwired/stimulus';export default class extends Controller {    static targets = ['form'];    toggle() {        this.formTarget.hidden = !this.formTarget.hidden;    }}

Dans le gabarit, le bloc reçoit data-controller="stock-alert", le bouton data-action="click->stock-alert#toggle" et le formulaire data-stock-alert-target="form". Le comportement est le même qu'avant, mais il vit dans un fichier rangé, déclaré une fois, et réutilisable.

Confier au serveur ce qui dépend des données

Selon la documentation des Live Components, un Live Component est un composant Twig qui se met à jour automatiquement dans la page quand l'utilisateur interagit avec lui. Pour un prix qui change selon la déclinaison choisie ou un récapitulatif de panier, c'est plus simple et plus sûr qu'un script qui reconstruit du HTML à la main : le calcul reste côté serveur, dans Sylius. Avant d'écrire un composant, je vérifie toujours si Sylius 2 en fournit déjà un que l'on peut étendre par un hook. Le cas particulier de l'ajout au panier est traité dans l'article sur l'ajout au panier sans Symfony UX.

Quels pièges pour le dirigeant ?

Le plus coûteux est invisible : le suivi des conversions. Les déclencheurs de votre gestionnaire de balises qui écoutaient un clic sur un bouton précis, une classe Semantic UI ou un événement jQuery ne se déclenchent plus si le balisage change. Les ventes continuent, mais vos tableaux de bord publicitaires se vident, et vos campagnes s'optimisent sur des données fausses. Je liste ces déclencheurs avant la migration et je les reteste avec de vraies commandes de test.

Le second piège est de tout réécrire d'un coup. Je traite d'abord les comportements du tunnel de commande et de la fiche produit, puis le reste. Si vous voulez savoir combien de scripts sont concernés chez vous, le diagnostic de migration Sylius 2 en fait l'inventaire, et la configuration de build qui les accueille est décrite dans l'article sur Webpack Encore et l'organisation frontend de Sylius 2.

Ce que je vous propose

Les correctifs de sécurité de Sylius 1.14 s'arrêtent le 31 décembre 2026. L'adaptation du JavaScript à Symfony UX se planifie bien quand on sait exactement combien de comportements il faut reprendre, et lesquels touchent le chiffre d'affaires. Je lance Sylius Upgrade Analyzer sur votre projet, j'inventorie vos scripts et vos déclencheurs de suivi, et je vous remets un diagnostic offert avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées.