Outils
======
Ce commit retire le tooling de Flow, et ajoute le support de TypeScript
pour les fichiers .ts et .tsx. Il n'est pas nécessaire de tout migrer
d'un coup ce qui facilite la transition. On garde en effet le
compilateur Babel avec un preset TypeScript (ce qui permet donc de
retirer à la fois les types Flow et TypeScript) plutôt que d'utiliser le
compilateur standard pour la conversion du code. Cela permet aussi de
mieux s'intégrer avec d'autres outils, notamment les test-runners.
Ajout d'une nouvelle commande `yarn run type-check`, intégrée dans
CircleCI.
Par ailleurs ajout du support de l'opérateur ?? pour donner des valeurs
par défaut (nullish-coalescing-operator).
Typage des libraires tierces
============================
Les principales libraires que nous utilisons ont un typage TypeScript de
bon niveau, ce qui facilite l'intégration. J'ai mis à jour react-i18next
et i18next afin de corriger un problème de typage.
Typage du code
==============
Le typage est loin d'être complet dans ce commit, en particulier il
manque les types relatifs au state Redux, ainsi qu'au moteur (règle,
explication). Néanmoins le typage des contextes fonctionne, en
particulier sitePaths (avec un type récursif non trivial !) qui a déjà
permis de détecter un lien mort.
Le typage des "paths" (Components/, Règles/, etc.) fonctionne bien, y
compris avec l'auto-complétion automatique des import par Typescript.
TypeScript se révèle déjà bien agréable dans VSCode (auto-complétion,
refacto, etc.) ! Reste à migrer progressivement le reste du code !
Vu qu'on utilise un serviceworker, lorsque la requête ne passe pas jusqu'au serveur, la redirection n'est pas effective
On parse les règles de redirection netlify coté front et on les ajoute à l'app
Développé dans le repo mon-entreprise.fr mais publié sur
https://publi.codes
1ère version : afficher un extrait de code des deux applications
d'exemple
Faire un lien vers le wiki, nettoyé.
2ème version : rendre éditable ce code, avec un widget à côté qui est
mis à jour automatiquement quand on change un taux, une formule. C'est
le côté "publi" et moderne de la plateforme.
plutôt que de le charger dans le bundle principale.
- Permet d'avoir une estimation du temps de chargement
- Peut-être que le problème du nombre d'entrance plus faible que le nombre de visite sera ainsi reglé
On compile maintenant pour les navigateurs récents (qui supportent les modules es6.
On ajoute une config de build pour les browser legacy (ie11).
Cela permet :
- De ne plus être dépendant de polyfill.io (qui nous a claqué dans les doigts et a peté la prod)
- D'avoir un JS transpilé plus léger et plus proche du code écrit pour les navigateurs récents
- De pouvoir ajuster le build en fonction du navigateur (on ajoute pas le serviceWorker dans IE par exemple. A l'inverse, on
pourrait multiplier le nombre de bundle pour tirer profit de HTTP2)
Dans le futur, on voudra surement créer une version pour les nav moderne et une version IE,
On pourra alors se débarasser de polyfill.io et uniquement utiliser polyfill.io de babel
Intérêt : explorer la base de règle facilement, par namespace.
Ne pas merger sans faire en sorte que ça soit complètement chargé
dynamiquement, car l'éditeur doit faire plusieurs mega.
- Ajoute des links hreflang pour lier les pages entre elles avec google
- Prends en compte le lien passer en français / anglais
TODO : mettre les noms de domaines dans des variables d'env
Acceleration drastique des perfomances, la page est chargée immédiatement.
Limitations:
- La page embauche.beta.gouv.fr est prérendue en français. Le contenue saute si le navigateur est en anglais
- Les tests end to end ne sont pas encore branchés avec les pages prérendues. Voir https://github.com/zeit/serve-handler/issues/71
Maël
Maxime Quandalle
Johan Girod
Johan Girod