On n’apprend pas une techno avec le projet le plus utile, mais avec celui qui donne envie d’y revenir le soir. Pour moi, ça a été un Pokédex. pokedwwmm est mon bac à sable Symfony : un Pokédex de la première génération, monté autour des Twig Components, qui m’a servi de prétexte pour creuser un mécanisme du framework dont la doc est encore un peu maigre.
Le souci, quand on découvre les Twig Components, c’est qu’on tombe toujours sur les trois mêmes exemples : un compteur, un bouton, un formulaire. Rien qui pousse vraiment le concept. Le Pokédex Gen 1, lui, est parfait pour ça : 151 entrées, des types multiples, des stats qui varient, des illustrations, des relations. Chaque morceau de page devient naturellement un composant — la carte d’un Pokémon, le badge de type, la barre de stat.
Concrètement, le site liste les 151 Pokémon avec leur illustration officielle, propose une fiche détaillée par créature (types, stats, description, dimensions) et des filtres par type aux couleurs fidèles aux jeux. J’ai même poussé le détail jusqu’aux favicons : chaque page affiche la Pokéball qui lui correspond — Master Ball, Ultra Ball, Great Ball — en SVG vectoriel.
Côté technique, c’est du Symfony avec Twig Components (propriétés public obligatoires, on s’y fait vite), un front en Twig + Asset Mapper sans framework JS, et des données lues depuis un JSON local plutôt qu’une base. Ce choix est assumé : pour ce périmètre, sortir Doctrine et une base relationnelle aurait été de l’over-engineering pur.
Et puis il y a eu la surprise du dataset. Le JSON public que j’utilisais comme source contenait des erreurs — des types secondaires manquants, des noms mal orthographiés — que j’ai dû corriger à la main. La leçon est restée : même un jeu de données populaire et réputé fiable a ses trous, et il faut toujours s’attendre à mettre les mains dedans. Un projet n’a pas besoin d’être ambitieux pour t’apprendre quelque chose de concret.