JeuWeb - Crée ton jeu par navigateur
Javascript "déclaratif" ou "impératif"? - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Javascript "déclaratif" ou "impératif"? (/showthread.php?tid=7878)

Javascript "déclaratif" ou "impératif"? - Xenos - 27-09-2017

Salutations,

s'il y a bien une méthode d'utilisation de javascript que je trouve cohérente pour du jeu web un peu lourd et les sites web en général, c'est pour enrichir le langage HTML.

En d'autres mots, je n'aime pas la façon "jQuery" (je ne sais pas trop comment l'appeler?!) qui consiste à balancer du code JS au milieu de la page pour aller manipuler ses éléments de manière impérative. Par exemple:

Code :
<!-- Et encore, c'est parfois des "span" que je vois -->
<a href="#">Open modal</a>

<script>
$('a').on('click', function () { $.openInModal("lalala.html"); }
</script>

En revanche, l'autre approche que j'affectionne consiste à "déclarer" de nouveaux comportements à partir des classes HTML, et éventuellement des data attributes. Par exemple:

Code :
// JS dédié, global
// qui utilise les DOMMutation ou autre pour trigger la ligne ci-dessous
document.querySelectorAll('a.open-in-modal').forEach(
  n => n.addEventListener(
    'click',
    e => { /* code de l'openInModal avec n.getAttribute('href') */}));

Code :
<!-- Code utilisateur, dans n'importe quelle page du site -->
<a href="lalala.html" class="open-in-modal">Open modal</a>

Bref, le concept revient à centraliser les morceaux JS pour n'avoir plus que des attributs à poser dans ses balises HTML (et le "framework" se démerde pour appliquer à ces éléments HTML "customs" les comportements correspondants). Voire, s'il est "bien fait", le code JS global peut retirer le comportement spécifique si la classe "open-in-modal" est retirée du noeud HTML.
Comme dit: on n'est pas très loin de la notion de "custom elements", avec comme seule éventuelle différence de se baser sur la class plutôt que sur le nom du tag. Ce qui permet du coup de dupliquer le node sans aucun problème (le comportement sera ensuite rajouté au noeud dupliqué par le JS global), ce que la 1er méthode ne permet pas (il faut ré-appliquer le comportement manuellement).


Au final, mes questions sont les suivantes:
• Comment utilisez-vous le JS dans vos jeux, et éventuellement à votre taff? Façon 1 (que je qualifie d'impérative: j'appelle la fonction JS à l'endroit où j'en ai besoin) ou façon 2 (que je qualifie de déclarative: je pose une classe sur mon élément HTML et le code JS du jeu se démerde) ?
• Existe-t-il un nom de pattern pour ces deux approches? Voire des frameworks qui utilisent l'une ou l'autre de ces approches?
• Quels avantages/inconvénients aux deux approches?

[Oui, c'est peut-être un peu hors contexte et mal formulé, mais c'est une question qui est passée au taff]

RE: Javascript "déclaratif" ou "impératif"? - Ter Rowan - 27-09-2017

non mais le 1) c'est juste pas beau, c'est le pattern "je fais au plus vite, sans qualité"

dans les applis qu'on construit de mon côté, on utilise angular (4 juste pour dire pas angularjs) du coup tout ça est mis complètement autrement

pour simplifier
ton appli est découpée en page / module / composant

et chaque composant a sa partie html / comportement / etc soit 3 , 4 , 5 fichiers par composant

et un fichier global qui consolide les composants


par contre quand je faisais du jquery (a titre perso) j'avais des fichiers js (avec les include qui va bien) et dans le html, éventuellement un peu de js à la fin du body pour déclarer 2 - 3 truc. Mais jamais des on.machin au milieu de l'html. c'est pas jquery en cause là, c'est le développeur

RE: Javascript "déclaratif" ou "impératif"? - niahoo - 27-09-2017

J'ai pas encore tout lu mais déjà c'est super biaisé car tes codes sont équivalents, tu utilises juste de manière crade ton jQuery et pas l'autre façon.

Tu peux utiliser jQuery, $() et .on() dans un fichier, au bon endroit proprement. C'est équivalent à utiliser querySelector et addEventListener mais avec un support automatique pour la compatibilité avec les anciens navigateurs.

edit:

Voilà, d'accord avec Ter Rowan, nous on utilise Vue, et perso React ou snabbdom donc il n'y a pas vraiment d'équivalence, mais sinon avec jQuery tu peux juste faire ça :

Code :
$(document).on('click', 'a.open-in-modal', function(evt) {
  var n = evt.target
  // ...
});

Dans un fichier, bien proprement, et tu peux ajouter/enlever ta classe quand tu veux sur tes a.

RE: Javascript "déclaratif" ou "impératif"? - Xenos - 27-09-2017

Ouep, donc on retombe bien sur le même avis, en considérant qu'avoir une classe CSS (dans le cas présent) définie, unique, centrale, commune pour tout le site est bien plus cohérent que de laisser chaque page poser ses classes et aller faire son binding.

J'avais du mal à exprimer cette idée: c'est la notion de "classe CSS centralisée, pareille pour tout le monde" qui change véritablement entre les 2 approches; la première prend des classes à la volo-osef parce que le code de binding est juste spécifique à cette page et celle-là seulement, alors que la seconde décharge chaque page de ce binding en allant simplement établir une classe CSS commune à tout le monde pour ouvrir son lien dans une modale.

Merci Smile je n'arrivais vraiment pas à mettre la formulation sur ce concept

PS: @niahoo dans l'exemple, je m'en fous un peu de la différence vanilla/jQuery, c'était surtout question de sélecteur commun au site

RE: Javascript "déclaratif" ou "impératif"? - Sephi-Chan - 27-09-2017

Depuis 2 ans j'utilise React, donc c'est plutôt déclaratif. Le gestion de l'état de l'application (via Redux) est inspiré de la programmation fonctionnelle (une action prend un état de départ et retourne un état d'arrivée), ce qui rend la logique facile à suivre.

RE: Javascript "déclaratif" ou "impératif"? - Argorate - 29-09-2017

Moi je fais du

Code :
$document.on 'click', 'a.open-in-modal', (evt)->

encapsulé par mon bind manager qui fait en sorte de déclarer ça qu'une seule fois,
puisque dans mon cas je recharge jamais les pages (turbolink inside), donc je charge le JS petit à petit, et si tu reviens sur une page déjà visité, les bind sont déjà fait Smile

Mais oui, c'est mieux d'avoir une classe et y associer un comportement.

D'ailleurs grâce à mon système, j'ai des bind qui ne sont fait qu'une fois mais qui marche sur tout le site et pas juste une page spécifique... Wink