Workflow front-end : un nouvel espoir (partie 3)

Cet article est le troisième d'une série consacrée à réflexion et la refonte de notre workflow, outils et pratiques front-end. Il présente la première nouvelle version de notre stack, toujours en cours d'amélioration.

L'An de Grâce 2018 vers à peu près 1h du matin...

C'est le souffle court et les doigts fébriles que je pianote sur mon clavier les quelques instructions suivantes :

La destination de ce commit énigmatique ? Un repo sobrement nommé frontkit-react-redux sur notre Gitlab.

Son contenu ? Un premier jet de notre nouvelle stack front. Vous avez pu suivre, non sans passion, les réflexions que nous avons pu avoir sur le statut de nos pratiques, outils et workflow.

C'est donc sans surprise que nous allons vous dévoiler nos premiers travaux sur la refonte de notre workflow et de notre stack front-end.

Automatisation des tâches

Babel

Pour transpiler notre Javascript ES6+ en ES5 lisible et compréhensible par tous les navigateurs que nous ciblons, notre choix s'est porté sur Ouvre une nouvelle fenêtreBabel.

Notre config utilise le traditionnel preset

Webpack

Afin d'avoir entièrement la main sur notre workflow, nous avons décidé d'utiliser le plus célèbre des bundlers : Ouvre une nouvelle fenêtreWebpack.

Nous avons découpé notre workflow en 3 fichiers de config :

• Création d'un serveur pour notre application, accessible depuis tout appareil utilisant le même réseau
• Hot Module Replacement, pour le JS et le CSS (parce que recharger la page, c'est nul)
• Création de sourcemaps, pour faciliter le débuggage

• Purification du Javascript (retrait du code mort, minification)
• Création des chunks (modules Javascript utilisés par plusieurs points d'entrée et leurs enfants)
• Minification du HTML
• Purification du CSS (retrait des styles non appliqués, minification)
• Injection du CSS critique dans le HTML

• Transpilage avec Babel
• Extraction des styles (CSS-Modules et CSS classique) dans un fichier
  , application des plugins PostCSS (import, Tailwind, CSSNext)
• Injection des bundles CSS et JS et des vendors de façon automatique dans un template HTML (les bundles ont un nom hashé)

Améliorations en cours et à venir

• Amélioration des performances (vitesse d'exécution, taille des bundles générés), une bataille de chaque jour
• Mise en place du code splitting, pour gagner en rapidité
• Passage à Ouvre une nouvelle fenêtreWebpack 4, qui ne se fera que quand tous les plugins que nous utilisons dans nos fichiers de configuration qui ne sont pas inclus dans cette nouvelle version 4 soit Ouvre une nouvelle fenêtrev4 friendly.

Côté application client

React

La plupart de l'équipe ayant pu se faire une petite expérience sur Ouvre une nouvelle fenêtreReact, nous nous sommes pour l'instant positionné sur la célèbre librairie de Facebook pour construire nos applications.

Les améliorations à venir

Mise en place de l'environnement Redux

Comme pour React, ce premier jet de stack pioche sur un outil sur lequel l'équipe a pu se faire la main pour nos futures applications nécessitant un state manager : Ouvre une nouvelle fenêtreRedux.

Nous pensons mettre en place l' Ouvre une nouvelle fenêtrearchitecture Ducks pour organiser la logique de nos composants.

Animations, transitions et micro-interactions

Un des souhaits communs aux pôles design, développement front et développement back, c'est la mise en place d'animations, de transitions entre les pages et de micro-interactions afin de créer des sites plus dynamiques.

CSS nous permet déjà de faire des choses formidables, mais voici quelques outils auxquels nous aimerions jeter un coup d'oeil :

• Ouvre une nouvelle fenêtremo.js
• Ouvre une nouvelle fenêtrepopmotion
• Ouvre une nouvelle fenêtrereact-css-transition

Côté Style

Il s'agit de l'une des parties de notre stack qui a le plus radicalement changé. Pour rappel, nous utilisons, sur nos projets historiques, Sass (LESS pour les projets les plus anciens) avec Boostrap (3 ou 4 selon la date de naissance de projet) sur une Ouvre une nouvelle fenêtrearchitecture 7-1, PostCSS pour certains cas et Trowel en supplément (ou Silverhold, la version dépréciée de Trowel).

Pour la nouvelle stack, nous avons choisi d'utiliser du CSS tout simple augmenté avec PostCSS (avec les modules CSSNext, qui inclut Ouvre une nouvelle fenêtre Autoprefixer pour préfixer nos styles selon les navigateurs que nous supportons, et Ouvre une nouvelle fenêtreeasy-import pour le moment).

La plupart de nos styles sont générés par Ouvre une nouvelle fenêtreTailwindCSS, qui nous permet de gérer automatiquement toutes les classes atomiques dont nous avons besoin pour créer de superbes interfaces.

Pour les styles plus complexes ou les animations, nous avons choisi d'essayer les CSS-Modules.

Documentation

Storybook

Coutumier de l'approche Atomic Design et des styleguides, la nouvelle stack a vu l'arrivée de Ouvre une nouvelle fenêtreStorybook, une solution qui permet de tester ses composants visuels dans un environnement isolé de notre application.

Grâce à une combinaison d'addons, nous pouvons, en plus d'avoir un styleguide, générer une documentation pour nos composants et tester leur accessibilité (dans une certaine mesure).

Tests

Jest + Enzyme

Une envie que nous avions depuis quelques temps, c'est la création de tests côté front-end. Pour cela, nous avons choisi le framework Ouvre une nouvelle fenêtreJest, créé par Facebook, et l'utilitaire Ouvre une nouvelle fenêtreEnzyme de Airbnb. Nous écrivons donc des tests unitaires pour chacun de nos composants visuels ( Ouvre une nouvelle fenêtreretrouvez ici une explication (en anglais) sur les différences entre tests unitaires, tests fonctionnels et tests d'intégration).

Ensemble, ces outils se révèlent diablement efficaces et permettent de tester la structure des composants en comparant un snapshot (une photo) de la structure initiale d'un composant avec un nouveau snapshot qui lui est présenté.

En plus de la structure, ces outils permettent également de tester l'interactivité d'un composant (quand je clique/sélectionne/survole/change quelque chose, est ce qu'il se passe bien quelque chose ?).

Améliorations en cours et à venir

Nous souhaitons mettre en place des tests de régression visuelle. Quelques solutions existent pour mener à bien cette tâche. Nous avons décidé de tenter le coup avec un outil nommé Ouvre une nouvelle fenêtreLoki. A voir ce que cela va donner !

Linter et formatter

Nous avons choisi Ouvre une nouvelle fenêtrePrettier pour formater notre code et Ouvre une nouvelle fenêtreESLint ainsi que Ouvre une nouvelle fenêtreStylelint pour linter le Javascript et le CSS/PostCSS (respectivement).

ESLint est configuré pour suivre les standards d'écriture de React et nous alerter en cas de non respect des normes d'accessibilité dans le markup de nos composants.

Stylelint, quant à lui, nous avertit si nous utilisons des unités autres que les

Git Hooks avec Husky et lint-staged

Les Git Hooks sont des scripts et instructions qui sont exécutés avant qu'un

Pour ces tâches, nous avons choisi Ouvre une nouvelle fenêtreHusky, en combinaison avec Ouvre une nouvelle fenêtrelint-staged.

Avant chaque commit, nous lançons sur les fichiers dont les modifications ont été enregistrées dans le dépôt git (en gros où on a fait

Cette approche permet d'éviter de réévaluer l'ensemble de la code base : si 5 fichiers / 250 ont été modifiés, pourquoi réévaluer les 245 autres sachant que seul du code propre peut être

Architecture

Voici l'architecture à laquelle nous arrivons avec cette stack :

Avant

Après

Contrairement à notre ancienne architecture, ici le front est totalement séparé du back. Nous suivons le principe suivant : chaque composant doit pouvoir fonctionner et être testé de façon indépendante, d'où l'architecture de composant suivante :

• : la définition du composant
• : les stories du composant, c'est-à-dire la liste de ses différents états visuels (les .stories sont ce qu'utilisent storybook)
• : définition des tests du composant

Retour d'expérience sur ces premiers travaux

Refondre sa stack front ne se fait pas du jour au lendemain et dans son coin ! Principale actrice du passage de la stack front historique à cet embryon, j'ai voulu rapprocher les différents pôles de l'agence :

• design
• back
• SEO/stratégie média

Le développement front-end est en effet le pont qui va relier ces différents points entre eux : le code se doit de donner vie aux maquettes en étant plus qu'un simple miroir statique par des micro-interactions et des animations. Il doit également leur implémenter un système nerveux en reliant l'interface à la logique back-end. Mais à quoi sert de faire un site si personne ne le voit ? Le SEO a également toute sa place si l'on cherche à réécrire sa stack et son workflow.

C'est dans ce but que la discussion de cette refonte s'est effectuée sur notre Discourse et lors de discussions informelles, afin que chacun puisse expliquer ses problèmes, frustrations et attentes sur la stack front : l'occasion pour chacun donc, d'apporter sa pierre à l'édifice, même pour les non-développeurs.

Pour ma part, cela m'a permis de tester des technologies et des combinaisons que je n'avais jamais encore pu croiser dans le vaste monde front-end (les CSS Modules avec un framework CSS atomique, certaines combinaisons d'addons dans Storybook), d'en découvrir certaines (Jest, Enzyme et Loki) et, plus important, d'en approfondir d'autres, surtout la configuration de Webpack pour un environnement de production.

Car c'est surtout là que repose la difficulté de l'exercice : savoir comment configurer et lier les outils que l'on utilise entre eux. C'est peut-être là le point noir principal de cette expérience : il faut un certain** background technique** pour tout mettre en place, et assez de pédagogie pour documenter et expliquer le rôle de chaque chose et comment interagir avec, à l'oral comme à l'écrit.

Mais il reste encore beaucoup à faire, beaucoup à découvrir. Cette stack n'est pas vouée à être figée. Des jumelles alternatives verront certainement le jour (avec Ouvre une nouvelle fenêtreInferno, Ouvre une nouvelle fenêtreCerebral ou d'autres technos que l'on jugera bon d'intégrer à notre workflow). L'architecture et les technos bougeront sans doute au fur et à mesure que nous testerons cette stack.

Discutez, renseignez-vous, et surtout documentez et expliquez vos résultats. Car rien ne sert d'avoir un vaisseau capable de transporter tout un monde si vous seul savez comment le conduire.