Utiliser et documenter 2 ou 3 méthodes standards dès que l'on a besoin d'un module Javascript #3229

Open
opened 8 years ago by rastapopoulos · 5 comments
Owner

Actuellement, on a tendance :

  • soit à charger du JS sur toutes les pages
  • soit à le charger au moment où on en a besoin
  • soit, mieux mais fastidieux, à gérer soi-même à la main un mécanisme de chargement unique d'un module (cf GIS dernièrement)

Il semblerait pourtant qu'il existe depuis plusieurs années enfin des méthodes pour appeler un ou plusieurs modules uniquement lorsque nécessaire, et en pouvant les appeler plusieurs fois sans risque. Bref, l'équivalent des inclusions PHP.

Pour jQuery de base je ne sais pas, mais ce serait au moins utile pour tel ou tel module de jQueryUI, pour le JS de datation de SPIP, (inc-dateur), pour Leaflet, etc.

Doit-on vraiment réinventer la roue à chaque fois qu'on veut n'inclure un JS qu'une seule fois ?

http://requirejs.org/docs/whyamd.html
http://developer.telerik.com/featured/jquery-using-only-what-you-need/

Qu'en pensent les experts en cache et en performance ? :)

Actuellement, on a tendance : - soit à charger du JS sur toutes les pages - soit à le charger au moment où on en a besoin - soit, mieux mais fastidieux, à gérer soi-même à la main un mécanisme de chargement unique d'un module (cf GIS dernièrement) Il semblerait pourtant qu'il existe depuis plusieurs années enfin des méthodes pour appeler un ou plusieurs modules uniquement lorsque nécessaire, et en pouvant les appeler plusieurs fois sans risque. Bref, l'équivalent des inclusions PHP. Pour jQuery de base je ne sais pas, mais ce serait au moins utile pour tel ou tel module de jQueryUI, pour le JS de datation de SPIP, (inc-dateur), pour Leaflet, etc. Doit-on vraiment réinventer la roue à chaque fois qu'on veut n'inclure un JS qu'une seule fois ? http://requirejs.org/docs/whyamd.html http://developer.telerik.com/featured/jquery-using-only-what-you-need/ Qu'en pensent les experts en cache et en performance ? :)
Owner

Il y a plusieurs problématiques : chargement asynchrone, chargement seulement si besoin, dépendances.
A voir comment traiter ça complètement et proprement, pas de solution idéale en tête.
Actuellement ma préférence va pour :

  • si le JS a des chances d'être utilisé sur une majorité de page, insertion dans le head pour qu'il soit minifié, concaténé avec les autres scripts et toujours chargé
  • si le JS sera vraisemblablement utilisé sur une minorité de page, on charge son js via getScript+callback ce qui permet de ne le charger que si besoin, et est compatible chargement async par jQl

Mais ça ne traite pas tous les problèmes.
Version cible mise à 3.2

Il y a plusieurs problématiques : chargement asynchrone, chargement seulement si besoin, dépendances. A voir comment traiter ça complètement et proprement, pas de solution idéale en tête. Actuellement ma préférence va pour : - si le JS a des chances d'être utilisé sur une majorité de page, insertion dans le head pour qu'il soit minifié, concaténé avec les autres scripts et toujours chargé - si le JS sera vraisemblablement utilisé sur une minorité de page, on charge son js via getScript+callback ce qui permet de ne le charger que si besoin, et est compatible chargement async par jQl Mais ça ne traite pas tous les problèmes. **Version cible mise à 3.2**
Poster
Owner

Mmmh, dans ce cas, pour ces deux points, il faudrait peut-être qu'on écrive un article de documentation qui explique : "Mon plugin ou mon squelette utilise du javascript, comment dois-je l'ajouter ?"

Et qui liste alors ces deux options avec le code qui va bien montrant comment l'insérer.
Actuellement chacun⋅e se débrouille comme ille peut, sans savoir où est l'exemple parfait à copier.

Pour ton deuxième point, je dis ça dans le vide, mais peut-être qu'il y aurait moyen aussi d'encapsuler ça dans une fonction propre à SPIP qui fait ce travail de getScript/callback ? Genre spip_inclure_javascript('chemin/du/js') en expliquant où il faut l'utiliser ?

Mmmh, dans ce cas, pour ces deux points, il faudrait peut-être qu'on écrive un article de documentation qui explique : "Mon plugin ou mon squelette utilise du javascript, comment dois-je l'ajouter ?" Et qui liste alors ces deux options avec le code qui va bien montrant comment l'insérer. Actuellement chacun⋅e se débrouille comme ille peut, sans savoir où est l'exemple parfait à copier. Pour ton deuxième point, je dis ça dans le vide, mais peut-être qu'il y aurait moyen aussi d'encapsuler ça dans une fonction propre à SPIP qui fait ce travail de getScript/callback ? Genre spip_inclure_javascript('chemin/du/js') en expliquant où il faut l'utiliser ?
Poster
Owner
There is no content yet.
Owner

Version cible mise à 4.1

**Version cible mise à 4.1**
rastapopoulos added the
documentation
label 4 months ago
Poster
Owner

Imaginons que comme dans Drupal, on est une variable accessible en permanence en JS pour stocker des informations transversales comme décrit ici : #4531

Est-ce que dedans on pourrait pas stocker un état des libs chargées (en ayant une API pour ça pour pas modifier à la main bien sûr). Ainsi :

  • quand on charge une lib JS de manière permanente dès le chargement de la page, donc dans le head compressé/optimisé : on pose un drapeau pour cette lib
  • si un morceau de squelette (GIS, champ de date, Saisies diverses, etc) a besoin d'une lib : avec une API on entoure d'un test vérifiant si elle est déjà chargée càd testant le drapeau dans la variable globale, et si elle ne l'est pas, on appelle une autre fonction de l'API chargeant dynamiquement la lib (donc pouvant être dans une inclusion plus profonde, y compris chargé en ajax, en box etc), fonction simplifiée qui ferait le getScript+callback etc un peu comme GIS… ET qui poserait le drapeau disant que cette lib est désormais déjà chargée !
  • du coup si un autre morceau de squelette (plus bas ou chargé plus tard en ajax) a besoin de la même lib : même si elle a été chargée dynamiquement précédemment, on le sait déjà aussi, et donc on ne recharge rien (là aussi on aura entouré avec l'API du test si déjà chargée)

Ça reprend le principe de concept genre require en node etc, mais sans node, et surtout on peut mixer le fait de charger des choses dès l'origine, donc compressable/optimisable (mais drapeau bien posé pour chaque), avec le fait de charger plus tard, sans que ce soit tout l'un ou tout l'autre.

En effet, certains choix de ce genre ne peuvent pas être du ressort des devs de plugins : suivant le site on pourra avoir des cartes GIS ou des Saisies partout, ou sur 2 pauvres pages, et ça c'est parfois aux intés parfois aux webmasters de le savoir. Du coup pour chaque besoin, on pourra décider si on veut l'inclure en permanence (par ex GIS si je sais que j'en ai partout), ou au besoin ponctuellement quand yen a peu.

Imaginons que comme dans Drupal, on est une variable accessible en permanence en JS pour stocker des informations transversales comme décrit ici : https://git.spip.net/spip/spip/issues/4531 Est-ce que dedans on pourrait pas stocker un état des libs chargées (en ayant une API pour ça pour pas modifier à la main bien sûr). Ainsi : - quand on charge une lib JS de manière permanente dès le chargement de la page, donc dans le head compressé/optimisé : on pose un drapeau pour cette lib - si un morceau de squelette (GIS, champ de date, Saisies diverses, etc) a besoin d'une lib : avec une API on entoure d'un test vérifiant si elle est déjà chargée càd testant le drapeau dans la variable globale, et si elle ne l'est pas, on appelle une autre fonction de l'API chargeant dynamiquement la lib (donc pouvant être dans une inclusion plus profonde, y compris chargé en ajax, en box etc), fonction simplifiée qui ferait le getScript+callback etc un peu comme GIS… ET qui poserait le drapeau disant que cette lib est désormais déjà chargée ! - du coup si un autre morceau de squelette (plus bas ou chargé plus tard en ajax) a besoin de la même lib : même si elle a été chargée dynamiquement précédemment, on le sait déjà aussi, et donc on ne recharge rien (là aussi on aura entouré avec l'API du test si déjà chargée) Ça reprend le principe de concept genre require en node etc, mais sans node, et surtout on peut mixer le fait de charger des choses dès l'origine, donc compressable/optimisable (mais drapeau bien posé pour chaque), avec le fait de charger plus tard, sans que ce soit tout l'un ou tout l'autre. En effet, certains choix de ce genre ne peuvent pas être du ressort des devs de plugins : suivant le site on pourra avoir des cartes GIS ou des Saisies partout, ou sur 2 pauvres pages, et ça c'est parfois aux intés parfois aux webmasters de le savoir. Du coup pour chaque besoin, on pourra décider si on veut l'inclure en permanence (par ex GIS si je sais que j'en ai partout), ou au besoin ponctuellement quand yen a peu.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.