Quelques mois après mon arrivée, nous avons entamé le gros projet pour lequel j'avais été embauché : La refonte de l'application web Overblog, qui permet aux utilisateurs d'administrer leurs blogs.
L'application en place codée dans un framework JavaScript maison basé sur YUI était devenue de par son obsolescence difficilement maintenable et il était capital de moderniser le code-source afin de faciliter l’ajout de nouvelles fonctionnalités.
Nous avons très vite décidé d’utiliser ReactJs pour son approche centrée Composants, nous permettant de bien organiser notre code, et son JSX nous permettant d’utiliser du HTML dans le Javascript.
Nous avons utilisé la librairie Apollo, qui suit la spécification GraphQL, pour requêter les données de façon simple et flexible. Contrairement à une API Rest, le langage de requête GraphQL nous permettait, développeur front-end, d’être beaucoup plus flexibles et autonomes une fois le serveur GraphQL développé.
Nous avons utilisé la librairie styled-components et avons ainsi pu profiter de la puissance du CSS-in-JS tout en continuant d’utiliser la syntaxe CSS dans le Javascript grâce aux "templates string".
Pour minimiser le markup et respecter une uniformité dans toutes l’application nous avons utilisé styled-system pour ses propriétés responsives qui respectent des échelles.
Les formulaires sont au coeur de notre application et nous avons choisi d'utiliser React Final Form pour les gérer.
Nous avons de nombreux formulaires, parfois complexes et dynamiques, notamment sur la page de rédaction d'articles, et ce fut un véritable challenge pour optimiser l'expérience utilisateur.
De nos jours, une application web moderne se doit de s'adapter à toutes les tailles d'écran, en paysage ou en portrait. Pourtant notre ancien design n’était conçu que pour les écrans d’ordinateurs.
Il a fallu repenser entièrement l’interface ainsi que l'expérience utilisateur de notre application pour rendre cette dernière la plus ergonomique possible, quel que soit le support avec lequel on y accède.
Nos utilisateurs pouvaient passer de longues heures à rédiger leurs articles et, de par mon rôle au sein de l'équipe, je donnais de ma personne pour leur offrir le plus grand confort visuel qu'il soit.
Moi-même étant un partisan des modes sombres sur les applications que j'utilisais au quotidien, j'avais à coeur de proposer cette fonctionnalité, qui n'était alors pas prévue dans notre roadmap, à nos utilisateurs.
C'est avec beaucoup de joie, alors que la proposition avait été acceptée par l'équipe et intercalée pour l'occasion dans notre planning, que nous avons élaboré un thème sombre du plus bel effet.
Notre application web étant complètement responsive, l'étape suivante a été de la faire évoluer vers une Progressive Web App.
Le but de cette manœuvre était de permettre à nos utilisateurs de bénéficier depuis leur smartphone de toutes les dernières fonctionnalités développées au quotidien pour notre nouvelle application web. Par la même occasion nous avons pu remplacer les applications natives existantes, instables dépourvues et non maintenues par manque de budget et d'effectifs compétents.
À long terme, cette PWA permettra à nos utilisateurs de recevoir s'ils le souhaitent leurs notifications directement sur leur téléphone sans même ouvrir leur application.
Une fois la Progressive Web App finalisée, nous avons déployé de nouvelles applications natives sur le PlayStore et l’AppleStore afin que nos clients puissent trouver facilement notre application. Ces applications natives sont développés à l’aide d’Expo et composées d’une WebView englobant notre application web.
Pour être plus confiants lors de la publication d’une nouvelle version et ainsi minimiser les régressions involontaires, nous avons ajouté des tests de bout en bout.
Ces tests permettent de valider le bon fonctionnement global de l’application mais aussi des interactions avec les éléments sensibles de l’interface ainsi que de la bonne intégration avec les micro services. On peut ainsi coder des scénarios de tests afin de simuler des clics sur les éléments de l’interface et vérifier les comportements attendus.
Pour coder ces tests nous avons utilisé Jest, une librairie de tests maintenue par l’équipe de Facebook, ainsi que Puppeteer qui permet d’émuler le comportement d’un Google Chrome sans interface.
Voici quelques un des scénarios critiques que nous avons ainsi testé de bout en bout :
Une fois les différents scénarios mis en place, ces tests ont été automatisés afin d’être joués avant toute publication d’une nouvelle version. En cas d’erreur, la nouvelle version n’était pas déployée et nous étions alertés en cas d’erreur.