- Avant 2010
- grosso modo vanilla ou jQuery
- on faisait tout à base de addEventListener
- donc on ne se basait que sur les events standard JS
- on écoutait des events mais pas plus que ça
- on mixait le "comment mettre à jour" avec les données et la vue
- le fait de réagir ?
- un peu trop basic comme définition
l'idée c'est de définir des données, les mapper et avoir un mécanisme qui réagit tout seul pour faire en sorte de synchroniser le tout
- le père de tous les frameworks modernes
- fonctionnement à base de composant
- two-ways data-binding
- on map une variable de notre composant dans la vue
- à chaque changement de la variable on change la vue
- si la vue bouge, on change les variables en conséquence aussi
- on part exemple un input dont la value était mappé à une variable, on avait un binding dans les deux sens
- tout fonctionnait à base d'un système de watcher
- ça marche tant que y'a pas grand chose à watch
- c'est pas perf
- plus y'a de watch plus c'est lourd et lent
- on est limité au tick du watcher
- avant Angular 2 on cherche à faire mieux
- fini le watch, on introduit Zone.js
- à chaque fois qu'il se passe un truc, Zone prévient Angular qu'il doit lancer une détection de changement
- là Angular fait le tour de tous les composants pour voir ce qui a pu changer (ce qu'on appelle la phase de "change detection")
- déclenche une mise à jour des composants qui ont bougés
# CODE SLIDE : avec l'édition d'une variable
# CODE SLIDE : avec l'édition d'un champ de texte
# CODE SLIDE : avec du two-way data binding
# CODE SLIDE : avec la résolution d'une promesse en mappant le retour
# CODE SLIDE : avec la résolution d'une promesse en async pipe
- c'est simple à écrire (bien que parfois un peu verbeux)
- c'est réactif
- on y est habitué
MAIS
- quand même pas mal d'annotation, de type à mettre, et...
- Zone vient monkey patch pleins d'API standard pour introduire une mécanique de notification d'appel (pour les setTimeout, les setter, les Promises, etc.)
- Zone ça fonctionne
- c'est mieux que les watcher
- mais on monkey patch beaucoup de choses
- c'est lourd
- y'a un système de contexte un peu bizarre
- c'est un peu trop magique pour être facile à comprendre
- Angular + Zone c'est forcément du component level pour la réactivité
- experimental à partir de la v16
- stable en v17
- nouvelle mécanique pour la réactivité
- on ne se repose plus sur Zone pour la réactivité
- on ne fait plus de réactivité à l'échelle du composant mais d'une variable
- ce qu'on appelle la "fine grained reactivity"
- le concept n'est pas nouveau, Solidjs l'a introduit en 2019
# CODE SLIDE : reprendre la demo edition de variable mais en Signal
# CODE SLIDE : reprendre la demo edition de champ de texte mais en Signal
# CODE SLIDE : reprendre la demo promesse mais en Signal
# CODE SLIDE : montrer computed
# CODE SLIDE : montrer effect
# CODE SLIDE : demo Signal input()
# CODE SLIDE : demo Signal output()
# CODE SLIDE : demo Signal viewchild() / viewChildren()
- moins d'anotation
- moins de complexité dans les composants
- rien de compliqué
- beaucoup plus léger
- plus de magie sur la gestion de l'asynchrone
- en passe d'être standardisé dans ECMAScript (stage 1)
- l'implémentation est simple
- Annecdote : le polyfill actuel est basé sur l'implémentation des Signals d'Angular
- plus besoin de Zone
- en tout cas bientôt
- et on commence à pouvoir remplacer beaucoup de chose par des signals
- Pas besoin de RxJS pour les composants
- RxJS n'est utilisé (en tout cas pas visible) dans la réactivité en Angular
- viens initialement de chez Netflix et plutôt côté backend
- avec les Signals on parlait de reactivité et d'état
- avec RxJS on parle stream et event
- le but de RxJS c'est de nous donner une API haut niveau pour gérer des données sur un flux, les combiner, transformer, filtrer, faire du rejeux, etc.
- aucune notion d'UI
- RxJS peut très bien s'utiliser côté backend !
- typiquement NestJS est en grande partie basé sur RxJS
- un Observable est stateless
- un Observable est lazy
- un Observable est purement fonctionnel et "immutable"
# CODE SLIDE : demo Signal + Observable toSignal() toObservable()
- on a des ponts faciles au besoin entre RxJS et les Signals quand même
- API beaucoup plus simple mais aussi beaucoup plus limité
- stateful donc attention à l'impact mémoire en fonction de ce qu'on fait
- pas forcément simple de garder un arbre de dépendance entre signal simple
- Entièrement basé sur RxJS
- Il faudrait casser l'interface du HttpClient pour changer ça
- Il faudrait tout ré-écrire pour passer sur des Signals
- Pas de raison de le faire
- C'est déjà facile de passer d'un Observable à un Signals
- Et aussi les interceptors se basent sur le fait que c'est du RxJS
- Donc HttpClient et interceptor => on reste sur RxJS
- Faire du full Signals pour être plus simple
- Plus d'async, plus de fuite mémoire (ou presque)
- ne plus utiliser RxJS à moins de ne pas avoir le choix (est-ce que ce n'est pas une erreur de design si on est obligé ?)
- basé sur RxJS
- l'API expose des Observables
- logique comme c'est des events
- à priori ça ne changera pas
- Ça dépend mais je pencherais plutôt sur RxJS par défaut ou valeur simple
- Si on sait que la valeur va beaucoup changer RxJS
- Si la valeur bouge peu : valeur simple
- Basé sur RxJS
- API pensé pour être simple avec RxJS
- Exploite à fond les opérateurs RxJS
- Optimisé pour RxJS
- Fournir des utilitaires qui permettent directement de faire le pont entre NgXs et nos composants sous forme de Signal
- Signal Store
- Un store basé sur les Signals
- Fourni des ponts pour utiliser du RxJS quand c'est plus pratique
- encore en preview !
- créé par Brandon Roberts