Quali sono gli svantaggi dei pattern di script non invadenti nelle applicazioni web?

Question

Quali sono gli svantaggi dei pattern di script non invadenti nelle applicazioni web?

#1 da (7 voti)
#2 da (7 voti)
#3 da (2 voti)

6

Prima di tutto, c'è un nome per questo come un modello di design in buona fede? Al momento mi riferisco solo a questo come "non invadente javascript". Ecco un breve esempio di ciò di cui sto parlando:

1.) Utilizza gli attributi HTML5 data- * per definire i valori che verranno utilizzati negli script UX. Qualcosa del genere:

<input type="date" data-app-calendar="datepicker" />

2.) Utilizzare lo script per inizializzare i comportamenti di javscript utilizzando questi attributi di dati

(function($) {
    $.app = $.app || {};
    $.app.obtruders = $.app.obtruders || {};
    $.app.obtrude = function(selector) {
        var obtruder, obtruders = $.app.obtruders;
        for (obtruder in obtruders) {
            if (!obtruders.hasOwnProperty(obtruder)) continue;
            if (typeof obtruders[obtruder] === 'function')
                obtruders[obtruder].apply(this, 
                    Array.prototype.slice.call(arguments, 0, 1) || document);
        }
    };

    $.extend($.app.obtruders, {
        calendar: function (selector) {
            $(selector).find('[data-app-calendar=datepicker]').datepicker();
        }
    });

    $(function () {
        $.app.obtrude(document);
    });

})(jQuery);

Ciò che si finisce con, imo, è il markup di presentazione che è separato molto chiaramente dagli script comportamentali. L'esempio sopra è semplice, ma puoi estenderlo a UX scriptable più complesso come google maps (sto lavorando su questo al momento). Puoi addirittura aggiungere nuovi "elementi di disturbo" in file javascript separati estendendo il letterale dell'oggetto $ .app.obtruders.

Prima di iniziare a utilizzare questo modello più ampiamente nella nostra app, volevo scegliere cervelli per opinioni e cercare di ottenere idee su alcuni potenziali svantaggi di un approccio come questo. Cosa ti piace di questo modello? Cosa non ti piace? Perché sceglieresti di non usarlo?

html5 web-development javascript design-patterns

posta danludwig 11.12.2011 - 18:11

fonte

3 risposte

7

Ci sono due principali svantaggi.

1. Il primo è stato già menzionato da Michael Borgwardt : il fatto che sia difficile scoprire cosa rende un elemento della pagina che agisce come fa. Ad esempio:

<div id="TopActions">
    <a id="ToggleTopPanel" onclick="javascript:ToggleTopPanel();">Expand</a>
</div>

è semplice: quando leggo questo codice, ne sono assolutamente sicuro:

Che quando faccio clic sul link "Espandi", farà qualcosa che è specificato nel metodo ToggleTopPanel() scritto da qualche parte. Se voglio saperne di più, devo solo cercare il metodo.
Che la pagina non funzionerà con JavaScript disabilitato.

Se, d'altra parte, ho letto:

<div id="TopActions">
    <a id="ToggleTopPanel" href="?topPanel=expanded">Show</a>
</div>

Non ho idea di cosa succederà se JavaScript è abilitato (e anche se il comportamento è diverso dalla versione non JavaScript). Inoltre, non c'è nulla che io possa fare per trovarlo senza sforzo. Se ci sono migliaia di righe di codice, dove cercare? Potrebbe essere:

$('#ToggleTopPanel').click(function() {
    // The magic happens here.
});

o forse:

$('#TopActions a').click(UI.Top.Activated($(this)));

o qualcosa di completamente diverso. O ho un browser con un profiler e so come usarlo, o, beh ...

2. La seconda ragione è che JavaScript non invadente non è il modo più semplice per eseguire il lavoro. Se è ovviamente una scelta per le applicazioni web di grandi dimensioni, è eccessivo per un piccolo sito personale visitato da una persona a settimana (esclusa la persona che lo ha creato).

Se l'accordo è di fare qualcosa di piccolo, e di renderlo veloce ed economico, non preoccuparti di JavaScript non invadente.
Se l'accordo è di aggiungere alcuni fastidiosi effetti visivi come quei fiocchi di neve che volano su tutta la pagina o le api che cercano il cursore o l'annuncio che salta davanti alla pagina che l'utente stava per leggere, non fastidio con JavaScript non invadente.

risposta data 11.12.2011 - 22:28

fonte

2

Questo è chiamato iniettare funzionalità in un'applicazione. È un modello "comune".

Personalmente uso un modello simile

["feature1", "feature2", ...].forEach(function(feature) {
  var elems = $("." + feature);
  // this document has an element that uses the feature
  if (elems.length) {
    loadFeatureByAjax(document, feature);
  }
});

Quindi ogni funzione sa come inserirsi nel selettore

var Feature = function (selector) {
    $(selector).find('.featureName').datepicker();
}

Nota che usiamo le classi piuttosto che gli attributi data- perché i selettori CSS sono lenti e vanno evitati.

L'unica altra obiezione è che la tua particolare implementazione sembra prolissa, ma potrebbe essere solo il tuo stile di codifica.

risposta data 11.12.2011 - 19:44

fonte

Leggi altre domande sui tag html5 web-development javascript design-patterns

Strumenti e pratiche indispensabili per una start-up agile [chiusa] Vari concetti di programmazione (da un punto di vista Python)

score 7 · Accepted Answer

È un modello comune, "javascript non invadente" è un nome diffuso per esso, ed è generalmente considerato superiore alle alternative (mettendo le chiamate JavaScript direttamente in link e gestori di eventi).

L'unico svantaggio che posso pensare è che rende il comportamento più difficile da scoprire. Quando guardi l'HTML, non hai idea di cosa sia il comportamento dinamico o dove sia definito. Questo può essere mitigato dalle convenzioni o dal supporto IDE.