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').clickmais, 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 source
js-this-class-do-somethingclasse, vous pouvez donc facilement CTRL + F pour cela dans le code.Réponses:
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.
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?
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.
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.
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.
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é.
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.
la source
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 officielMISE À 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.
la source
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
la source
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.
la source
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.
la source