Perché l'uso di JavaScript negli attributi HREF è scoraggiato?

Naviga le tue risposte
5

Disclaimer : sono venuto su Programmers.SE per fare questa domanda perché capisco che questo è il posto dove porre questo tipo di domanda, e non necessariamente lo stackoverflow. Se sbaglio, chiudi la domanda e indirizzami in un posto in cui potrei discuterne.

Ho notato che le persone hanno detto (nell'anno 2014) che non dovremmo usare JavaScript nell'attributo href di un tag di ancoraggio HTML. Quindi questa chiamata di funzione: 

<a id="expand-rail" href="javascript:callMyFunc()">Expand</a>

è sconsigliato e su questo è preferibile collegare un gestore di eventi all'evento onclick di questo tag di ancoraggio.

Perché?

Prenderò che questo stile di chiamate di funzioni JavaScript sia molto "90", ma quale linea guida di stile specifica discute questo e soppesa i pro e i contro di farlo è stato e lo raccomanda contro? Voglio dire, ci deve essere una lista di pro e contro, perché posso pensare ad alcuni professionisti, come l'accesso rapido a una funzione per un piccolo file HTML, o una facile leggibilità su un piccolo progetto. Sì, hai i lati negativi, come non separare la vista dal controller. Voglio sapere chi ha detto questo, perché è "generalmente compreso" e dove posso verificarlo.

Prendi qualcosa del genere: 

<span>
    Please <a id="page-reload" href="javascript:window.location.reload()">click here</a> to refresh
</span>

È abbondantemente ovvio ciò che sto cercando di fare. È davvero necessario separare la logica dalla vista in questo caso? Se sei d'accordo con me sul fatto che possiamo lasciare questa diapositiva, allora dove tracciamo la linea?

    
posta Michael Plautz 24.11.2014 - 21:01
fonte

1 risposta

8

Riguarda il principio di JavaScript non intrusivo. L'approccio moderno impone che ci sia una separazione di funzionalità dalla presentazione.

Detesto citare Wikipedia, ma fornire un articolo di Wikipedia su JavaScript discreto una lettura.

Su una nota personale ci sono tre cose su JavaScript non intrusivo che mi piacciono molto:

  1. Separazione dei dubbi: il mio JavaScript è completamente separato dal mio codice HTML. È in file separati e mi incoraggia a scrivere codice JavaScript pulito. Con i tag incorporati tendo a scaricare pile di rifiuti nei tag dello script. Qui sto scrivendo JavaScript molto stretto, modulare, riutilizzabile e manutenibile.

  2. Degrado aggraziato: quando si utilizza JavaScript in linea in questo modo, si presume che il client abbia JavaScript abilitato. Cosa succede se il client non ha JavaScript abilitato? Il tuo sito fallisce del tutto? Se scrivi JavaScript non invadente, di solito stai creando un sito funzionale con HTML, quindi migliora l'esperienza con JavaScript. Senza JavaScript l'esperienza utente del tuo sito è degradata, ma comunque funzionale.

  3. Chiedi invece di assumere - Questo si collega a ciò di cui stavo parlando con il punto numero due. Quello che sei incoraggiato a fare è costruire un'esperienza di base usando HTML + CSS e poi migliorarlo con JavaScript. In molti dei miei siti (sono uno sviluppatore .NET MVC) utilizzo l'interfaccia utente jQuery per caricare pagine parziali per moduli di input. Con JavaScript non invadente il mio sito funziona perfettamente con carichi di pagina completi, e quindi è arricchito con richieste AJAX che mi consentono di creare finestre di dialogo modali. Nel mio codice server in realtà impongo se restituire un View() (layout completo) o PartialView() (HTML semplice) in base al fatto che la richiesta sia o meno una richiesta AJAX.

Diamo un'occhiata al tuo primo esempio. In base al contesto, posso presumere di avere una sezione della pagina nascosta e il collegamento chiama una funzione per espandere quella sezione della pagina. Si potrebbe raggiungere questo in due modi. Potrebbe essere nascondere la sezione con il contenuto e quindi visualizzarla quando si fa clic sul collegamento (attivazione di CSS) oppure si potrebbe effettuare una chiamata al server per caricare i dati e visualizzarli sulla pagina ( Richiesta AJAX). Nella sua forma attuale il contenuto visualizzato dai metodi call è ora inaccessibile al tuo cliente. Puoi refactoring della tua pagina per visualizzare tutto il contenuto della pagina al momento del caricamento se JavaScript non è disponibile e poi nasconderlo quando il DOM è pronto, oppure potresti avere il link diretto a una pagina intera con il contenuto, quindi modificare tale comportamento in un AJAX richiesta.

    
risposta data 24.11.2014 - 21:57
fonte

Leggi altre domande sui tag

Esiste una guida per lo sviluppo del software per progettare hotkey efficienti per le azioni? Come gestire gli interi di stato dal database nel codice orientato agli oggetti?