Journal Elm 0.17

Sommaire

• • Souscriptions
  • Misc
  • Conclusion

Mon cher journal,

Je ne sais pas si je t'ai déjà parlé de Elm, ce langage fonctionnel de développement web dont la syntaxe s'inspire largement de Haskell (mais dépouillé d'une grande partie de sa richesse complexité) tout en introduisant une notion "reactive" via le concept de signaux qui permettent de réagir en fonction de valeurs changeantes dans le temps (comme la position de la souris, la taille de la fenêtre, des messages websocket, etc).

Il se trouve qu'on attendait assez fébrilement la sortie de la version 0.17 depuis tout de même le mois de novembre 2015 alors que son créateur Evan Czaplicki nous avait plutôt habitué à un rythme de sortie de version assez court (bon, certes, pour la 0.16, il avait fallu attendre quelques longs mois aussi, mais ici, ça bat tous les records).

Et bien on est gâté.

Il y a deux jours, la sortie de la version 0.17 a en effet été annoncée via un nouveau post de son créateur sur le site officiel du projet, et ce dernier ne nous annonce rien de moins que l'abandon du R dans FRP (Function Reactive Programming) et jette les signaux aux oubliettes. Carrément.

Souscriptions

Il s'agit ici du changement majeur de cette version 0.17.

Evan a souhaité rendre l'apprentissage du langage encore plus simple qu'auparavant. Visiblement, la gestion de signaux troublait pas mal de nouveaux venus et il a donc décidé de les enrober dans un concept plus haut niveau.

Pour la faire courte, réagir à des valeurs changeantes dans le temps passe maintenant par un système de souscriptions d'événements, via la déclaration d'une fonction générale subscriptions qui, en fonction du modèle de donnée (qui représente l'état de l'application, dans la même philosophie que le state dans Redux pour ceux qui font du ReactJs) reçu en paramètre est censée renvoyer un ou plusieurs objets de souscription à des événements.

Pour prendre un exemple, si je veux gérer du drag'n'drop et si mon modèle de donnée contient un booléen "bouton gauche de la souris appuyé", la fonction subscriptions pourra renvoyer une souscription aux événement de type "déplacement de souris" si elle détecte que le booléen susnommé est à true.

Alors qu'avec les signaux, on avait pas d'autres choix de les écouter ad vitam aetnernam une fois qu'ils étaient déclarés, ce nouveau système de souscription permet de dynamiquement être aware d'événements suivant l'état de l'application (via le modèle de donnée).
D'une certaine manière, et parce qu'elle prend le modèle en paramètre, cette nouvelle fonction fait un peu penser à la fonction update qui, lorsqu'elle reçoit un message particulier, transforme l'état de l'application dans un nouvel état (de façon immutable), sauf qu'ici, ce n'est pas un état qu'on change, mais un nouvel ensemble de souscriptions d'événements qu'on renvoie.

En contrepartie, ce nouveau système couple encore plus les applications Elm avec la fameuse architecture applicative Elm puisque le modèle et la fonction update sont encore plus sollicités qu'avant pour réagir aux événements. Par exemple, Signal.foldp qui permettait d'accumuler toutes les valeurs changeantes d'un signal n'existe plus et il est recommandé de gérer toute l'accumulation via la fonction update.

Misc

On note également quelques changements mineurs :

• On ne parle plus d'Action pour les messages qui permettent de changer le modèle (ou bien d'émettre des effets de bords) mais de Message ce qui est à mon sens beaucoup plus logique. En effet, parler d'Action pour des événements passifs pouvait parfois prêter à confusion.
• La syntaxe d'exposition des fonctions d'un module change légèrement
• Plus de signaux, donc plus de Signal.address, plus de Signal.mailbox, tout ce qui permettait de lier des événements à des composants du DOM virtuel change assez radicalement, du coup, l'objet Html (renvoyé par les fonctions div, span, etc etc) est devenu paramétrique et prend un Message en paramètre, ce qui simplifie grandement les choses.
• Effect devient Cmd ce qui est surtout un changement cosmétique (comme pour Action -> Msg) et toute cette logique migre dans le core du langage, ce qui fait sens également dans l'optique d'intégrer encore plus l'Architecture Elm au langage.
• Deux trois autres petits changements cosmétiques, des modules qui changent de noms (avec la volonté d'offrir un dépot elm-lang officiel qui contiendra des modules "mainstream" => evancz/elm-html devient elm-lang/html, etc), des modules qui sortent du core pour migrer dans des modules externes (Mouse, Keyboard, etc).

Les détails ici.

Pour finir, plus que jamais, le mainteneur du projet et les gens qui travaillent avec lui insistent pour garder l'apprentissage du langage accessible, et pour ça, ils n'utilisent jamais de termes comme "monade" ou "functor", mais mettent plutôt l'accent sur les possibilités offertes par Elm : pas d'erreurs au runtime, un compilateur qui aide vraiment et qui n'est pas là pour décorer, une incitation aux bonnes pratiques qui fait quasiment partie de l'ADN du langage, etc.

Conclusion

Bon ok, Evan a encore cassé l'API et pas mal de gens râlent car certains sont pressés et tentent déjà d'utiliser Elm en production (ce que je conseille pas, ou alors vraiment en connaissance de cause ou bien si vous êtes NoRedInk :-) )
Mais bon, journal, malgré ça, je trouve ça très chouette que des gens cherchent constamment à rendre leur joujou de plus en plus accessible et je dois avouer qu'après une journée à pondre du JavaScript pour le boulot, je suis content de retrouver mes petites expériences Elm le soir, je trouve ça très ludique et rafraîchissant !

Bisous