DHH confirme la tendance UJS pour Rails 3

Community FR
1

Sans grande surprise, mais ça fait du bien de le noter, DHH confirme que
la
tendance pour les helpers AJAX de Rails 3 sera d’utiliser l’Unobscursive
JavaScript. Fini le inline JS généré par les remote_truc qui placent de
gros
paquets pas beaux dans nos belles vues (HAML bien sûr). D’ailleurs, plus
personne ne les utilise les remote helpers de Rails… nan ?

Le message :
http://groups.google.com/group/rubyonrails-core/msg/513775eab7724b96

Nicolas.

2

Le 5 février 2009 23:08, Nicolas a écrit :

Sans grande surprise, mais ça fait du bien de le noter, DHH
confirme que la tendance pour les helpers AJAX de Rails 3
sera d’utiliser l’Unobscursive JavaScript.

ça fait une semaine qu’il l’a dit… Comme le dit NZKoz, bikeshedding
en vue

– Jean-François.

–
http://twitter.com/underflow_

3

cool, reste plus qu’Ã remplacer prototype pour jquery maintenant xD

4

2009/2/5 Nicolas B. [email protected]

l’Unobscursive JavaScript.

Unobtrusive ? (d’accord le mot peut sembler obscur :wink:

5

Oui, plus qu’à intégrer jQuery, et trouver une solution pour ces
câââââlice
de tâbernac’ de liens “delete” qui font du JS pour éviter d’envoyer une
requête “GET”…

Michel B.

6

Normalement c’est le but ^^°

Sauf erreur de ma part le JS unobtrusive c’est :

  • qui dégrade bien (fonctionnement sans JS non perturbé, même si moins
    “fun”)
  • qui ne pollue pas (rien dans le HTML et tout dans un .js)

Michel B.

2009/2/6 Nicolas G [email protected]

7

On Fri, Feb 6, 2009 at 1:55 AM, Thomas B. [email protected] wrote:

2009/2/5 Nicolas B. [email protected]

l’Unobscursive JavaScript.

Unobtrusive ? (d’accord le mot peut sembler obscur :wink:

même question a priori ce serait donc du unobtrusive (donc non visible
dans
le code source html).

non ?

NG

8

Michel B. a écrit :

Oui, plus qu’à intégrer jQuery, et trouver une solution pour ces
câââââlice de tâbernac’ de liens “delete” qui font du JS pour éviter
d’envoyer une requête “GET”…

Ce serait bien de pouvoir utiliser DELETE qui est prévu par HTTP mais
qui n’est pas implémenté dans les navigateurs.

Il y a quand même un avantage à ce lien qui génère du javascript c’est
qu’un robot ne peut pas supprimer une ressource simplement en le
suivant.

Après pour permettre du javascript non intrusif pourquoi n’aurait on pas
une structure de dossiers comme pour les vues dans le dossier
javascript, du genre:
javascript
products
show.js

On pourrait automatiquement inclure le show.js lorsqu’un render du
show.html.erb est effectué, avec un mécanisme de content_for par
exemple.

Par contre ce ne sera pas forcément simple de maintenir du code généré.

–
Martin C. || fuse
http://www.noremember.org

9

2009/2/6 Martin C. [email protected]

Par contre ce ne sera pas forcément simple de maintenir du code généré.

Rien ne t’empêche d’organiser ton dossier “public” comme tu le sens en
même
temps, et toutes les vues n’ont pas forcément besoin d’un fichier js
spécifique. Personellement je trouve que c’est un peu comme les vues
RJS, ça
me semble un peu overkill quand l’objectif est juste d’afficher une
ressource dynamiquement.

Au final, je préfère amplement faire de l’AJAX pour charger les bouts de
vue
et les formulaires new / edit, et faire du bubbling pour supplanter
l’action
des liens. Ca évite de faire plein de vues qui contiennent une ligne de
JS
chacun, et avec jQuery c’est vraiment super simple. Je vais avoir un
exemple
de cette méthode à montrer dans quelques jours dans mon github pour ceux
que
ça intéresse, je vous tiens au courant.

Michel B.

10

Bonjour,
personnellement je me suis déjà mis UJS en jouant bien modestement
avec des “content_for” accompagnés de labels bien goaler et
référencésdans le layout principal.
A l’usage c’est pas bien compliqué d’écrire les quelques javascripts
reprenant les habillages Ajax qu’on peut trouver dans un
remote_form_for.
Evidemment j’en ai pas beaucoup dans le code…
J’y vois un autre intérêt : l’intégration plus simple de frameworks JS
annexes complétant Prototype.

voilà @+

Mathieu BODIN

11

Michel B. a écrit :

On pourrait automatiquement inclure le show.js lorsqu'un render du
show.html.erb est effectué, avec un mécanisme de content_for par
exemple.

Par contre ce ne sera pas forcément simple de maintenir du code généré.

Rien ne t’empêche d’organiser ton dossier “public” comme tu le sens en
même temps, et toutes les vues n’ont pas forcément besoin d’un fichier
js spécifique.

Je ne dis pas qu’il faut un fichier js pour chaque vue, seulement quand
c’est nécessaire.

Au final, je préfère amplement faire de l’AJAX pour charger les bouts de
vue et les formulaires new / edit, et faire du bubbling pour supplanter
l’action des liens.

Je suis d’accord avec toi mais je parle de code généré, comme l’exemple
du link_to avec un :method => :delete.

Si on ne veut plus que ce code soit intrusif il faudra bien le mettre
quelque part.

–
Martin C. || fuse
http://www.noremember.org

12

Le 6 févr. 09 à 10:11, Martin C. a écrit :

Ce serait bien de pouvoir utiliser DELETE qui est prévu par HTTP mais
qui n’est pas implémenté dans les navigateurs.

Ca, c’est sûr… ça serait vraiment bien.

Il y a quand même un avantage à ce lien qui génère du javascript c’est
qu’un robot ne peut pas supprimer une ressource simplement en le
suivant.

Il y a le no-follow pour ça, nan ? Après, je ne sais pas si tout les
bots le prennent en compte. Encore moins les bots de spam.

exemple.
Je suis moyen bof d’accord avec ça.
En plus de multiplier les fichier de code, ça deviendrait horrible en
cas de partial (faudrait inclure leurs JS aussi ?).
Et puis ca multiplie les requêtes pour les fichiers js, donc le
chargement de la page…
C’est mieux tout dans le application.js, non ? En plus, s’il est
compressé, c’est encore mieux)

Par contre ce ne sera pas forcément simple de maintenir du code
généré.

Aussi.

Enfin, c’est juste mon avis…

–
Meuble
http://imeuble.info

13

2009/2/6 Michel B. [email protected]

Au final, je préfère amplement faire de l’AJAX pour charger les bouts de
vue et les formulaires new / edit, et faire du bubbling pour supplanter
l’action des liens. Ca évite de faire plein de vues qui contiennent une
ligne de JS chacun, et avec jQuery c’est vraiment super simple. Je vais
avoir un exemple de cette méthode à montrer dans quelques jours dans mon
github pour ceux que ça intéresse, je vous tiens au courant.

Michel B.

Ok, chose promise, voici un petit bout d’appli Rails avec du jRails
nonobtrusive et qui dégrade pas trop mal :

Bon, c’est sans prétention, c’est un peu un toy-project pour tester
jRails
et parce que je suis en train de me remettre à chercher du boulot, et il
n’est pas encore vraiment polis et tout (il manque encore les tests
entre
autres, honte sur moi, je vais les rajouter ASAP), mais c’est amplement
suffisant pour voir qu’un tout petit peu de “gentil” JavaScript (avec
jQuery…) remplace harmonieusement tout plein de “vilain” rjs qui part
dans
tous les sens et qui dégrade pas trop bien.

Sinon, n’hésitez pas à dire ce que vous en pensez si vous en pensez
quelque
chose, je suis toujours intéressé par l’opinion de mes pairs.

A ce soir pour l’apéro…

Michel B.

14

Stéphane Akkaoui a écrit :

chargement de la page…
C’est vrai que si tu as une vue qui render 10 partials avec chacun leur
js, ça devient coûteux en requêtes http, mais ce n’est pas forcément si
courant que ça.

A l’inverse, combien de pages charge tout la lib prototype (voir
script.aculo.us) alors qu’il n’y a aucun javascript à exécuter parfois ?

C’est mieux tout dans le application.js, non ? En plus, s’il est
compressé, c’est encore mieux)

C’est clair que c’est mieux en terme de requêteq http car il y en a
moins, mais ça pose plusieurs problèmes.

D’abord en terme de maintenance, si j’enregistre tous les événements de
page1 et page2 dans un même fichier je dois chaque fois vérifier que je
suis bien dans tel contexte et pas dans l’autre.

Avec de la délégation c’est plus léger mais avec beaucoup de pages ça
devient vite un cauchemar.

En terme de performances ça dépend de la taille de l’application.
Pour une grosse appli il vaut peut être mieux charger deux fichiers de
quelques ko qu’un fichier application.js de 100ko dont 90% du code ne te
sert pas dans le contexte actuel.

Pour une petite appli ce serait plus l’inverse.

Dans le meilleur des deux mondes ce qui serait intéressant serait que le
framework fasse automatiquement la concaténation des fichiers javascript
avant d’envoyer ça au navigateur. Faut voir les inconvénients.

–
Martin C. || fuse
http://www.noremember.org