Image de couverture : Symfony 8.2 : vos formulaires lisent enfin les types de vos classes
PHP & Frameworks

Symfony 8.2 : vos formulaires lisent enfin les types de vos classes

4 min de lecture
41 vues
Sébastien Muler

Et si vos formulaires cessaient de redéclarer ce que PHP sait déjà ?

Dans beaucoup de projets Symfony, le formulaire est adossé à un DTO ou à une entité dont les propriétés sont typées. Pourtant, au moment de construire le FormType, on répète presque mot pour mot ces informations : ce champ est un entier, celui-ci est une date, celui-là est un booléen. La version 8.2 du composant Form s'attaque à cette redondance en s'appuyant directement sur les types déclarés dans vos classes.

Le problème : une information écrite deux fois

Prenons un DTO d'inscription classique :

final class RegistrationData
{
    public string $email = '';
    public int $age = 18;
    public bool $newsletter = false;
    public ?\DateTimeImmutable $birthDate = null;
}

Pour l'exposer dans un formulaire, il fallait jusqu'ici décrire chaque champ avec son type de formulaire correspondant :

$builder
    ->add('email', EmailType::class)
    ->add('age', IntegerType::class)
    ->add('newsletter', CheckboxType::class)
    ->add('birthDate', DateType::class);

Ce code n'est pas difficile à écrire, mais il a un coût. Chaque modification d'un type de propriété oblige à penser à mettre à jour le formulaire. Quand on change int en float, ou qu'on rend une propriété nullable, l'oubli se paie par un comportement subtilement faux, souvent découvert tard.

Ce que change Symfony 8.2

Le principe est simple : le composant lit les types de vos propriétés et en déduit le type de champ le plus adapté, ainsi que certaines options qui en découlent, comme le caractère obligatoire ou facultatif d'un champ lorsque la propriété est nullable. Vous ne précisez explicitement que ce qui sort de l'ordinaire.

En pratique, l'idée est de pouvoir décrire un formulaire en s'appuyant sur la classe elle-même, sans énumérer des types de champs qui n'apportent aucune information nouvelle. Les types de formulaire explicites restent disponibles, et ils gardent la priorité dès que vous voulez un rendu particulier : un TextareaType pour une chaîne longue, un ChoiceType pour une valeur contrainte, une option personnalisée.

Cette évolution s'inscrit dans une tendance plus large de l'écosystème : exploiter le système de types de PHP comme source de vérité plutôt que de multiplier les déclarations parallèles. Le même mouvement existe déjà côté sérialisation, validation et mapping de requêtes.

Comment préparer la migration

Avant de passer à la 8.2, quelques réflexes évitent les mauvaises surprises :

  • Typez rigoureusement vos DTO et entités. L'inférence ne vaut que ce que valent vos déclarations : une propriété sans type ou typée mixed n'apportera aucune aide.
  • Repérez les formulaires qui se contentent de répéter les types. Ce sont les premiers candidats à l'allègement.
  • Conservez les déclarations explicites quand le rendu compte. Si un champ doit s'afficher d'une façon précise, mieux vaut le dire clairement que de dépendre d'une déduction.
  • Vérifiez vos tests de formulaires. Après simplification, assurez-vous que les champs obligatoires, facultatifs et les conversions de valeurs se comportent comme avant.
  • Lisez les notes de version avant de migrer, pour connaître les détails exacts de l'API et d'éventuelles incompatibilités.

Une approche progressive fonctionne bien : on commence par un formulaire simple et peu risqué, on compare le résultat avec l'ancienne version, puis on étend aux autres.

Pourquoi c'est une bonne nouvelle pour la maintenance

Le gain principal n'est pas de gagner quelques lignes. C'est de réduire les endroits où une même règle doit être maintenue. Un type de propriété devient une seule source de vérité, et le formulaire suit. Pour une équipe qui gère de nombreux écrans de saisie, c'est moins de code répétitif à relire en revue, moins de divergences entre le modèle et l'interface, et des évolutions plus rapides.

Il faut toutefois garder en tête que l'inférence reste un confort, pas une baguette magique : pour les cas métier spécifiques, la déclaration explicite demeure la plus lisible.

Conclusion

Symfony 8.2 poursuit le travail de simplification du composant Form en lui faisant exploiter les types que vous écrivez déjà. Si vos classes sont bien typées, vous pourrez alléger vos formulaires sans perdre en contrôle. Le détail complet de la fonctionnalité est présenté dans l'article d'origine : New in Symfony 8.2: Forms That Read Your Types.

Partager cet article

Et votre site, il vaut quoi ?

Vitesse, accessibilité, référencement technique. Le rapport est écrit pour un dirigeant, pas pour un développeur. Gratuit, sans inscription.

Tester mon site