Passer à Strapi v4 et créer un blog : mes premiers mois chez Troopers.

Après une formation à la Wild Code School où j’ai appris le métier de développeur web, avec un focus sur React en front, je suis arrivé chez Troopers pour un stage. J’ai très rapidement été mis dans le bain : Marie, une développeuse front, partait dans trois semaines et je devais l’aider à terminer ce qu’elle avait déjà bien entamé : finir de migrer le site de l’agence depuis Strapi v3 vers la v4 du cms, et créer tous les composants et pages du nouveau blog avec Next.js et TypeScript. Anciennement sur un autre domaine (slash.troopers.coop), ce blog est désormais intégré au site, entièrement redesigné et repensé.

Étant junior, j’ai encore tout à apprendre, de nombreux exemples feront probablement transparaître ce fait dans l’article qui vient. En voici un premier : j’ai cru Marie quand elle m’a dit « t'inquiètes, trois semaines c’est large ».

Le plus dur est fait

L’enjeu du projet était donc double : migrer sur Strapi v4 et créer le nouveau blog. La migration sur la v4 était bien avancée. Le repo était créé et configuré, la plupart du code ainsi que du contenu avait déjà été migré sauf quelques slices. Pour chacun d’eux il fallait : Créer le slice sur Strapi Mettre à jour le fragment GraphQL du front Mettre à jour le typage du front Mettre à jour la structure de donnée du front Mettre à jour le storybook (un outil permettant de documenter les composants d’un projet) Mettre en place des éventuelles modifications de fonctionnement

Mettre à jour les fragments a été l’occasion de découvrir GraphQL et Apollo, des structures d’API. Je suis plusieurs fois resté perplexe devant des erreurs 400 d’origine diverses : typos, mauvaise structure de requête, requête d’un élément par encore créé ou qui a changé de nom, mais finalement rien de trop compliqué de ce côté là. Concernant les typages, la logique de TypeScript est venue très vite, et je trouve déjà difficile de m’en passer. J’ai néanmoins réalisé trop tard qu’aucun de nos types ne tenait réellement compte du caractère obligatoire du champ dans Strapi, ce qui est dommageable car cela empêche TypeScript de me prévenir que tel ou tel composant va crasher si l’utilisateur oublie de remplir un champ. Heureusement Patrick le PO et Leticia la designeuse se sont chargés de vérifier ce qu’il se passe avec un bouton sans lien, ou une liste de logo sans logo : j’ai souvent dû ajouter des ternaires (des conditions de rendu). Un jour je prévois de refaire une passe pour typer possiblement null ce qui doit l’être, et de rendre obligatoire dans Strapi les autres éléments. Un travail d’autant plus fastidieux que Strapi refuse de rendre obligatoire un champ si quelque part il existe vide dans un composant…

Nous avons aussi créé quelques nouveaux slices mais rien de trop complexe, et deux bonnes semaines après mon arrivée, j’avais déjà beaucoup appris sur GraphQL, Strapi, Next.js et TypeScript. Nous étions au bout de la migration du site existant, au bout du tunnel donc ?

Strapi v4 a bien chamboulé la manière dont les données étaient organisées, voici un exemple ci dessous de requêtes pour exactement le même élément:

Pas tout à fait la même chose : si vous avez bien observé, le premier récupère une seule catégorie quand le second en récupère potentiellement plusieurs. Profitant de la migration, les fonctionnalité ont souvent évolué, ce qui a contribué à allonger le projet.

Le blog

Marie part dans moins d’une semaine, il reste tout à créer pour le nouveau blog. Une nouvelle page article et plusieurs nouveaux slices pour cette page, créer la page d’accueil du blog qui affiche les articles, les pagine et les filtre et une fois ce travail terminé, intégrer les articles manuellement dans le nouveau CMS. On est large ?

Et bien, pas tant que ça, je me dis même qu’on risque d’avoir une ou deux semaines de retard si ça continue (douce innocence). L’intégration n’est pas terminée quand Marie part, je continue à un petit rythme. Je découvre que quand figma donne une épaisseur de 2px, un trait d’épaisseur 3px retourne directement de la colonne “à tester” vers la colonne “à faire”. Et que si ça marche en local mais pas sur la liseuse du PO ou le Tamagochi de la designeuse, ça ne marche pas.

Des choses qui aujourd’hui me paraissent plutôt simples sont entièrement nouvelles, et me prennent donc longtemps. Comment on crée une page déclinable en plusieurs versions dans Next.js ? Et dans Strapi ? Comment on pagine dans Strapi ? C’est quoi remark ? C’est mieux quand c’est saveur github ? Il faut aussi des miettes de pain ? Heureusement, Vincent l’autre développeur front prend le relais de Marie, relit mes PR et répond à mes questions.

Malgré le retard sur le projet, je reste optimiste. Chaque lundi, j’annonce en réunion que le site est presque prêt. Les choses avancent, et le gros œuvre sort de terre fin septembre : des pages, des composants fonctionnels, l’intégration peut commencer. Il ne reste plus que quelques finitions !

Vous avez dit finitions ?

À mesure que la mise en prod approchait, j’ai été confronté à de nouvelles questions: notre site est-il accessible, éco-conçu, ses métas données se comportent-elles correctement ? Pourquoi mettre à jour un article ne re-rend pas toujours le contenu ? Leticia, qui a intégré une grande partie des contenus, et Patrick se sont mis à dénicher tout un tas d’anomalies, de bizarreries, d’approximations et nous nous sommes tous les trois lancés dans une valse de tickets. Gwenn, un développeur de l’agence, venait de terminer une formation sur l’accessibilité. Il a audité le blog et créé des dizaines de tickets, sur des sujets souvent tout à fait nouveaux pour moi, afin de rendre ce blog aussi accessible que possible. Enfin, avec Vincent qui relisait chacune de mes PR, et ne manquait pas de me faire chaque fois des retours instructifs, ainsi que des nouveaux projets sur lesquels j’ai commencé à travailler, la mise en ligne s’est retrouvée repoussée pendant encore plusieurs semaines. J’ai par exemple passé un grand nombre d’heures le nez dans la doc de Next.js pour chercher à comprendre pourquoi le re-rendu était si lent et aléatoire après une modification dans le CMS de preprod. Spoiler : c’était la faute du cache d’apollo, une petite ligne a résolu le problème.

Waow, 3j de boulot pour générer deux lignes d’options dans la configuration apollo, ça c’est de la productivité !

Ou alors pour tenter de comprendre la différence entre getServerSideprops et getStaticProps. Enfin, j’ai bataillé avec tout un tas de concepts nouveaux qui sont pourtant au cœur du travail du front : métadonnées, navigation au clavier, liens canoniques, balisage accessible, limitation des requêtes serveur… Ce travail a payé, car le site est très bien noté en accessibilité (96 sur Ouvre une nouvelle fenêtrehttps://pagespeed.web.dev) et en éco-conception (98 sur Ouvre une nouvelle fenêtrehttps://kastor.green).

En parallèle, toute l’agence a mis la main à la patte pour copier coller les articles de blog dans le nouveau CMS. Les scripts de migration, et bien, disons que ça nous a semblé plus rapide de nous en passer. Grâce à cet effort collectif, nous avons mis en prod mi-novembre, avec seulement 10 semaines de retard sur le planning, youpi !

Pour finir

Vous vous demandez si le jeu en valait la chandelle ? Vous pouvez juger par vous-même, vous lisez un article de blog sur la création d’un blog, sur le blog qui a servi à créer l’article de blog relatant la création du blog, dingue ! Pour ma part, j’ai beaucoup aimé commencer mon stage sur un projet interne, de petite envergure, basé sur des technos récentes, avec toujours quelqu’un pour apporter une réponse à mes questions. J’ai le sentiment d’avoir énormément appris. A la fin du projet, j’ai même pu quelques temps m’y sentir chez moi, afin d’arriver en pleine forme sur des nouveaux repos à la syntaxe étrange (vous dit Redux ?) et d’être de nouveau perdu.