ripple.js : templating JavaScript
Avec ajout de plugins propre aux vues et aux composants
Le 2014-04-23 08:10:37, par vermine, Expert éminent sénior
ripple.js : templating JavaScript avec ajout de plugins propre aux vues et aux composants
ripples.js est une bibliothèque JavaScript pour la création de modèles (templates) et la liaison de données (data binding) construite par Segment.io. Elle s'articule autour de templates et a une API permettant d'ajouter des plugins aux composants.
On y retrouve des similitudes avec Reactive (observables, etc.), AngularJS, Handlebars et React (construction d'interface utilisateur). La différence majeure avec les autres bibliothèques de ce genre est qu'il n'y a aucune utilisation globale. Chaque vue a son propre ensemble de plugins et de liaisons.
Il y a un exemple qui utilise un modèle intégré dans un élément script et deux plugins : ripple.events et ripple.markdown. Les plugins autorisent l'observation des modifications dans une textarea et la seconde partie est configurée pour afficher le résultat à l'aide d'une directive sur un élément div.
Le modèle pour la composition de la vue permet que cette dernière soit intégrée et que les données seront toujours synchronisées lorsque la vue change.
La bibliothèque comporte par exemple :
Téléchargement (version 0.3.2).
La page GitHub.
D'après un article sur DailyJS.
Et vous ?
Que pensez-vous de cette bibliothèque ?
Quel outil utilisez-vous pour faire vos templates ?
ripples.js est une bibliothèque JavaScript pour la création de modèles (templates) et la liaison de données (data binding) construite par Segment.io. Elle s'articule autour de templates et a une API permettant d'ajouter des plugins aux composants.
On y retrouve des similitudes avec Reactive (observables, etc.), AngularJS, Handlebars et React (construction d'interface utilisateur). La différence majeure avec les autres bibliothèques de ce genre est qu'il n'y a aucune utilisation globale. Chaque vue a son propre ensemble de plugins et de liaisons.
Code javascript : |
1 2 3 4 5 6 7 8 9 10 | var Person = ripple('<div>{{name}}</div>') .use(events) .use(each) .use(dispatch); var person = new Person({ name: 'Tom' }); person.appendTo(document.body); |
Il y a un exemple qui utilise un modèle intégré dans un élément script et deux plugins : ripple.events et ripple.markdown. Les plugins autorisent l'observation des modifications dans une textarea et la seconde partie est configurée pour afficher le résultat à l'aide d'une directive sur un élément div.
Le modèle pour la composition de la vue permet que cette dernière soit intégrée et que les données seront toujours synchronisées lorsque la vue change.
La bibliothèque comporte par exemple :
- l'utilisation de template HTML avec les accolades comme délimiteur ;
Code html : 1
2
3
4<div class="{{type}}"> <img src="{{avatar}}" /> {{ firstName + " " + lastName }} </div>
Code javajscript : 1
2
3
4
5
6{ "type": "winner", "avatar": "http://ragefaces.io/rage.png", "firstName": "Nicolas", "lastName": "Cage" }
- l'intégration avec Component (fichier json) ;
- la manipulation du DOM (appendTo, replace, before et after) ;
- des événements (construct, created, ready, etc.) ;
- des getters et setters.
Et vous ?
-
SylvainPVRédacteur/Modérateur"La plupart des langages" n'inclut pas JavaScript, or c'est une lib JavaScript !PHP et Javascript sont eux-mêmes des moteurs de rendule 23/04/2014 à 16:27
-
SylvainPVRédacteur/ModérateurNon, le moteur de rendu c'est le composant logiciel intégré à ton navigateur qui permet de dessiner les pages Web. Webkit, Gecko, Trident, Servo sont des moteurs de rendu. JavaScript et PHP sont des langages de programmation.
Utiliser innerHTML peut convenir pour des cas simples, mais quand on parle d'applications web riches, les modèles de page et les interactions sont bien trop complexes pour qu'on puisse se contenter de cette solution. C'est tout l'intérêt du template : rendre plus lisible et maintenable la génération de larges pans de HTML en JavaScript.
Je te suggère un peu de lecture : http://sylvainpv.developpez.com/tuto...lating-client/le 23/04/2014 à 21:09 -
yenicallCandidat au Club>akrogames
Je ne suis pas d'accord avec toi : Tu affirmes que l'utilisation de moteur de rendu est une erreur de conception car les langages on un "moteur de rendu" intégré et que cela ajoute une complexité supplémentaire
Je vais pousser ce raisonnement vers l'absurde:
Pourquoi utiliser des frameworks comme Zend,Symfony, Jquery, Angular, alors que l'on peut très bien coder sans ces frameworks car ils ajoutent une complexité non négligeable ?
Pourquoi utiliser Doctrine VS PDO/mysqli en PHP ?
Pourquoi faire des interfaces graphiques alors que l'on peut directement écrire sur la console ?
Serte c'est vrai que tu peux afficher du texte avec echo en php, ou document.write en JS, mais tout comme les frameworks, ils (Moteurs de rendu) ne sont pas nécessaires mais ajoute une couche d'abstraction rendant la création d'application plus rapide et plus facilement maintenable.
Tu comparesCode : <?php echo $this->name; ?>
Code : {{name}}
La deuxième méthode transforme ton code enCode : <?php if(isset($this->name) && !empty($this->name)){ echo $this->name;} ?>
-------
Edition: Correction de mon orthographe, tournure de phrasesle 24/04/2014 à 11:11 -
anykeyhMembre confirmé
Les moteurs de templating n'ont pas besoin d'exister car les langages intègre déjà des fonctionnalités d'affichage.
- Les moteurs de jeu 3D n'ont pas besoin d'exister, car openGL ou directX font déjà du rendu de triangles/pixel
etc...
En fait, le principe d'une bibliothèque, c'est justement de se greffer au dessus de ce qui se fait déjà. Si javascript/php n'intégraient pas de fonctionnalités d'affichage, comment un moteur de templating pourrait être produit dessus?
Il se trouve que ce genre de framework ajoute une surcouche (principe d'un framework, hein), afin de simplifier l'intégration, qui peut-être très pénible sur de gros projets.
On oublie souvent un point essentiel, à savoir que l'intégration c'est dur à tester. Les tests unitaires sur du rendu HTML, bof bof j'y crois pas trop (si quelqu'un a la recette magique je prend).
Alors on ajoute un peu de complexité là ou l'ont peut tester (initialisation de la lib, parametrage, création d'une architecture pour recuperer les templates etc), tout en réduisant la complexité là où c'est difficile à maintenir.
Je le vois comme ça, l'interêt des moteurs de templates/rendu.le 24/04/2014 à 13:34 -
ShutyMembre éprouvéPour le coup, je ne suis absolument pas du même avis que toi ! Le templating permet ou plutôt aide principalement les intégrateurs / designers à concevoir simplement leurs design sans pour autant connaitre les profondeurs d'un langage de développement.
Je ne suis pas un grand amoureux de Smarty (je préfère Twig) mais il s'avère être d'une grande utilité. C'est pourquoi Prestashop l'utilise...le 23/04/2014 à 12:04 -
teddyFryMembre à l'essaiJe ne vois pas trop en quoi le templating est un problème de conception. Que l'on pousse les informations via du binding de données ou que l'on parse un fichier template le principe reste le même et dans tous les cas un moteur de rendu se charge de générer l'interface utilisateur.
Le but étant de séparer la génération de l'interface de la manipulation des données. L'erreur serait pour moi de générer du code HTML dans son code.
En tout cas un tel framework doit prendre tout son sens avec Node.JS, j'essayerai ça ce week-end par curiosité.le 23/04/2014 à 14:23 -
SylvainPVRédacteur/ModérateurJe suis le seul à voir une ressemblance frappante avec les Backbone.View et handlebars ?le 23/04/2014 à 14:54
-
vermineExpert éminent séniorle 23/04/2014 à 15:09
-
SylvainPVRédacteur/ModérateurCe n'est pas l'impression que j'ai eu
Enfin, libre à toi de ne pas utiliser de templating JavaScript, si tu estimes ne pas en avoir besoin le 24/04/2014 à 13:06 -
kimjoaMembre confirméEt je ne te parle pas de la surcouche innerHtml mais de la fonctionnalité write de JS. Les moteurs de templating n'ont pas besoin d'exister car les langages intègre déjà des fonctionnalités d'affichage.
Il y'a une grosse différence entre le JS et le PHP, c'est que à la base le JS n'a pas été fait pour faire du templating, contrairement à PHP.
Y'a pas de balise sur la sortie standard, comme en PHP avec les <?php ?> ou <?= ?>, du coup tout ce base sur des strings, strings qui sont en JS très limité, pas d'interpolation, pas de multiligne!
PHP n'a pas besoin de moteur de template, lourd, lent, demandant un apprentissage, obligeant souvent à découpler la partie récupération des données et affichage des données. Il se suffit largement à lui même!
Il existe une solution simple et élégante reprenant le principe du PHP avec ses open tag, comme ejs, ou le micro-templating de jonh resign, et c'est vraiment pratique quand on veux pas se trimbaler des chaines à rallonge, source d’erreurs, sans aide à l’auto complétion, illisible.
Une autre solution est de s'abstraire du html et construire ses éléments directement avec le DOM, via un jeux de fonction simple pour limiter la verbosité de l'API, des fonctions du type hdiv([attributs], [...elements]). C'est la solutions que j'ai choisit au taf, car l'implémentation du data-binding est vraiment plus aisé et on reste sur du javascript. Pas de directive, ou autre pseudo code/attribut à définir... Besoin de capitaliser une chaîne, et un coup de toUpperCase et c'est terminéle 24/04/2014 à 20:24