Stretto accoppiamento tra Javascript, HTML e CSS: un approccio più moderno?

È molto comune vedere Javascript associato a determinati selettori per trovare elementi, archiviare dati e ascoltare eventi. È anche comune vedere questi stessi selettori usati per lo styling.

jQuery (e il suo motore di selezione Sizzle) supportano e promuovono facendo riferimento a elementi con sintassi di tipo CSS. Come tale, questa tecnica è particolarmente difficile da "disimparare" (o refactoring) quando si costruiscono progetti.

Ho capito che questo è il risultato della storia dello sviluppo di HTML e Javascript e che i browser sono stati creati per consumare / analizzare / rendere in modo efficiente questo tipo di accoppiamento. Ma man mano che i siti Web diventano sempre più complessi, questa realtà può presentare difficoltà nell'organizzazione e nel mantenimento di questi livelli separati.

La mia domanda è: può e dovrebbe essere evitato nei siti Web moderni?

Se sono nuovo nello sviluppo del front-end e desidero imparare le cose "nel modo giusto", vale la pena imparare a separare ed evitare tali dipendenze dall'inizio? Questo significa evitare jQuery a favore di una libreria che promuove una struttura più disaccoppiata?

Non c'è modo di evitarlo. Sono accoppiati perché interagiscono tra loro. Se il tuo javascript intende eseguire 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. Ad oggi questi sono i cavalli di battaglia di qualsiasi tipo di attraversamento del DOM. Tutti gli altri selettori jQuery più elaborati si risolvono in una combinazione di questi eventualmente, e / o attraversando direttamente ogni nodo DOM (questo era il modo di fare getByClassName).

Non c'è altra scorciatoia. Javascript deve sapere cosa fare e dove. In genere, se un elemento ha un id o una classe che è rilevante solo nello scripting, molte persone lo anteporranno con js-o con qualche altra bandiera evidente.

Un'altra convenzione più recente è la selezione dell'attributo di dati.

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

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

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

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

Ma non pensare mai che puoi scrivere HTML interattivo e javascript e in qualche modo entrambe le parti non conoscono l'altra. Si tratta di come limitare i riferimenti alle dipendenze.

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

OK. Forse è un po 'estremo.

Il disaccoppiamento in un'applicazione Web si verifica già a molti livelli. Le applicazioni REST ti consentono di definire la tua applicazione in termini di "risorse web" associate a un URL. Visualizza modelli consente di presentare all'interfaccia utente i dati che sono disaccoppiati dal modello di dominio, ma ha la forma necessaria per visualizzarli correttamente. I livelli di servizio consentono di scambiare un'interfaccia utente con un'altra e così via.

Storicamente, c'è sempre stato un compromesso tra interattività e accoppiamento. Quanto più interattiva è la tua pagina web, tanto più strettamente legata all'applicazione sarà. Ma la logica di interattività nella pagina Web è limitata alla pagina Web stessa; qualsiasi accoppiamento con il server avverrà tramite POST o AJAX. Quindi non sono sicuro che dovresti preoccuparti eccessivamente dell'accoppiamento a livello Javascript, oltre a 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 l' applicazione SPA .

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

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

No, l'uso di selettori di classe, elemento e ID sul lato client non dovrebbe essere evitato. La sintassi viene utilizzata perché i selettori CSS sono un linguaggio di dominio molto maturo e ben consolidato e avere un design comune rende molto più facile condividere un modello logico comune di una pagina tra programma e design, il che è una cosa molto, molto buona.

Sebbene sia possibile utilizzare in modo improprio 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 del gestore percorsi jQuery per un livello indiretto e cache al dom.

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

Poi,

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

Così,

// 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({});