Come convinco il mio capo (e altri sviluppatori) a utilizzare / considerare JavaScript non intrusivo

21

Sono piuttosto nuovo nel nostro team di sviluppatori.

Ho bisogno di alcuni argomenti forti e / o esempi di "trappola", quindi il mio capo capirà finalmente i vantaggi di JavaScript non intrusivo, in modo che lui e il resto della squadra smettano di fare cose del genere:

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

e

<script type="text/javascript">

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

Ho suggerito di utilizzare uno schema piuttosto comune:

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

e

<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();

});

Il motivo per cui il mio capo (e altri) non vogliono usare questo approccio è che l'Event-Inspection in FireBug (o Chrome Dev Tools) non è più semplice, ad es. con

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

può immediatamente vedere quale funzione viene eseguita su change-event e saltare direttamente ad essa in un enorme file JS pieno di spaghetti code .

Nel caso di JavaScript non invadente l'unica cosa che vedrebbe è:

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

e non ha idea se alcuni eventi, se ce ne sono, sono stati associati a questo elemento e quale funzione verrà attivata.

Stavo cercando una soluzione e l'ho trovata:

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

ma, questo "approccio" ha fatto sì che prendesse "troppo tempo ..." per scoprire quale funzione si attiva su quale evento, quindi mi è stato detto di smettere di associare eventi del genere.

Ti sto chiedendo alcuni esempi o forti vantaggi o altri tipi di suggerimenti per "Perché dovremmo usare UJS"

UPDATE: il suggerimento di "cambiare lavoro" non è una soluzione ideale.

UPDATE 2: Ok, Non ho solo suggerito di utilizzare l'associazione eventi jQuery, L'ho fatto . Dopo aver scritto tutto Event-Delegation, il Boss è venuto da me e mi ha chiesto, perché sto facendo delegazione di eventi con approccio e approccio diversi che non conosce

Ho menzionato alcuni ovvi benefici, come: - Ci sono 15 campi di input e tutti quindi hanno un evento onchange (non solo, alcuni di loro hanno anche onkeyup ) Quindi è più pragmatico scrivere questo tipo di evento -delegazione per TUTTI i campi di input, invece di farlo 15 volte, specialmente se tutto il codice HTML sarà reso con PHP echo - > echo '... <input type="text" id="someid" ... />...'

    
posta V-Light 20.02.2013 - 11:58
fonte

5 risposte

49
  1. Interrompi l'utilizzo di parole chiave e prova invece a creare argomenti validi. Anche la pagina di Wikipedia per Non invadente JavaScript dice che il termine non è formalmente definito. Può essere un termine generico per un certo numero di buone idee, ma se suona come una semplice moda o moda, il tuo capo e colleghi non presteranno molta attenzione. Peggio ancora, se continui a parlare di qualcosa che considerano inutile, potrebbero iniziare a scartare idee completamente indipendenti che difendi.

  2. Scopri perché tu pensi che le idee JavaScript discrete siano importanti. È perché hai letto che sono considerate best practice? Hai incontrato problemi che puoi attribuire a non seguire queste idee? Quanto l'adozione di queste idee avrà un impatto sui profitti dell'azienda?

  3. Entra nella testa del tuo capo. Perché fa le cose come fa lui, e perché ha rifiutato le tue modifiche? Probabilmente non è stupido, ed è probabilmente più esperto di te, quindi probabilmente ha delle buone ragioni per fare le cose a modo suo. Hai già fatto cenno ad alcuni di loro: segui quel filo fino alla fine. Quindi scopri se e come i tuoi suggerimenti miglioreranno le cose di cui è più interessato.

  4. Suggerimento 1: ai manager piace il denaro. Quanto più direttamente puoi legare i tuoi suggerimenti a un reddito maggiore o a una spesa ridotta, tanto maggiore sarà l'impatto del tuo argomento. Suggerimento 2: il tempo è denaro. Suggerimento 3: Di per sé, l'attrazione estetica del codice non guadagna. L'opposto, infatti, richiede tempo per rendere il codice un aspetto gradevole. Il brutto codice che funziona bene va bene con la maggior parte dei manager.

  5. Non limitarti a parlarne, fallo . Se sei abbastanza fortunato da farti venire un piccolo progetto autonomo, chiedi al tuo manager se puoi farlo usando lo stile "UJS" come una sorta di dimostrazione. Quando sei pronto, tieni una recensione del codice in cui puoi spiegare come funziona e perché pensi che sia migliore dello stile attuale.

  6. L'idealismo è ottimo, ma non lasciarlo intralciare. È più importante essere visti come qualcuno che fa le cose che come un dilettante che si lamenta dello stile di codifica rozza . Questo è particolarmente vero se sei il nuovo tipo. Se non riesci a ottenere la trazione con UJS ora, fai un buon lavoro e crea lentamente un caso per le modifiche che desideri apportare man mano che guadagni credibilità.

  7. Leggi Passa: come cambiare le cose quando il cambiamento è difficile . Ti darà molte più buone idee su come costruire efficacemente il tuo caso.

risposta data 20.02.2013 - 15:30
fonte
8

Quello che puoi fare è dare loro una demo di debug di un html USJ usando gli strumenti FireQuery così come Chrome Query .

FireQuery è un'estensione firebug e fa un buon lavoro. Per quanto riguarda Chrome Query, non posso garantire per quanto è buono, ma è sicuramente usato da alcuni degli sviluppatori ( un post su stackoverflow ).

Sappi anche che la funzione .data è stata rimossa per restituire i dati degli eventi interni poiché jQuery 1.8.0 , e sostituito con $._data(element, "events") che può essere instabile, come da changelog ufficiale

This is now removed in 1.8, but you can still get to the events data for debugging purposes via $._data(element, "events"). Note that this is not a supported public interface; the actual data structures may change incompatibly from version to version.

UPDATE:
Quando ho iniziato a lavorare ho avuto lo stesso dilemma. Ma alla creazione di una demo con GUI completamente funzionale (applicazione a singola pagina) che includeva schede dinamiche (anche chiudibili), menu Accordion (creato dinamicamente da db), hanno finalmente capito che è meglio usare USJ fino in fondo.

Anche il vantaggio dell'uso di USJ è che puoi ridimensionare l'intera applicazione in un piccolo script (illeggibile). Mostra loro anche gli script per google.com / github.com (ad esempio) e fai notare che anche loro stanno avendo il codice compresso, che è sempre meglio, poiché il visualizzatore del sito avrà difficoltà a decodificare i difetti di sicurezza e utilizzali per iniziare un attacco a tutti gli effetti sul tuo sito (spaventali), anche se improbabile.

UPDATE 2 :
A proposito, non sapevo che stavo facendo USJ fino a quando ho visto questa domanda, quindi grazie in un modo.

    
risposta data 20.02.2013 - 15:08
fonte
2

I gestori di eventi inline possono essere presenti perché:

  • Nessuna delega degli eventi, che è ottima quando vuoi poter eseguire il ripping degli elementi dentro e fuori una pagina in modo dinamico senza dover eseguire nuovamente il bind.

  • Hai associato il comportamento ai tag HTML anziché agli attributi di classe / ID dei tag HTML. Supponiamo che tu abbia una classe di "combo_box" in tutta la tua app. All'improvviso, a metà delle tue vecchie pagine, vuoi una leggera variazione sulle tue caselle combinate quando sono in un contenitore diverso. Legato a una classe, puoi modificare tale comportamento in base al contesto del contenitore, ad es. %codice%. Legato al maledetto codice HTML potresti ritrovarti a rintracciare ogni piccola casella di selezione con una classe .combo_box in qualsiasi numero di pagine per modificare quei riferimenti di gestore uno per uno invece di modificare o scrivere un paio di nuove righe di codice per filtrare da un singolo percorso di file .

  • Se vuoi più gestori, li hai racchiusi in una funzione e quindi li leghi inutilmente a specifici file HTML. Quanto è mantenibile?

  • Un punto più sottile è che è molto più facile / più mantenibile / flessibile e robusto per gestire il comportamento con più mentalità di un pannello di controllo. Legandosi da una posizione centrale, hai un luogo in cui puoi avere una panoramica di tutti i comportamenti che si verificano nella pagina tutti allo stesso tempo, il che è utile quando, ad esempio, devi capire perché alcune pagine eseguono occasionalmente in un certo bug che è difficile da capire ma non da altri.

  • Questo è il lato client. Disponiamo di più browser che interpretano tutte le complesse complessità nei loro stessi modi per renderne conto. Lascia perdere tutto e lascia che l'IDE lo risolva per te le mentalità non funzionano bene qui. Mantenere il tuo codice stretto, minimale, liberamente accoppiato e pulito non è di moda, è assolutamente essenziale per stabilire un front end gestibile che sia facile da modificare e aggiornare e sì, è qui che arrivano i discount assumendo che il tuo manager abbia in previsione .

  • Non lo è più! # # $ ing 2002. Questo argomento è vecchio come le tabelle del layout. Passa oltre e inizia a fidarti di un dev specializzato specializzato lato client che tu stesso hai assunto espressamente perché ti mancava la loro esperienza (non che io stia canalizzando qualsiasi rabbia per esperienza personale o altro).

E per confutare l'argomento del tuo capo, non è davvero così difficile rintracciare quale classe o ID viene utilizzato nella delega degli eventi o nel binding del gestore con CTRL + F e uno strumento che ti consente di visualizzare tutto il JS sulla pagina come il mio ho imbarazzato in modo imbarazzante la versione di bookmarklet jquery / prototipo-only in cui mi sono affrettato a frugare insieme quando la barra degli strumenti di web dev ha iniziato a sgridarmi (dannata codifica a colori). Aggiungi un segnalibro dal link alla pagina js fiddle o copia il JS e creane uno tuo.

Un link di violino JS che presumibilmente scadrà alla fine

    
risposta data 24.02.2013 - 06:59
fonte
0

Uno dei principali vantaggi della tua tecnica suggerita è che devi legare una volta il gestore di eventi a un genitore come "documento" e questo gestore sarà in grado di intercettare gli eventi provenienti da tutti i bambini che hanno soddisfatto il selettore dato come " button.anyclass". Salva la memoria e manutenibile in modo tale da richiedere solo un'istanza di modifica e influisce su tutti gli elementi.

Per quanto riguarda il non poter riconoscere immediatamente la funzione associata, la tua squadra potrebbe semplicemente standardizzare un modo per dichiarare tali funzioni probabilmente nella parte più bassa della pagina. Quindi tutti sapete dove guardare, anche le convenzioni sui nomi sono molto importanti. I commenti sarebbero estremamente vantaggiosi, ma assicuratevi che venga rimosso dal server prima di servirlo come risposta al browser.

Inoltre, se vuoi fornire l'offuscamento e la minimizzazione di javascript per motivi di sicurezza, la tua tecnica lo renderebbe possibile, a differenza del vecchio stile che il tuo team sta ancora utilizzando.

    
risposta data 20.02.2013 - 15:07
fonte
-2

La risposta ovvia è che puoi associare una sola funzione al tuo pulsante con l'attributo onclick, mentre l'evento JQuery ti consente di associare più funzioni. Un problema comune con l'evento onload: se il documento è composto da più di un file, spesso si verificano collisioni.

Un'altra soluzione che potrebbe soddisfare sia te che il tuo capo è l'uso del data-binding, con una libreria come Knockout o Angular, che tiene traccia delle modifiche sulla tua vista e sopprime la necessità di gran parte dei gestori di eventi .

    
risposta data 20.02.2013 - 12:21
fonte

Leggi altre domande sui tag