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:
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 :
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.
1 |
0 |