Au lieu de participer au populaire Advent of Code, cette année j'ai décidé de relever le défi de l'Advent of TypeScript. Dans cet article, vous trouverez mes solutions ainsi que quelques détails sur leur fonctionnement ou ce que j'ai appris en résolvant les défis.
Avec l'omniprésence de Babel et Typescript dans l'univers Frontend, la compatibilité Javascript de nos applications n'est (presque) plus un sujet. Pour le HTML, seulement quelques attributs sont ajoutés depuis le HTML5 pour des fonctionnalités bonus (lazyload, prefetch, etc.). Ils sont en général ignorés par les navigateurs incompatibles. Et pour le CSS ? Pas de polyfills à proprement parler, un support très hétérogène et la moindre esquive d'un display:grid est désastreux pour le visuel. Alors comment fait-on pour rationaliser notre CSS ? Voyons ça ensemble.
En Typescript, il est possible de définir des types de plusieurs manières : interface, classe, enum, mot-clé type, as const, etc. Dans cet article, nous allons nous concentrer sur les types construits à partir d'une union disjointe et les avantages d'une telle pratique. L'union en Typescript se fait via le symbole | (ex : type Union = A | B | C). Le terme disjoint n'est pas anodin car contrairement au polymorphisme, les types que l'on va utiliser peuvent ne rien avoir en commun.
Non malheureusement ce n'est pas (encore) possible en Javascript, ni en Typescript. Mais on peut essayer de s'en rapprocher, notamment en séparant l'identification d'un scénario de son exécution. L'objectif est de renforcer la lisibilité et rapprocher le code du problème à résoudre. Pour illustrer le propos, nous utiliserons le traitement d'un article de blog (ajout, suppression, publication, etc.) à partir des informations contenues dans cet article. De plus, je vous propose d'y aller étape par étape afin que vous puissiez appliquer ce refactoring dans votre code.