Intercooler.js

Posté par Ontologia (site web personnel) le 05 juillet 2014 à 11:15. Édité par Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

juil.

2014

Intercooler.js est une énième, mais nouvelle bibliothèque JavaScript pour les sites web orientés client lourd.

Elle propose un mécanisme déclaratif assez intéressant : le comportement de l'interface est codé dans les attributs de balises HTML standard.
Elle simplifie la vie du développeur en évitant de devoir intégrer des évènements sur des sélecteurs JQuery (ou ses concurrents) : celui-ci a le choix de provoquer un appel AJAX ou un appel interne sur une fonction javascript, de manière déclarative dans le code HTML.

Intercooler est basé sur le concept de Partial View Controller. Dans cette approche, le serveur renvoi des fragments de HTML à intégrer dans l'interface.

Quelques exemples valent mieux qu'un long discours :

Cet exemple montre comment provoquer un appel AJAX lors d'un clic dans une div.

<div ic-src="/example/click">
        You have not yet clicked the button
</div>
<button class="btn btn-primary" ic-post-to="/example/click">
        Click Me!
</button>

Si l'utilisateur clique sur le bouton, le contenu de la div ayant l'attribut ic-src="/example/click" sera remplacé par le retour de l'appel AJAX en POST à l'URL /example/click.

Mais grâce à la fonction addURLHandler(handler), on peut faire en sorte que l'URL /example soit captée en interne :

(function () {
            var clicks = 0;
            Intercooler.addURLHandler({
              'url': '/example/click',
              'get': function () {
                return 'You have clicked the button ' + clicks + ' times'
              },
              'post': function(){
                clicks++;
              }
            });
          })();

Bref, cette bibliothèque offre des possibilités affriolantes, même si elle est encore jeune.
Elle permettrait même à un webdesigner peu versé dans le développement de rajouter un peu d'interactivité dans ses pages.

Aller plus loin

Le site du framework (873 clics)
Introduction rapide au framework (355 clics)
API (70 clics)

# Questions

Posté par rogo le 05 juillet 2014 à 13:01. Évalué à 8.
Quelques questions à chaud, je n'ai pas pris le temps de creuser :
1. Je croyais que les specs HTML (sans parler de feu xHTML) interdisaient les attributs "maison". Certes, les navigateurs peuvent bouffer n'importe quoi, mais c'est gênant d'avoir des pages non-valides, ne serait-ce que parce que cela gêne la détection des autres erreurs. Pourquoi ne pas avoir utilisé des attributs data-ic-* ?
2. Apparemment, ce framework mélange une partie de la logique de traitement à la couche d'affichage. Cela va à l'encontre du principe usuel de séparation des activités. À l'usage, ce n'est pas un peu le bazar d'avoir une partie du JS mêlée au HTML ?
3. L'exemple proposé s'écrit facilement avec le standard jQuery. C'est à peine plus lourd, mais bien plus explicite. J'ai du mal à voir le gain de ce framework.
```
<div id="example-click">
        You have not yet clicked the button
</div>
<button class="btn btn-primary" onclick="$('#example-click').load('/example/click')">
        Click Me!
</button>
```
Idem pour l'interception des appels AJAX, avec jQuery.ajaxSend(). Quel est l'intérêt d'introduire un langage déclaratif à apprendre en plus de Javascript et ses frameworks ?
- [^] # Re: Questions
  
  Posté par claudex le 05 juillet 2014 à 14:28. Évalué à 4.
  
  L'exemple que tu donne ne traite pas les erreurs, peut-être que ce framework le fait par défaut.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Questions
    
    Posté par rogo le 06 juillet 2014 à 13:09. Évalué à 3.
    Mauvaise pioche. Le mot "error" est absent de la doc officielle, et il n'est présent dans l'API que pour cette ligne :
```
error.ic(evt, elt, req, status, str)     Triggered after an error occurs during an intercooler request
```
    Ça semble équivalent à jQuery :
```
.ajaxError(handler(event, jqXHR, ajaxSettings, thrownError))
```
    En passant, une info qui n'est bizarrement pas mis en avant, c'est que intercooler.js est une extension de jQuery. En lisant la présentation succincte, je croyais qu'il fallait apprendre une nouvelle API dès qu'on avait besoin de sortir un peu des clous, alors qu'apparemment on revient en ces cas à du jQuery usuel.
- [^] # Re: Questions
  
  Posté par rakoo (site web personnel) le 05 juillet 2014 à 14:29. Évalué à 8.
  
  À l'usage, ce n'est pas un peu le bazar d'avoir une partie du JS mêlée au HTML ?
  
  Il est temps de se demander vraiment ce que veut dire réellement la séparation des activités. Je sais pas si tu as déjà vu des applications web un peu grosses, mais dans la soi-disant couche "présentation" (ie HTML), il y a toujours un bout de "logique" (un semi-langage en plus, pas HTML mais pas javascript, qui permet de définir le contenu final en fonction des données, qui boucle sur ces données, etc…). La seule séparation qui existe vraiment dans ces cas-là est la séparation des langages, ce qui n'est pas intéressant du tout.
  
  Je t'invite à regarder cette vidéo, présentée par l'un des types derrière React. Il y parle du framework, mais il invite surtout à réellement réfléchir sur ce que tu veux faire pour ton application: l'historique des technos web fait que tu veux naturellement séparer HTML, CSS et JS mais en fait ce qui t'intéresse réellement c'est séparer ton application en composants interopérables et réutilisables, quelles que soient les technologies/langages/frameworks que tu utilises pour les créer.
  
  L'exemple proposé s'écrit facilement avec le standard jQuery.
  
  C'est un exemple; je pense qu'il faut voir ça à l'usage, sur des applications un peu plus grosses.
  - [^] # Re: Questions
    
    Posté par groumly le 06 juillet 2014 à 21:48. Évalué à 10.
    
    Je sais pas si tu as déjà vu des applications web un peu grosses, mais dans la soi-disant couche "présentation" (ie HTML), il y a toujours un bout de "logique" (un semi-langage en plus, pas HTML mais pas javascript, qui permet de définir le contenu final en fonction des données, qui boucle sur ces données, etc…).
    
    C'est pas un probleme ca, les vues ont parfaitement le droit d'avoir du code, tant que c'est de la pure presentation.
    Ya pas de mal a avoir "updateWithFoo" sur une vue, tant que cette methode ne fait effectivement que presenter foo dans le contexte de cette vue, i.e. ne faire que modifier l'apparence de cette vue en fonction de l'etat de foo.
    C'est de la logique de presentation, tu peux vouloir formatter une date, changer la couleur du label en fonction du contenu, cacher/afficher un autre element, que sais je encore.
    
    La ou la separation doit etre faite, c'est sur l'interaction avec les vues. Le bouton baz doit dire au controlleur pouf "on m'a clique", le controlleur decide alors de dire au domaine "fait cette action domaine specifique", le domaine parle au serveur, traite la reponse et dit au controlleur "tiens, le serveur a repondu blabla", et le controlleur dit alors a la vue "ok, voila ce qu'il faut montrer maintenant" (ou passe la main au controleur suivant, ou affiche nue erreur, ou que sais je encore).
    
    Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# En tant que développeur web du dimanche ...

Posté par KiKouN le 06 juillet 2014 à 09:08. Évalué à 3.

… , j'aime bien. Cela ne m'a pas pris 3 plombs pour faire quelques choses de plaisant et surtout je n'ai pas eu besoin d'aller me documenter sur du JS.

Par contre, ic-pool ne marche pas ( firefox ou chromium, pas tester ailleurs ) et je n'ai pas vu de gestion d'erreur en cas de serveur indisponible. Je n'ai rien vu aussi sur la validation des données côté client mais c'est moins facile de le faire que sur de JSON ou autre.

C'est donc, dans l'état pas mal pour faire une appli interne mais pas encore adapté pour une appli public.
- [^] # Re: En tant que développeur web du dimanche ...
  
  Posté par KiKouN le 06 juillet 2014 à 10:20. Évalué à 1.
  
  Rien dis pour le ic-poll, l'erreur est même dans mon commentaire.
# et par rapport aux autres libs JS ?

Posté par flan (site web personnel) le 06 juillet 2014 à 17:32. Évalué à 4.

Je n'y connais pas grand-chose en JS, mais la présentation me fait beaucoup penser (peut-être à tort) à du Angular-JS. Du coup, ça serait pas mal de mettre un peu en avant la différence par rapport aux n-1 librairies JS précédentes, non ?
- [^] # Re: et par rapport aux autres libs JS ?
  
  Posté par rogo le 06 juillet 2014 à 21:02. Évalué à 6.
  De ce que j'ai vu par pure curiosité, je décrirais cette biblio JS ainsi :
  - C'est une surcouche à jQuery.
  - Le but est de faire les opérations AJAX simples en ajoutant des attributs déclaratifs dans le HTML.
  - Les réponses du serveur sont en HTML.
  - Pour les opérations complexes (élaboration des paramètres de la requête, réponse JSON ou XML, etc), on repasse à du jQuery.
  Personnellement, je suis très dubitatif sur les facilités d'évolution du code écrit avec ceci. Par exemple, imaginons qu'on l'utilise pour ajouter un bouton ajax : on lit un "input" et on remplit un "div" avec un message reçu par AJAX. OK, facile. Un peu plus tard, on veut faire évoluer l'AJAX : on n'enverra pas le même input suivant la case qui aura été cochée. Et la réponse devra donner, en plus du message, les options d'une liste déroulante. Il va falloir casser tout ce qu'on a fait pour le récrire en JS standard.
- [^] # Re: et par rapport aux autres libs JS ?
  
  Posté par pmoret (site web personnel) le 07 juillet 2014 à 13:29. Évalué à 5.
  
  En particulier par rapport à AngularJS, on gagne quoi ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.