Comment convaincre mon patron (et d'autres développeurs) d'utiliser / de considérer le JavaScript discret


21

Je suis assez nouveau dans notre équipe de développeurs.

J'ai besoin d'arguments solides et / ou d'exemples "d'écueils", donc mon patron comprendra enfin les avantages de JavaScript discret, de sorte que lui et le reste de l'équipe, cessent de faire des choses comme ça:

<input type="button" class="bow-chicka-wow-wow" 
       onclick="send_some_ajax(); return false;" value="click me..." />

et

<script type="text/javascript">

function send_some_ajax()
{
  // bunch of code ... BUT using jQuery !!!
}
</script>

J'ai suggéré d'utiliser un modèle assez courant:

<button id="ajaxer" type="button">click me...</button>

et

<script type="text/javascript">

// since #ajaxer is also delivered via ajax, I bind events to document 
//  -> not the best practice but it's not the point....

$(document).on('click', '#ajaxer', function(ev) {
var $elem = $(this);
ev.preventDefault();

});

La raison pour laquelle mon patron (et d'autres) ne veut pas utiliser cette approche est que l'inspection des événements dans FireBug (ou Chrome Dev Tools) n'est plus simple, par exemple avec

<input type="text" name="somename" id="someid" onchange="performChange()">

il peut immédiatement voir quelle fonction s'exécute sur change-event et y accéder directement dans un énorme fichier JS plein de spaghetti-code .

Dans le cas de JavaScript discret, la seule chose qu'il verrait est:

<input type="text" name="somename" id="someid" />

et il n'a aucune idée si certains événements, le cas échéant, étaient liés à cet élément et quelle fonction sera déclenchée.

Je cherchais une solution et je l'ai trouvée:

$(document).data('events') // or .. $(document).data('events').click

mais, cette "approche" a mis "trop ​​longtemps ..." à découvrir quelle fonction se déclenche sur quel événement, donc on m'a dit d'arrêter de lier des événements comme ça.

Je vous demande quelques exemples ou de forts avantages ou tout autre type de suggestions pour "Pourquoi nous devrions utiliser UJS"

MISE À JOUR: la suggestion de "changer le travail" n'est pas une solution idéale.

MISE À JOUR 2: Ok, je n'ai pas seulement suggéré d'utiliser la liaison d'événements jQuery, je l'ai fait . Après avoir écrit toute la délégation d'événement, le patron est venu me voir et m'a demandé pourquoi je fais la délégation d'événement avec une approche différente et une approche qu'il ne connaissait pas.

J'ai mentionné des avantages évidents, comme - Il y a 15 champs de saisie et tous ont alors un onchangeévénement (non seulement, certains d'entre eux en ont aussi onkeyup) Il est donc plus pragmatique d'écrire ce type de délégation d'événement pour TOUS les champs de saisie, au lieu de le faire 15 fois, surtout si tout le HTML sera rendu avec l'écho de PHP ->echo '... <input type="text" id="someid" ... />...'


La "classe" de votre premier codebox a probablement besoin d'un =.
Joe Z.

6
Vous pouvez: 1) convaincre votre patron de vous laisser utiliser des techniques qu'il ne connaît pas; 2) enseignez à votre patron de nouvelles techniques; 3) arrêtez d'utiliser des techniques que votre patron ne connaît pas; ou 4) changer d'emploi. Ai-je oublié une option? Si vous ne voulez pas 4 et que vous ne pouvez pas réussir en 1 et 2, votre seule option restante est 3. Gardez à l'esprit que votre valeur marchande dépend de ce que vous savez. Donc, après avoir appris tout ce que votre patron approuve, vos options restantes sont: 3A) arrêtez d'apprendre et regardez votre valeur marchande chuter; 3B) apprendre et utiliser de nouvelles techniques pendant votre temps libre. L'option 3A vous coûte de l'argent, l'option 3B vous coûte du temps.
Viliam Búr

1
J'utiliserais l'approche an comme github: chaque élément qui a des événements liés dans JS a une js-this-class-do-somethingclasse, vous pouvez donc facilement CTRL + F pour cela dans le code.
caarlos0

FireQuery pourrait vous aider avec la partie "prend trop de temps". Je ne sais pas dans quelle mesure il fonctionne avec les événements, mais il devrait au moins vous indiquer qu'un élément contient des événements.
Izkata

1
Voici un bel utilitaire que j'aime utiliser lorsque je travaille avec des événements
karka91

Réponses:


49
  1. Arrêtez d'utiliser des mots à la mode et essayez plutôt de faire des arguments solides. Même la page Wikipédia pour JavaScript discret dit que le terme n'est pas formellement défini. Cela peut être un terme générique pour un certain nombre de bonnes idées, mais si cela ressemble à une simple mode ou à la mode, votre patron et vos collègues n'y accorderont pas beaucoup d'attention. Pire encore, si vous continuez à parler de quelque chose qu'ils considèrent comme inutile, ils peuvent commencer à ignorer les idées complètement indépendantes que vous préconisez.

  2. Découvrez pourquoi vous pensez que les idées JavaScript discrètes sont importantes. Est-ce parce que vous lisez qu'elles sont considérées comme des meilleures pratiques? Avez-vous rencontré des problèmes que vous pouvez attribuer à ne pas suivre ces idées? Dans quelle mesure l'adoption de ces idées aura-t-elle un impact sur les résultats de l'entreprise?

  3. Entrez dans la tête de votre patron. Pourquoi fait-il les choses comme il le fait et pourquoi a-t-il rejeté vos changements? Il n'est probablement pas stupide, et il est probablement plus expérimenté que vous, donc il a probablement de bonnes raisons de faire les choses à sa façon. Vous en avez déjà fait allusion - suivez ce fil jusqu'au bout. Ensuite, déterminez si et comment vos suggestions amélioreront les choses qui l'intéressent le plus.

  4. Astuce 1: Les gestionnaires aiment l'argent. Plus vous pouvez directement lier vos suggestions à une augmentation des revenus ou à une réduction des dépenses, plus l'impact de votre argument sera important. Astuce 2: Le temps c'est de l'argent. Astuce 3: En soi, l'attrait esthétique du code ne fait pas d'argent. Le contraire, en fait - il faut du temps pour rendre le code joli. Un code laid qui fonctionne bien convient parfaitement à la plupart des gestionnaires.

  5. Ne vous contentez pas d'en parler, faites-le . Si vous avez la chance d'avoir un petit projet autonome, demandez à votre responsable si vous pouvez le faire en utilisant le style "UJS" comme une sorte de démonstration. Lorsque vous êtes prêt, tenez une revue de code où vous pouvez expliquer comment tout cela fonctionne et pourquoi vous pensez que c'est mieux que le style actuel.

  6. L'idéalisme est génial, mais ne le laissez pas vous gêner. Il est plus important d'être considéré comme quelqu'un qui fait avancer les choses que comme un dilettante qui se plaint d'un style de codage grossier. Cela est particulièrement vrai si vous êtes le nouveau mec. Si vous ne pouvez pas obtenir de traction avec UJS maintenant, faites du bon travail à la place et créez lentement un dossier pour les modifications que vous souhaitez apporter à mesure que vous gagnez en crédibilité.

  7. Lire Switch: comment changer les choses lorsque le changement est difficile . Cela vous donnera beaucoup plus de bonnes idées sur la façon de construire efficacement votre cas.


L'essentiel de la réponse est de prouver que ujs fonctionne de manière réaliste. Montrez-leur que cela fonctionne.
OnesimusUnbound

2
@AvinashR Le fait est que ce qui motive les managers n'est souvent pas la même chose qui motive les développeurs. Nous, les développeurs, aimons que le code soit agréable et bien rangé, élégamment conçu, etc. Les gestionnaires veulent maximiser les profits. Si votre changement entraînera plus de ventes, tant mieux. Si cela se traduit par un temps de développement plus court ou moins de temps passé à retravailler ou à corriger des bogues, tant mieux. Heureux d'entendre que les clients aiment votre interface graphique, mais le patron attribue-t-il cela à UJS ou à l'apparence de l'interface graphique? Si les clients regardent votre code et disent "nous voulons que notre code ressemble à ça!" il devrait être facile de faire votre cas.
Caleb

3
En plus de "Switch", je recommanderais également "Driving Technical Change" par Terrance Ryan: terrenceryan.com/book . Aussi, dans "Bonjour HTML5 et CSS3", Rob Crowther le dit simplement: "HTML pour le contenu, CSS pour la présentation et JavaScript pour le comportement". En gardant le JavaScript hors du HTML, vous pouvez créer une bibliothèque de comportements et réutiliser le HTML partout sans codage supplémentaire. Cela, au point n ° 4 de Caleb, permet d'économiser du temps et de l'argent.
Adrian J. Moreno

2
Point 3: Ne surévaluez pas l'expérience. Je préférerais dans mon équipe un Leo Messi de 22 ans super talentueux plutôt qu'un joueur de Premier League occasionnel paresseux et surpayé de 32 ans. Le sang jeune, frais et talentueux est souvent très précieux.
Robert Niestroj

1
"Les gestionnaires veulent maximiser les profits." - Les managers souhaitent également réduire les risques; pourrait être une autre avenue.
Roger Lipscombe

8

Ce que vous pouvez faire est de leur donner une démo de débogage d'un html USJ en utilisant les outils FireQuery ainsi que Chrome Query .

FireQuery est une extension Firebug et fait un très bon travail. Quant à Chrome Query, je ne peux pas garantir à quel point il est bon, mais il est définitivement utilisé par certains des développeurs ( un post sur stackoverflow ).

Sachez également que la .datafonction est supprimée pour renvoyer les données d'événement internes depuis jQuery 1.8.0 , et remplacée par $._data(element, "events")laquelle peut être instable, selon le changelog officiel

Ceci est maintenant supprimé en 1.8, mais vous pouvez toujours accéder aux données d'événements à des fins de débogage via $ ._ data (élément, "events"). Notez que ce n'est pas une interface publique prise en charge; les structures de données réelles peuvent changer de manière incompétitive d'une version à l'autre.

MISE À JOUR:
Quand j'ai commencé à travailler, j'avais le même dilemme. Mais lors de la création d'une démo avec une interface graphique entièrement fonctionnelle (application d'une seule page) qui comprenait des onglets à ouverture dynamique (fermables également), un menu Accordéon (créé dynamiquement à partir de db), ils ont finalement compris qu'il était préférable d'utiliser USJ à fond.

De plus, l'utilisation d'USJ est que vous pouvez réduire votre application entière en un petit script (illisible). Montrez-leur également les scripts pour google.com / github.com (à titre d'exemple) et précisez que même le code est compressé, ce qui est toujours mieux, car le lecteur du site aura du mal à décoder les failles de sécurité. et utilisez-les pour lancer une attaque à part entière sur votre site (faites-leur peur), même si cela est peu probable.

MISE À JOUR 2 :
Btw, je ne savais pas que je faisais l'USJ jusqu'à ce que je vois cette question, donc merci d'une manière.


2

Les gestionnaires d'événements en ligne puent parce que:

  • Aucune délégation d'événement - ce qui est idéal lorsque vous souhaitez pouvoir extraire des éléments de manière dynamique d'une page à une autre sans avoir à la relier.

  • Vous avez lié le comportement aux balises HTML plutôt qu'aux attributs de classe / ID des balises HTML. Supposons que vous ayez une classe de "combo_box" dans votre application. Du coup, sur la moitié de vos anciennes pages, vous voulez une légère variation sur vos combos quand elles sont dans un conteneur différent. Lié à une classe, vous pouvez modifier ce comportement en fonction du contexte du conteneur, par exemple "#special_container .combo_box". Lié à l'intérieur du fichu HTML, vous pourriez vous retrouver à traquer chaque petite boîte de sélection avec une classe .combo_box dans n'importe quel nombre de pages pour modifier ces références de gestionnaire une à une plutôt que de modifier ou d'écrire quelques nouvelles lignes de code pour filtrer à partir d'un seul emplacement de fichier .

  • Si vous voulez plusieurs gestionnaires, vous devez les encapsuler dans une fonction, puis les lier inutilement à des fichiers HTML spécifiques. Est-ce maintenable?

  • Un point plus subtil est qu'il est beaucoup plus facile / plus facile à entretenir / flexible et robuste de gérer le comportement avec plus d'une mentalité de panneau de contrôle. En vous liant à partir d'un emplacement central, vous avez un endroit où vous pouvez obtenir un aperçu de tous les comportements qui se produisent sur la page en même temps, ce qui est pratique lorsque, par exemple, vous devez comprendre pourquoi certaines pages sont parfois exécutées dans un certain bug qui est difficile à comprendre mais pas les autres.

  • Ceci est du côté client. Nous avons plusieurs navigateurs qui interprètent tous la grande complexité à leur manière. Slop-it-all-together et laissez l'EDI régler cela pour vous les mentalités ne fonctionnent pas bien ici. Garder votre code serré, minimal, couplé et propre de manière lâche n'est pas à la mode, il est absolument essentiel afin d'établir un front-end maintenable facile à modifier et à mettre à jour et oui, c'est là que les $$$ entrent en supposant que votre gestionnaire a réellement la prévoyance .

  • Ce n'est plus le cas! @ # $ Ing 2002. Cet argument est aussi ancien que les tableaux que la mise en page. Dépassez-vous et commencez à faire confiance à un développeur expérimenté spécialisé côté client que vous avez vous-même embauché expressément parce que vous manquiez de son expertise (pas que je canalise la colère de l'expérience personnelle ou quoi que ce soit).

Et pour réfuter l'argument de votre patron, il n'est vraiment pas si difficile de trouver la classe ou l'ID utilisé dans la délégation d'événements ou la liaison de gestionnaire avec CTRL + F et un outil qui vous permet de visualiser tous les JS sur la page comme mon propre jquery personnel embarrassant / version de bookmarklet uniquement prototype, j'ai bricolé à la hâte quand la barre d'outils de développement Web a commencé à me craquer (maudit codage couleur). Ajoutez un signet à partir du lien sur la page js fiddle ou copiez le JS et créez le vôtre.

Un lien de violon JS qui expirera vraisemblablement à terme


+1 Enfin, quelqu'un a souligné les principaux inconvénients du JS en ligne. Va utiliser ces arguments dans le prochain débat avec mon patron.
V-Light le

@ V-Light Ont-ils fonctionné?
Erik Reppen

2
Nan! L'option 'ChangeYourOrganization' était la solution
V-Light

0

Un avantage majeur de votre technique suggérée est que vous ne devez lier qu'une fois le gestionnaire d'événements à un parent tel que "document" et ce gestionnaire sera en mesure d'attraper les événements provenant de tous les enfants qui ont satisfait le sélecteur donné tel que "button.anyclass" ". Économise de la mémoire et est maintenable de manière à ne nécessiter qu'une seule instance de modification et affecte tous les éléments.

En ce qui concerne le fait de ne pas être en mesure de reconnaître immédiatement la fonction liée, votre équipe pourrait simplement normaliser un moyen de déclarer ces fonctions probablement dans la partie inférieure de la page. Donc, vous savez tous où regarder, la convention de dénomination est également très importante.Les commentaires seraient extrêmement bénéfiques, mais assurez-vous qu'ils sont supprimés par le serveur avant de les servir de réponse au navigateur.

De plus, si vous souhaitez assurer l'obscurcissement et la minification du javascript à des fins de sécurité, votre technique le rendrait possible, contrairement à l'ancien style que votre équipe utilise toujours.


-2

La réponse évidente est que vous ne pouvez lier qu'une fonction à votre bouton avec l'attribut onclick, tandis que l'événement JQuery vous permet de lier plusieurs fonctions. Un problème courant avec l'événement onload: si votre document est composé de plusieurs fichiers, des collisions se produisent souvent.

Une autre solution qui pourrait vous satisfaire, vous et votre patron, est l'utilisation de la liaison de données, avec une bibliothèque comme Knockout ou Angular, qui garderait une trace des modifications sur votre vue et supprimerait le besoin d'une grande partie des gestionnaires d'événements.


1
concernant Knockout, Angular et autres frameworks JS pour les cool-kids ... malheureusement ce n'est pas une option. La raison est la même que ci-dessus ... c'est "trop" ou "trop ​​nouveau" ou "trop ​​cool" ou simplement "nous ne voulons pas apprendre quelque chose de nouveau, faisons-le à l'ancienne (stupide / stupide) .. . "
V-Light

@Niphra: De plus, vous ne pouvez lier une fonction qu'à un seul composant.
Bruno Schäpper

3
@ V-Light: "Vous pouvez changer votre organisation ou changer votre organisation." C'est peut-être intéressant pour vous: jamesshore.com/Change-Diary
Bruno Schäpper

Hé, mon entreprise reste avec Classic ASP car ASP.NET est "trop ​​nouveau", mais j'ai quand même réussi à pousser Knockout dans notre code. Essayez de voir quelles sont leurs préoccupations et voyez si vous pouvez apporter un changement.
DistantEcho

1
@Niphra "mon entreprise s'en tient à Classic ASP:" c'est ... terrifiant.
Michael Paulukonis
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.