Discussion :

[Community Management]

Chers membres du club,

Je vous pr�sente ce tutoriel de SylvainPV sur comprendre le data binding dans Angular, React et Vue.

Les frameworks MVVM sont aujourd'hui une partie centrale du d�veloppement front-end d'applications web. Ils occupent souvent l'actualit� JavaScript et sont source de grands d�bats parmi les professionnels.

Derri�re cette appellation, on retrouve un principe de base reliant le Mod�le (M) � la Vue (V) : le data binding. Pourtant ce m�canisme est souvent mal connu ou mal compris par les utilisateurs de ces frameworks, perdus dans le jargon technique et marketing.

Nous allons t�cher de d�crire comment ce m�canisme de data binding est impl�ment� au sein de trois frameworks populaires : Angular, React et Vue.

Bonne lecture



Les meilleurs cours et tutoriels pour apprendre la programmation JavaScript
Les meilleurs cours et tutoriels pour apprendre la programmation Web

[Paleo]

Merci SylvainPV pour cet excellent aper�u des diff�rentes solutions en data-binding.

Je trouve aussi que Vue.js est une solution l�g�re et �l�gante en mati�re de data-binding. La question qui, en ce qui me concerne, n'est pas tranch�e, est la suivante : le data-binding vaut-il r�ellement la peine, par rapport � une manipulation plus traditionnelle des �l�ments du DOM via Sizzle/jQuery ou m�me les API standards ?

[SylvainPV]

Tout d�pend si tu optes pour un rendu des vues c�t� client ou c�t� serveur. Si l'essentiel de ton rendu est fait c�t� serveur, et que les interactions c�t� client ne sont pas trop complexes, une manipulation directe et manuelle du DOM est sans doute plus simple. En revanche, si le rendu est fait c�t� client, on a tout int�r�t � se reposer sur une solution de data-binding afin que toutes les vues soient conditionn�s par le mod�le. Cela permet de limiter les �tats applicatifs et de simplifier �norm�ment la gestion. Tu es d�j� s�rement tomb� dans le cas o� tu as un plugin UI jQuery qui doit modifier le DOM pour s' "initialiser", et sur lequel tu dois toujours te poser la question de s'il est initialis� ou pas, ou "en cours d'initialisation". Ces "�tats" de vues n'existent plus quand tu pars sur une solution comme React ou vuex.

Si tu te rappelles de mon article sur le templating client, tu sais que je penche nettement en faveur du rendu c�t� client, pour la compensation de latence, la r�duction de la bande-passante utilis�e et l'ouverture � l'usage offline

[Paleo]

Je parle aussi d'application JavaScript embarqu�e dans le navigateur. Le data-binding n'est pas un lien entre le mod�le et la vue au sens MVC du terme. Il s'agit plut�t d'un moyen d'agir sur la vue au travers d'une repr�sentation. Je veux dire que les mod�les des vues ne sont pas le mod�le de l'application, et la synchronisation entre les (mod�les de) vues et le mod�le de l'application est en dehors de la probl�matique du data-binding.

On peut programmer de mani�re modulaire, par "composants", c-�-d en regroupant le code CSS, les templates HTML et le code JS par petites entit�s fonctionnelles, tout en manipulant directement des �l�ments du DOM.

[SylvainPV]

Oui, on se rapproche alors davantage d'un pattern MVC que MVVM.

[Paleo]

Pour info : https://engineering.footballradar.co...-tabular-data/

[Paleo]

L'approche de Monkberry semble saine : pas de data binding, pas de DOM virtuel, aucune magie.

Un langage de template :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
<div>
  Hello {{ name }}!
</div>

� compil� en code JavaScript utilisant les objets DOM standards :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
var div1 = document.createElement('div');
div1.textContent = 'Hello ' + name + '!';

[SylvainPV]

Int�ressant. C'est bien du data-binding, � partir du moment o� il y a des mises � jour partielles du DOM et une r�solution des liaisons dans un mod�le de donn�es. Pour la magie c'est plus subjectif comme d�finition J'ai jou� avec une petite heure, voil� mon analyse :

Pour la d�tection de changements, c'est du classique: une API de changement d'�tat � la React/Backbone. Le templating est DOM-based (on ne peut pas mettre d'expressions pour d�finir un tag par exemple), mais il y a les moustaches comme sucre syntaxique pour l'interpolation de texte et attributs.

Concernant la mise � jour du DOM, c'est plus particulier : la compilation du template consiste en fait � le faire passer par un parser HTML qui va �crire le code JS correspondant pour g�n�rer ce HTML � partir des API du DOM, avec le bon vieux document.createElement. Ces �l�ments sont cr��s un par un et assign�s � des r�f�rences en m�moire. Lorsque des liaisons de donn�es sont d�tect�es pour un �l�ment, chaque donn�e aura un setter associ� qui fera les modifications sur l'�l�ment en question. C'est un peu comme si vous �criviez vos mises � jour du DOM � la main, sauf que l� c'est un compilateur qui s'en charge.

Un exemple vaut mieux qu'un long discours. Le template:

Code html :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
<div>
   <p>
      Hello {{ name }}!
   </p>
   <p>Monkberry is <i>almost</i> an anagram of Monkey beer</p>
</div>

est compil� en :

Code js :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
/**
 * @class
 */
function hello() {
  Monkberry.call(this);
 
  // Create elements
  var div0 = document.createElement('div');
  var p1 = document.createElement('p');
  var text2 = document.createTextNode('');
  var p3 = document.createElement('p');
  var i4 = document.createElement('i');
 
  // Construct dom
  p1.appendChild(document.createTextNode(" Hello "));
  p1.appendChild(text2);
  p1.appendChild(document.createTextNode("! "));
  i4.appendChild(document.createTextNode("almost"));
  p3.appendChild(document.createTextNode("Monkberry is "));
  p3.appendChild(i4);
  p3.appendChild(document.createTextNode(" an anagram of Monkey beer"));
  div0.appendChild(p1);
  div0.appendChild(p3);
 
  // Update functions
  this.__update__ = {
    name: function (name) {
      text2.textContent = name;
    }
  };
 
  // Set root nodes
  this.nodes = [div0];
}
hello.prototype = Object.create(Monkberry.prototype);
hello.prototype.constructor = hello;
hello.pool = [];
hello.prototype.update = function (__data__) {
  if (__data__.name !== undefined) {
    this.__update__.name(__data__.name);
  }
};
 
window.hello = hello;
//# sourceMappingURL=view.js.map

Les avantages et les inconv�nients apparaissent alors clairement:

Avantages:

• les mises � jour du DOM sont effectivement les plus minimales possibles, puisque chaque donn�e a son setter d�di�
• le template une fois compil� reste lisible et exploitable en tant que tel

Inconv�nients:

• une fois compil�, le code est tr�s, tr�s verbeux. Avec cet exemple tr�s simple on a multipli� par 10 la taille du code apr�s compilation. Et plus les liaisons dans le template seront complexes, plus ce facteur risque d'augmenter.
• il n'y a actuellement pas d'optimisation pour g�rer les parties statiques des templates. Le second paragraphe est ainsi construit manuellement avec ses r�f�rences sans que cela soit vraiment n�cessaire.

Vu que la latence r�seau reste le probl�me de perf num�ro 1 pour l'usage web, le fait que la pr�compilation vienne d�cupler la taille des templates est un �norme d�savantage, que le faible poids de la lib en elle-m�me peut difficilement compenser � lui seul (et puis afficher le poids gzipp� c'est tricher :p ). A la rigueur, je peux y voir un int�r�t pour les applications JS hors-ligne ou embarqu�es. Mais alors le faible poids de la lib n'est plus un argument en sa faveur non plus.

J'ai aussi de grosses craintes sur la r�solution de divers probl�mes tels que les boucles infinies ou la r�sistance aux modifications inopin�es du DOM. C'est le genre de chose pour lesquels Angular/React/Vue ont des m�canismes d�di�s, j'ai moi-m�me d� le faire sur mon side-project de lib de data-binding. Mais en l'�tat, j'ai l'impression que Monkberry ne fait rien de tout �a et se contente d'une sorte de transpilation template HTML --> JS b�te et m�chante.

Bref j'attends d'avoir plus de retours et des d�mos r�elles d'applications pour juger, mais je suis tr�s mitig� pour le moment.

[Paleo]

Merci pour l'analyse.

C'est bien du data-binding, � partir du moment o� il y a des mises � jour partielles du DOM et une r�solution des liaisons dans un mod�le de donn�es.

Le data binding n'implique-t-il pas par d�finition une synchronisation automatis�e ? Ici, apr�s chaque modification des donn�es, il faut faire un :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

view.update(state);

C'est un peu comme si vous �criviez vos mises � jour du DOM � la main, sauf que l� c'est un compilateur qui s'en charge.

C'est-�-dire que Monkberry donne un langage de template � ceux qui veulent g�rer des morceaux du DOM � l'ancienne.

Vu que la latence r�seau reste le probl�me de perf num�ro 1 pour l'usage web, le fait que la pr�compilation vienne d�cupler la taille des templates est un �norme d�savantage

Ah, effectivement. D'exp�rience, en ce qui me concerne, le poids des templates dans une application JS n'est pas �norme relativement au code JS, mais c'est un point � v�rifier.

J'ai aussi de grosses craintes sur la r�solution de divers probl�mes tels que les boucles infinies ou la r�sistance aux modifications inopin�es du DOM. C'est le genre de chose pour lesquels Angular/React/Vue ont des m�canismes d�di�s, j'ai moi-m�me d� le faire sur mon side-project de lib de data-binding. Mais en l'�tat, j'ai l'impression que Monkberry ne fait rien de tout �a et se contente d'une sorte de transpilation template HTML --> JS b�te et m�chante.

Boucles infinies : il faudrait que je vois un exemple, je ne comprends pas o� est le risque.
Pour les modifications inopin�es du DOM : il me semble aussi que rien n'est g�r�.

[SylvainPV]

Il faut voir ce que l'on entend par "synchronisation automatis�e". Je d�compose �a en trois points: d�tection de changements, r�solution des liaisons et mise � jour du DOM. Le data-binding d�signe surtout la partie interm�diaire qui relie mod�le et DOM, � partir de l� on a des techniques de change detection et de mises � jour du DOM tr�s diff�rentes selon les solutions comme vu dans l'article. Les React / Redux / Vuex et autres Flux-based fonctionnent tous avec une API de changement d'�tat par exemple.

Pour les boucles infinies j'en parle en d�but de l'article.

[Paleo]

Pour les boucles infinies j'en parle en d�but de l'article.

Le 2-way data binding pose plusieurs probl�matiques, dont la principale est celle de provoquer des boucles infinies dans certains cas. Un match de ping-pong peut survenir lorsqu'une mise � jour du mod�le entra�ne une mise � jour de la vue qui elle-m�me entra�ne une mise � jour du mod�le, qui elle-m�me entra�ne une mise � jour de la vue, etc.

Sauf erreur, cette probl�matique est en dehors du scope de Monkberry, puisqu'il n'y a pas de d�tection des changements. Et pas non plus de mise � jour automatis�e d'un �tat � partir de valeurs d'un formulaires. Ici, c'est au d�veloppeur de faire attention � ce qu'il fait.

[SylvainPV]

Le fait que Monkberry ne fasse pas de 2-way data-binding r�duit les risques, c'est s�r, mais il y a d'autres mani�res de provoquer des boucles infinies: listeners d'�v�nements, hooks, setters... . La raison pour laquelle j'associe 2-way d-b avec boucles infinies dans l'article, c'est que ce m�canisme induit beaucoup d'op�rations discr�tes qui peuvent �chapper au d�veloppeur et le surprendre, d'o� l'�mergence de bugs / boucles infinies. Mais ce n'est pas le 2-way d-b qui est � l'origine du probl�me, c'est juste un facteur aggravant car plus complexe � appr�hender par le d�veloppeur. Au final, c'est toujours au d�veloppeur de faire attention et de se corriger, qu'il y ait un m�canisme de pr�vention ou non.

Pour reprendre l'exemple de l'article avec Monkberry et provoquer une boucle infinie de fa�on na�ve : http://jsfiddle.net/65re07Ls/1/