2013-07-30 13 views
10

Se sto creando una libreria JavaScript per uso generale, come dovrei gestire il supporto RequireJS?Quando si progetta una libreria JS, è necessario renderlo RequireJS/AMD compatibile o no?

Per quanto posso dire, rendere il codice compatibile con RequireJS più o meno lo rende impossibile da usare senza RequireJS. Quindi perché dovrei farlo?

  • In che modo le persone senza richiedono utilizzare questo codice?

  • C'è un modo per supportare entrambi senza biforcazione/ramificazione? Devo fornire il codice shim?

  • Ho capito bene?

+1

Sede [supportano entrambi CommonJS e AMD] (http://stackoverflow.com/questions/ 13673346/support-both-commonjs-and-amd) e anche il codice sorgente di molte librerie comuni come jQuery e Knockout che supportano AMD e non AMD – explunit

+0

UMD sembra che cerchi di risolvere ogni caso aggiungendo molta complessità . Esiste una best practice più semplice e flessibile? –

risposta

23

Se siete solo che fare con il browser (non node.js), è solo una manciata di righe per rendere la libreria di supporto AMD e non AMD.

Per esempio, here is the file from jQuery that does it, di cui tutti, ma quattro sono commenti:

// Execute the factory to produce jQuery 
var jQuery = factory(window); 

// Register as a named AMD module, since jQuery can be concatenated with other 
// files that may use define, but not via a proper concatenation script that 
// understands anonymous AMD modules. A named AMD is safest and most robust 
// way to register. Lowercase jquery is used because AMD module names are 
// derived from file names, and jQuery is normally delivered in a lowercase 
// file name. Do this after creating the global so that if an AMD module wants 
// to call noConflict to hide this version of jQuery, it will work. 
if (typeof define === "function" && define.amd) { 
    define("jquery", [], function() { 
     return jQuery; 
    }); 
} 

E un frammento molto simile da Knockout può essere trovato here:

} else if (typeof define === 'function' && define['amd']) { 
    // [2] AMD anonymous module 
    define(['exports'], factory); 
} 

Nota che jQuery adotta l'approccio named module mentre knockout usa un modulo anonimo. jQuery lascia anche $ e jQuery nel namespace globale, even when AMD is detected, mentre Knockout (e probabilmente molti altri) fanno non metti qualcosa nello spazio dei nomi globale quando AMD ha rilevato. Ci sono pro e contro per ogni approccio, come illustrato da queste domande:

+0

Ottimo! Quindi questo approccio viola qualsiasi regola sporcando lo spazio dei nomi globale con la sua sporca variabile jQuery? –

+0

@ MimsH.Wright ha aggiunto alcune note su questo sopra nella risposta – explunit

+1

Si noti che la posizione della funzionalità di esportazione amd è stata spostata in un nuovo file in [src/exports/amd.js] (https://github.com/jquery /jquery/blob/master/src/exports/amd.js) – turtlemonvh

Problemi correlati