Accoppiamento stretto tra Javascript, HTML e CSS: un approccio più moderno?

Non c'è modo di evitarlo. Sono accoppiati perché interagiscono l'uno con l'altro. Se il tuo javascript intende fare qualsiasi tipo di manipolazione DOM, allora ha bisogno di un modo per fare riferimento al DOM.

Ci sono varie convenzioni per questo.

L'API DOM di livello 2 fornisce i metodi getElementById, getElementByTagName e getElementsByName. Fino ad oggi questi sono i cavalli da lavoro di ogni tipo di attraversamento DOM. Tutti gli altri selettori jQuery più fantasiosi si risolvono in una combinazione di questi attraversamenti finali, e / o dritti di ogni nodo DOM (questo era il modo per fare getByClassName).

Non ci sono altri collegamenti. Javascript ha bisogno di sapere cosa fare e dove. In genere, se un elemento ha un ID o una classe che è rilevante solo nello scripting, molte persone lo prefissano con js- o qualche altra bandiera ovvia.

Un'altra nuova convenzione è la selezione degli attributi dei dati.

<ul data-myapp-sortable="true">

jQuery('[data-myapp-sortable]').makeSortable();

L'attributo dei dati viene generalmente utilizzato per scopi di scripting e la selezione dell'uso ha senso. Lo svantaggio è che questo è più lento rispetto all'utilizzo di getElementById ().

Un altro approccio è quello usato da angularJS, che crea un modello di vista. In questa convenzione ogni tipo di funzionalità di scripting è specificata da attributi appositamente designati come ng-disabled ng-href e molti altri. Non aggiungi selettori nel tuo javascript. Il documento HTML diventa l'autorità principale su ciò che è scritto da script e come, e il javascript funziona in modo astratto. È un buon approccio, ma ovviamente con una curva di apprendimento più alta rispetto ai metodi precedenti. E ancora, le prestazioni devono essere considerate.

Ma non pensare mai che tu possa scrivere HTML interattivo e javascript, e in qualche modo avere entrambe le parti non sanno dell'altro. È più su come puoi limitare i riferimenti alle dipendenze.

Se sei disposto a rinunciare all'interattività che ottieni, puoi evitare completamente Javascript. Framework come ASP.NET MVC sono molto utili per pubblicare pagine che contengono solo HTML, CSS e un pulsante SUBMIT.

OK. Forse è un po 'estremo.

Il disaccoppiamento in un'applicazione Web avviene già a molti livelli. Le applicazioni REST consentono di definire l'applicazione in termini di "risorse Web" associate a un URL. Visualizza i modelli consente di presentare i dati all'interfaccia utente che è disaccoppiata dal modello di dominio, ma ha la forma che è necessario per visualizzarli correttamente. I livelli di servizio consentono di scambiare una UI con un'altra e così via.

Storicamente, c'è sempre stato un compromesso tra interattività e accoppiamento. Più interattiva è la tua pagina web, più strettamente l'applicazione sarà. Ma la logica di interattività nella pagina web è limitata alla stessa pagina web; qualsiasi accoppiamento con il server si verificherà tramite POST o AJAX. Quindi non sono sicuro che dovresti preoccuparti eccessivamente dell'accoppiamento a livello Javascript, se non prestare attenzione al modo in cui i pacchetti di dati vengono passati tra il browser e il server.

L'approccio più "moderno" (ovvero il sapore della settimana) è probabilmente applicazioni SPA .

Martin Fowler descrive un approccio a questo come DOM segregato , in cui separa il tuo DOM JavaScript dal tuo JavaScript logico di pagina .

Application Logic <----> DOM Manipulation <----> DOM / HTML

No, l'uso di selettori di classe, elemento e ID non deve essere evitato dal lato client. La sintassi viene utilizzata perché i selettori CSS sono linguaggi di dominio molto maturi e ben consolidati e hanno un design comune rende molto più facile condividere un modello logico comune di una pagina tra programma e design, il che è molto, molto bello.

Sebbene sia possibile utilizzare male questa sintassi e creare un'applicazione terribile e non mantenibile, ciò è possibile indipendentemente dalla lingua o dal set di strumenti.

Qualcuno deve creare un'interfaccia di gestione dei percorsi jQuery per un indiretto e un livello di cache sul dom.

pathMgr.register(name,selector [,isDynamic=false]);
pathMgr.get(name [,refresh]);

Poi,

String.prototype.reg([isDynamic=false]);
String.prototype.get(name [,refresh]);

// at init....
var pathMgr=new PathMgr();
'sidebar-links #sidebar a'.reg();// new registery of selector '#sidebar a' under name 'sidebar-links'
// more, more


// in code
'sidebar-links'.get().css(etc...);
//or
'sidebar-links'.addStyleRule({});