SFEIR Lille : deux jours à la Dot JS

Auteurs :
Célia Doolaeghe
Julien Hery

Les 5 et 6 décembre 2019 à Paris, nous sommes plusieurs Sfeiriens à avoir eu la chance de participer à dotJS, deux journées de conférences techniques autour de JavaScript.

Le premier jour de cette conférence dotJS 2019, un des talks qui a attiré mon attention fut celui de Adrià Fontcuberta (@afontq), à propos de Testing Library dont il est l’un des contributeurs.

Ça tombait bien, car peu de temps auparavant, mon équipe se posait la question de la pertinence de changer nos pratiques de test ou nos outils, et nous étions tombés sur ce projet. Testing Library a pour slogan “The more your tests resemble the way your software is used, the more confidence they can give you.” et c’est cela qui avait retenu mon attention au cours de mes recherches.

Lors des développements au sein de mon projet, nous nous étions rendu compte que nous avions souvent des faux positifs et des faux négatifs. Les tests échouaient alors que l’application fonctionnait correctement. Un des points mis en évidence par Adrià fut l’introduction d’un nouvel utilisateur dans l’application.

Explication : une application devrait avoir deux utilisateurs, le développeur et l’utilisateur final. Mais dans certains cas, avec de mauvaises pratiques, il est possible d’introduire un troisième utilisateur : les tests !

Les librairies de test actuelles encouragent involontairement des pratiques pouvant mener à ce genre de problèmes. Par exemple, accéder à une méthode d’un composant via l’instance du composant. La plupart du temps, c’est un détail d’implémentation auquel l’utilisateur final n’a pas accès. Si jamais la méthode est renommée, les tests vont échouer, mais le composant fonctionnera toujours. C’est un faux négatif. Testing Library essaie d’encourager de bonnes pratiques en ne mettant à disposition que des méthodes se rapprochant du comportement qu’un utilisateur final pourrait avoir. La librairie fournit un ensemble des sélecteurs afin de récupérer les éléments HTML qui vous intéressent et déclencher des évènements dessus. On notera également la présence d’un sélecteur permettant d’obtenir un input associé à un label, très pratique pour l’accessibilité, largement mise en avant lors de la dotJS.

À noter que la documentation officielle de React recommande l’utilisation de Testing Library et que le projet est maintenant inclus dans create-react-app.

Après cette première journée sur le front, la deuxième s’axait plutôt sur les notions core du langage JavaScript et les technologies JS du backend.

Pour présenter les évolutions du langage, deux membres du TC39, le groupe chargé de définir le contenu des versions d’ECMAScript, étaient présents. Ils se réunissent en comité pour étudier les différentes propositions d’évolution du langage.

Dans son talk “TC39: How we work, what we’re working on, and how you can get involved”, Daniel Ehrenberg a présenté le fonctionnement du groupe TC39, finalement assez peu connu des développeurs JS, malgré son influence sur ce dernier.

Pour qu’une idée ou un besoin devienne une fonctionnalité, elle doit passer par 4 étapes :

1. décrire l’idée, étudier la solution en comité
2. rédaction formelle de la spécification, disponible sur GitHub
3. solution en développement
4. solution prête à devenir un standard ECMA, peut être implémentée par les autres services (navigateurs, NodeJS, etc.)

Daniel Ehrenberg a ensuite présenté les différentes propositions qui sont en cours de préparation, comme le nullish coalescing qui facilitera l’initialisation des variables, ou encore l’optional chaining pour lire en sécurité dans un objet qui peut être undefined. J’attends personnellement ces deux évolutions avec impatience !

L’intérêt est de montrer que JavaScript est un langage qui évolue encore énormément. Il est important de savoir que la communauté des développeurs peut s’impliquer, tester ces nouvelles fonctionnalités (tout en sachant qu’elles sont instables avant l’étape 4), car des retours rapides sont toujours très appréciés !

Une des propositions du TC39 a fait l’objet d’un talk à part entière : “Programming in the 4th Dimension — Making Time Make Sense”, par Maggie Johnson-Pint.

Il s’agit de la proposition Temporal, qui permettrait d’avoir enfin une gestion des dates dans JavaScript ! Car aujourd’hui, le pire moyen de gérer une date en JS est d’utiliser Date. L’idée est de remettre à plat ces concepts.

Nous aurons donc un jour des dates absolues et des dates locales, et la possibilité de passer facilement de l’une à l’autre. La notion de durée sera également incluse.

Mais surtout, nous pourrons enfin créer des dates sans heure ! Actuellement, l’heure est souvent mise à minuit par défaut, or avec la gestion des fuseaux horaires, on peut se retrouver à convertir une date de naissance locale en absolue et changer de jour sans le vouloir… Ou comment créer un joli petit bug ! Dans le futur, nous pourrons avoir des dates avec une heure à undefined et éviter ainsi toute ambiguïté.

De la même manière, nous pourrons avoir des heures sans date associée, par exemple pour exprimer l’heure d’un rendez-vous régulier. Et bien évidemment, nous pourrons combiner une date sans heure et une heure sans date pour obtenir une date avec heure. La manipulation des dates en sera grandement simplifiée !

Cette fonctionnalité est encore en cours de développement et en test, car le temps est une donnée complexe. C’est là que la communauté peut clairement se rendre utile : ils sont à la recherche d’un public qui utilise d’autres calendriers, ou encore d’applications particulières concernant les dates. Tout le monde peut voir l’avancée de leur travail et même commencer à les utiliser (mais là encore, il faut garder à l’esprit que la solution est instable et peut être modifiée).

En tout cas, c’est une évolution qui sera très utile pour des projets qui ont simplement besoin de gérer des dates sans vouloir pour autant importer toute une librairie pour ça.

Le TC39 a beaucoup d’autres projets en cours, toutes les informations sont disponibles dans leur GitHub.

Ces deux journées ont été riches en conférences, et il y a encore plein d’autres sujets à surveiller, comme Deno ou WebAssembly. Nous vous encourageons à aller regarder les vidéos de dotJS qui sont disponibles sur YouTube.