Chciałbym używać requireJS i używam jQuery. Nie chcę używać połączonej wersji requireJS i jQuery, ponieważ nie używam najnowszej wersji jQuery. Jaki jest dla mnie najlepszy sposób pracy z requireJS?
Co powstrzymuje Cię przed korzystaniem z najnowszego jQuery?
Incognito
Używam jQuery 1.3.8. Ta wersja działa nieco inaczej niż 1.4.X. Zamawiam na najnowszy jQuery, muszę trochę zaktualizować kod i na razie nie mam na to czasu. Ponadto uważam, że łączenie pakietów nie jest właściwe.
Naor,
Odpowiedź poniżej jest dobra ... dlaczego nie oznaczyłeś jej jako poprawną?
Więzień ZERO
@Prisoner ZERO: Szczerze, nie udało mi się tego przetestować. Ostatecznie użyłem modułu ładującego skrypt Ajax firmy Microsoft. Dzięki za przypomnienie mi o zaznaczeniu tej odpowiedzi. Jeśli powiedziałeś, że to świetne - wierzę ci.
Naor
Zauważyłem również, że requirejs jest trudny do użycia z innymi bibliotekami i odwrotnie. Dlatego stworzyłem bibliotekę, która jest dużo łatwiejsza w użyciu i jest testowana z angularem. Na dole znajduje się aplikacja demonstracyjna: gngeorgiev.github.io/Modulerr.js Możesz także połączyć wszystkie skrypty w jeden bez zależności od Modulerr.js
Georgi-it.
Odpowiedzi:
130
To też jest moje dokładne pytanie! Muszę też używać starszej biblioteki jQuery, ale także bardziej „tradycyjnych” bibliotek javascript. Jaka jest najlepsza technika, aby to zrobić? (Jeśli nie masz nic przeciwko, mogę zredagować twoje pytanie, aby było bardziej ogólne). Oto, czego się nauczyłem.
Dostępny jest moduł jquery,, i jest to obiekt jQuery. To jest bezpieczne:
// My module depends on jQuery but what if $ was overwritten?
define(["jquery"], function($) {
// $ is guaranteed to be jQuery now */
})
jQuery jest już załadowany przed jakimkolwiek require()lub define()rzeczami. Wszystkie moduły mają gwarancję, że jQuery jest gotowe. Nie potrzebujesz nawet require/order.jswtyczki, ponieważ jQuery został w zasadzie na stałe zakodowany do załadowania jako pierwszy.
Dla mnie numer 2 nie jest zbyt pomocny. Większość prawdziwych aplikacji ma wiele.js plików, które muszą być ładowane we właściwej kolejności - smutne, ale prawdziwe. Gdy potrzebujesz Sammy lub Underscore.js, połączony plik RequireJS + jQuery nie pomaga.
Moim rozwiązaniem jest napisanie prostych opakowań RequireJS, które ładują moje tradycyjne skrypty za pomocą wtyczki „order”.
Przykład
Załóżmy, że moja aplikacja ma te składniki (według zależności).
Moja aplikacja, świetna aplikacja
greatapp zależy od niestandardowego jquery (muszę użyć starej wersji)
greatapp zależy od my_sammy (SammyJS plus wszystkie jego wtyczki, których muszę używać). Te muszą być w porządku
my_sammy zależy od jquery (SammyJS to wtyczka jQuery)
my_sammy zależy od sammy.js
my_sammy zależy od sammy.json.js
my_sammy zależy od sammy.storage.js
my_sammy zależy od sammy.mustache.js
Moim zdaniem wszystko powyżej, co się kończy, .jsjest „tradycyjnym” skryptem. Wszystko bez .jsjest wtyczką RequireJS. Klucz jest taki: rzeczy na wysokim poziomie (greatapp, my_sammy) to moduły, a na głębszych poziomach wracają do tradycyjnych .jsplików.
Uruchamianie
Wszystko zaczyna się od programu uruchamiającego, który mówi firmie RequireJS, jak zacząć.
W js/boot.jskładę tylko config i jak uruchomić aplikację.
require( // The "paths" maps module names to actual places to fetch the file.// I made modules with simple names (jquery, sammy) that will do the hard work.
{ paths: { jquery: "require_jquery"
, sammy : "require_sammy"
}
}
// Next is the root module to run, which depends on everything else.
, [ "greatapp" ]
// Finally, start my app in whatever way it uses.
, function(greatapp) { greatapp.start(); }
);
Główna aplikacja
W greatapp.jsmam normalnie wyglądający moduł.
define(["jquery", "sammy"], function($, Sammy) {
// At this point, jQuery and SammyJS are loaded successfully.// By depending on "jquery", the "require_jquery.js" file will run; same for sammy.// Those require_* files also pass jQuery and Sammy to here, so no more globals!var start = function() {
$(document).ready(function() {
$("body").html("Hello world!");
})
}
return {"start":start};
}
Opakowania modułów RequireJS wokół tradycyjnych plików
require_jquery.js:
define(["/custom/path/to/my/jquery.js?1.4.2"], function() {
// Raw jQuery does notreturn anything, so return it explicitly here.
return jQuery;
})
require_sammy.js:
// These must be in order, so use the "order!" plugin.
define([ "order!jquery"
, "order!/path/to/custom/sammy/sammy-0.6.2-min.js"
, "order!/path/to/custom/sammy/plugins/sammy.json-0.6.2-min.js"
, "order!/path/to/custom/sammy/plugins/sammy.storage-0.6.2-min.js"
, "order!/path/to/custom/sammy/plugins/sammy.mustache-0.6.2-min.js"
]
, function($) {
// Raw sammy does not return anything, so return it explicitly here.return $.sammy;
}
);
Dobra robota nad tą odpowiedzią ... mam nadzieję, że pytający to zaznaczy!
Więzień ZERO
tworzysz moduł require_jquery w zależności od aktualnego pliku jquery, ale czy jquery nie pozostaje globalny? rzeczywisty plik jquery 1.4.2 ładowany ze ścieżki niestandardowej nie jest modułem require.js? czy też zawinąłeś wymaganie wokół tego pliku?
Sander,
3
Chciałbym zauważyć, że z najnowszą wersją jQuery (1.7) obsługuje już moduły, więc wystarczy, że będziesz go normalnie wymagać i będzie działać.
MikeMurko
1
Czy ktoś może zaktualizować tę odpowiedź, aby odzwierciedlić, jak to zrobić requireJS 2 (z podkładką) + jQuery 1.7+, który obsługuje AMD?
Henry,
1
Chciałbym tylko zwrócić uwagę, że najlepszym sposobem na osiągnięcie obsługi zależności w plikach javascript innych niż AMD jest teraz konfiguracja podkładki znajdująca się w RequireJS 2.0+. Jeśli nadal używasz wymagania 1.x, możesz użyć prekursora podkładki , wrapjs
Johann
32
To pytanie ma już co najmniej dwa lata, ale zauważyłem, że jest to nadal problem z RequireJS 2.0 (require-jquery.js używa jQuery 1.8.0, ale najnowsza wersja to 1.8.2).
Jeśli zdarzy ci się zobaczyć to pytanie, zwróć uwagę, że require-jquery.js to teraz tylko require.js i jquery.js, zmiksowane razem. Możesz po prostu edytować require-jquery.js i zastąpić części jQuery nowszą wersją .
Aktualizacja (30 maja 2013 r.) : Teraz, gdy RequireJS ma ścieżki i podkładki, istnieje nowy sposób importowania wtyczek jQuery i jQuery, a stara metoda nie jest już konieczna ani zalecana . Oto skrócona wersja obecnej metody:
Dziękuję za zwrócenie uwagi. Czytałem, że starsza wersja 1.8 miała problemy, które zostały rozwiązane w najnowszej.
Blaine Mucklow
W rzeczy samej. To nie były problemy jQueryUI z curCSS, prawda?
Chris,
1
@AHMED: Oboje działają. Różnica polega na tym, że definicja wyraźnie określa moduł. Zwykle wolę używać definicji prawie wyłącznie, ponieważ jest to bardziej szczegółowe na temat ścieżek: stackoverflow.com/questions/16087635/ ...
Chris
9
Odkryłem, że najlepszym podejściem jest trzymanie jQuery poza moją kompilacją RequireJS.
Po prostu dołącz jquery.min.js do kodu HTML. Następnie utwórz plik jquery.js zawierający coś takiego ...
Jest to dobre obejście, ponieważ mam kilka plików JS, które muszą być ładowane tradycyjnie za pomocą tagów skryptów i są one zależne od jQuery.
jingtao
3
Okazało się, że odpowiedź JasonSmitha jest niezwykle pomocna, prawdopodobnie bardziej niż dokumentacja RequireJS.
Jest jednak sposób, aby go zoptymalizować, aby uniknąć oddzielnych żądań AJAX dla (małych) modułów deklarujących definicję („require_jquery” „require_sammy”). Podejrzewałbym, że r.js zrobiłby to na etapie optymalizacji, ale możesz to zrobić z wyprzedzeniem, aby nie walczyć z Path, systemem BaseURI.
// We are going to define( dependencies by hand, inline.// There is one problem with that through (inferred from testing):// Dependencies are starting to load (and execute) at the point of declaring the inline// define, not at the point of require(// So you may want to nest the inline-defines inside require( // this is, in a way, short replacement for Order plug in, but allows you to use// hand-rolled defines, which the Order plug in, apparently does not allow.var jQueryAndShims = ['jquery']
if(window.JSON == null){
jQueryAndShims.push('json2')
define(
'json2'
, ['js/libs/json2.min.js']
, function() {
returnwindow.JSON
}
)
}
// will start loading the second we define it.
define(
'jquery'
, ['js/libs/jquery_custom.min.js']
, function() {
// we just pick up global jQuery here. // If you want more than one version of jQuery in dom, read a more complicated solution discussed in// "Registering jQuery As An Async-compatible Module" chapter of// http://addyosmani.com/writing-modular-js/returnwindow.jQuery
}
)
// all inline defines for resources that don't rely on other resources can go here.// First level require(// regardless of depends nesting in 'myapp' they will all start downloading // at the point of define( and exec whenever they want, // async in many browsers. Actually requiring it before the nested require makes// sure jquery had *executed and added jQuery to window object* before// all resolved depends (jquery plugins) start firing.require(jQueryAndShims, function($) {
// will start loading the second we define it.
define(
'sammy_and_friends'
, ['jquery','js/libs/jquery_pluginone.min.js','js/libs/jquery_plugintwo.min.js','js/libs/sammy.min.js']
, function($) {
// note, all plugins are unaltered, as they are shipped by developers.// in other words, they don't have define(.. inside.// since they augment global $ (window.jQuery) anyway, and 'jquery' define above picks it up// , we just keep on returning it.// Sammy is attached to $ as $.sammy, so returning just Sammy makes little sensereturn $
}
)
// second level require - insures that Sammy (and other jQuery plugins) - 'sammy_and_friends' - is// loaded before we load Sammy plugins. I normally i would inline all sammy plugins i need // (none, since i use none of them preferring jQuery's direct templating API// and no other Sammy plug in is really of value. ) right into sammy.js file. // But if you want to keep them separate:require(['sammy_and_friends'], function() {
// will start loading the second we define it.
define(
'sammy_extended'
, ['sammy_and_friends','js/libs/sammy_pluginone.min.js','js/libs/sammy_plugintwo.min.js']
, function($) {
// as defined above, 'sammy_and_friends' actually returns (globall) jQuery obj to which// Sammy is attached. So we continue to return $return $
}
)
// will start loading the second we define it.
define(
'myapp'
, ['sammy_extended', 'js/myapplication_v20111231.js']
, function($, myapp_instantiator) {
// note, myapplication may, but does not have to contain RequireJS-compatible define// that returns something. However, if it contains something like // "$(document).ready(function() { ... " already it MAY fire before // it's depends - 'sammy_extended' is fully loaded.// Insdead i recommend that myapplication.js returns a generator // (app-object-generating function pointer)// that takes jQuery (with all loaded , applied plugins) // The expectation is that before the below return is executed, // all depends are loaded (in order of depends tree)// You would init your app here like so:return myapp_instantiator($)
// then "Run" the instance in require( as shown below
}
)
// Third level require - the one that actually starts our application and relies on// dependency pyramid stat starts with jQuery + Shims, followed by jQuery plugins, Sammy, // followed by Sammy's plugins all coming in under 'sammy_extended'require(['jquery', 'myapp'], function($, myappinstance) {
$(document).ready(function() {myappinstance.Run()})
})
}) // end of Second-level require
}) // end of First-level require
wreszcie myapplication.js:
// this define is a double-wrap.// it returns application object instantiator that takes in jQuery (when it's available) and , then, that// instance can be "ran" by pulling .Run() method on it.
define(function() {
// this function does only two things:// 1. defines our application class // 2. inits the class and returns it.returnfunction($) {
// 1. defining the classvar MyAppClass = function($) {
var me = thisthis._sammy_application = $.sammy(function() {
this.raise_errors = truethis.debug = truethis.run_interval_every = 300this.template_engine = nullthis.element_selector = 'body'// ..
})
this._sammy_application.route(...) // define your routes ets...this.MyAppMethodA = function(blah){log(blah)} // extend your app with methods if you want// ...// this one is the one we will .Run from require( in loader.jsthis.Run = function() {
me._sammy_application.run('#/')
}
}
// 2. returning class's instancereturnnew MyAppClass($) // notice that this is INITED app, but not started (by .Run) // .Run will be pulled by calling code when appropriate
}
})
Ta struktura (luźno zastępuje (duplikuje?) Wtyczkę RequireJS's Order, ale) pozwala zmniejszyć liczbę plików potrzebnych do AJAX, dodając większą kontrolę do definicji drzewa zależności i drzewa zależności.
Istnieje również duży bonus do oddzielnego ładowania jQuery (które zwykle wynosi 100k) - możesz kontrolować buforowanie na serwerze lub buforować jQuery w localStorage przeglądarki. Spójrz na projekt AMD-Cache tutaj https://github.com/jensarps/AMD-cache, a następnie zmień definicję (instrukcje zawierające "cache!": I zostanie (na zawsze :)) zablokowana w przeglądarce użytkownika.
define(
'jquery'
, ['cache!js/libs/jquery_old.min.js']
, function() {
// we just pick up global jQuery here. // If you want more than one version of jQuery in dom, read a more complicated solution discussed in// "Registering jQuery As An Async-compatible Module" chapter of// http://addyosmani.com/writing-modular-js/returnwindow.jQuery
}
)
Uwaga dotycząca jQuery 1.7.x + Nie dołącza się już do obiektu okna, więc powyższe NIE będzie działać z niezmodyfikowanym plikiem jQuery 1.7.x +. Tam musisz dostosować swoje jquery **. Js, aby zawierało to przed zamykającym "}) (okno);":
;window.jQuery=window.$=jQuery
Jeśli masz w konsoli błędy „jQuery undefined”, oznacza to, że wersja jQuery, której używasz, nie dołącza się do okna.
Licencja kodu: domena publiczna.
Ujawnienia: JavaScript powyżej pachnie „pseudokodem”, ponieważ jest parafrazą (ręcznym przycinaniem) znacznie bardziej szczegółowego kodu produkcyjnego. Kod przedstawiony powyżej nie ma gwarancji, że będzie działał i NIE został przetestowany pod kątem działania zgodnie z prezentacją. Audyt, przetestuj. Średniki są celowo pomijane, ponieważ nie są wymagane zgodnie ze specyfikacją JS, a kod wygląda lepiej bez nich.
Po walce z RequireJS (rzeczy ładują się nie w porządku, nie przestrzegają definicji, wymagają zagnieżdżenia. Inne magiczne zachowania) przerzuciłem się na Curl.JS i zacząłem dobrze spać w nocy. Nie jest tak hipnotyzowany, ale cholera, jest stabilny i łatwy w obsłudze!
ddotsenko
1
Oprócz odpowiedzi jhs zapoznaj się z nowszymi instrukcjami na stronie github require-jquery z pliku README.md. Obejmuje zarówno najprostsze podejście do korzystania z połączonego pliku jquery / require.js, jak i jak używać oddzielnego pliku jquery.js.
Odpowiedzi:
To też jest moje dokładne pytanie! Muszę też używać starszej biblioteki jQuery, ale także bardziej „tradycyjnych” bibliotek javascript. Jaka jest najlepsza technika, aby to zrobić? (Jeśli nie masz nic przeciwko, mogę zredagować twoje pytanie, aby było bardziej ogólne). Oto, czego się nauczyłem.
Autor RequireJS, James Burke, wyjaśnił zalety połączonego pliku RequireJS + jQuery . Masz dwie rzeczy.
Dostępny jest moduł
jquery
,, i jest to obiekt jQuery. To jest bezpieczne:// My module depends on jQuery but what if $ was overwritten? define(["jquery"], function($) { // $ is guaranteed to be jQuery now */ })
jQuery jest już załadowany przed jakimkolwiek
require()
lubdefine()
rzeczami. Wszystkie moduły mają gwarancję, że jQuery jest gotowe. Nie potrzebujesz nawetrequire/order.js
wtyczki, ponieważ jQuery został w zasadzie na stałe zakodowany do załadowania jako pierwszy.Dla mnie numer 2 nie jest zbyt pomocny. Większość prawdziwych aplikacji ma wiele
.js
plików, które muszą być ładowane we właściwej kolejności - smutne, ale prawdziwe. Gdy potrzebujesz Sammy lub Underscore.js, połączony plik RequireJS + jQuery nie pomaga.Moim rozwiązaniem jest napisanie prostych opakowań RequireJS, które ładują moje tradycyjne skrypty za pomocą wtyczki „order”.
Przykład
Załóżmy, że moja aplikacja ma te składniki (według zależności).
Moim zdaniem wszystko powyżej, co się kończy,
.js
jest „tradycyjnym” skryptem. Wszystko bez.js
jest wtyczką RequireJS. Klucz jest taki: rzeczy na wysokim poziomie (greatapp, my_sammy) to moduły, a na głębszych poziomach wracają do tradycyjnych.js
plików.Uruchamianie
Wszystko zaczyna się od programu uruchamiającego, który mówi firmie RequireJS, jak zacząć.
<html> <head> <script data-main="js/boot.js" src="js/require.js"></script> </head> </html>
W
js/boot.js
kładę tylko config i jak uruchomić aplikację.require( // The "paths" maps module names to actual places to fetch the file. // I made modules with simple names (jquery, sammy) that will do the hard work. { paths: { jquery: "require_jquery" , sammy : "require_sammy" } } // Next is the root module to run, which depends on everything else. , [ "greatapp" ] // Finally, start my app in whatever way it uses. , function(greatapp) { greatapp.start(); } );
Główna aplikacja
W
greatapp.js
mam normalnie wyglądający moduł.define(["jquery", "sammy"], function($, Sammy) { // At this point, jQuery and SammyJS are loaded successfully. // By depending on "jquery", the "require_jquery.js" file will run; same for sammy. // Those require_* files also pass jQuery and Sammy to here, so no more globals! var start = function() { $(document).ready(function() { $("body").html("Hello world!"); }) } return {"start":start}; }
Opakowania modułów RequireJS wokół tradycyjnych plików
require_jquery.js
:define(["/custom/path/to/my/jquery.js?1.4.2"], function() { // Raw jQuery does not return anything, so return it explicitly here. return jQuery; })
require_sammy.js
:// These must be in order, so use the "order!" plugin. define([ "order!jquery" , "order!/path/to/custom/sammy/sammy-0.6.2-min.js" , "order!/path/to/custom/sammy/plugins/sammy.json-0.6.2-min.js" , "order!/path/to/custom/sammy/plugins/sammy.storage-0.6.2-min.js" , "order!/path/to/custom/sammy/plugins/sammy.mustache-0.6.2-min.js" ] , function($) { // Raw sammy does not return anything, so return it explicitly here. return $.sammy; } );
źródło
To pytanie ma już co najmniej dwa lata, ale zauważyłem, że jest to nadal problem z RequireJS 2.0 (require-jquery.js używa jQuery 1.8.0, ale najnowsza wersja to 1.8.2).
Jeśli zdarzy ci się zobaczyć to pytanie, zwróć uwagę, że require-jquery.js to teraz tylko require.js i jquery.js, zmiksowane razem. Możesz po prostu edytować require-jquery.js i zastąpić części jQuery nowszą wersją .
Aktualizacja (30 maja 2013 r.) : Teraz, gdy RequireJS ma ścieżki i podkładki, istnieje nowy sposób importowania wtyczek jQuery i jQuery, a stara metoda nie jest już konieczna ani zalecana . Oto skrócona wersja obecnej metody:
requirejs.config({ "paths": { "jquery": "//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min" } }); define(["jquery"], function($) { $(function() { }); });
Więcej informacji można znaleźć pod adresem http://requirejs.org/docs/jquery.html .
źródło
Odkryłem, że najlepszym podejściem jest trzymanie jQuery poza moją kompilacją RequireJS.
Po prostu dołącz jquery.min.js do kodu HTML. Następnie utwórz plik jquery.js zawierający coś takiego ...
define([], function() { return window.$; });
źródło
Okazało się, że odpowiedź JasonSmitha jest niezwykle pomocna, prawdopodobnie bardziej niż dokumentacja RequireJS.
Jest jednak sposób, aby go zoptymalizować, aby uniknąć oddzielnych żądań AJAX dla (małych) modułów deklarujących definicję („require_jquery” „require_sammy”). Podejrzewałbym, że r.js zrobiłby to na etapie optymalizacji, ale możesz to zrobić z wyprzedzeniem, aby nie walczyć z Path, systemem BaseURI.
index.html:
<html> <head> <script data-main="js/loader.js" src="js/require.js"></script> </head> </html>
loader.js:
// We are going to define( dependencies by hand, inline. // There is one problem with that through (inferred from testing): // Dependencies are starting to load (and execute) at the point of declaring the inline // define, not at the point of require( // So you may want to nest the inline-defines inside require( // this is, in a way, short replacement for Order plug in, but allows you to use // hand-rolled defines, which the Order plug in, apparently does not allow. var jQueryAndShims = ['jquery'] if(window.JSON == null){ jQueryAndShims.push('json2') define( 'json2' , ['js/libs/json2.min.js'] , function() { return window.JSON } ) } // will start loading the second we define it. define( 'jquery' , ['js/libs/jquery_custom.min.js'] , function() { // we just pick up global jQuery here. // If you want more than one version of jQuery in dom, read a more complicated solution discussed in // "Registering jQuery As An Async-compatible Module" chapter of // http://addyosmani.com/writing-modular-js/ return window.jQuery } ) // all inline defines for resources that don't rely on other resources can go here. // First level require( // regardless of depends nesting in 'myapp' they will all start downloading // at the point of define( and exec whenever they want, // async in many browsers. Actually requiring it before the nested require makes // sure jquery had *executed and added jQuery to window object* before // all resolved depends (jquery plugins) start firing. require(jQueryAndShims, function($) { // will start loading the second we define it. define( 'sammy_and_friends' , ['jquery','js/libs/jquery_pluginone.min.js','js/libs/jquery_plugintwo.min.js','js/libs/sammy.min.js'] , function($) { // note, all plugins are unaltered, as they are shipped by developers. // in other words, they don't have define(.. inside. // since they augment global $ (window.jQuery) anyway, and 'jquery' define above picks it up // , we just keep on returning it. // Sammy is attached to $ as $.sammy, so returning just Sammy makes little sense return $ } ) // second level require - insures that Sammy (and other jQuery plugins) - 'sammy_and_friends' - is // loaded before we load Sammy plugins. I normally i would inline all sammy plugins i need // (none, since i use none of them preferring jQuery's direct templating API // and no other Sammy plug in is really of value. ) right into sammy.js file. // But if you want to keep them separate: require(['sammy_and_friends'], function() { // will start loading the second we define it. define( 'sammy_extended' , ['sammy_and_friends','js/libs/sammy_pluginone.min.js','js/libs/sammy_plugintwo.min.js'] , function($) { // as defined above, 'sammy_and_friends' actually returns (globall) jQuery obj to which // Sammy is attached. So we continue to return $ return $ } ) // will start loading the second we define it. define( 'myapp' , ['sammy_extended', 'js/myapplication_v20111231.js'] , function($, myapp_instantiator) { // note, myapplication may, but does not have to contain RequireJS-compatible define // that returns something. However, if it contains something like // "$(document).ready(function() { ... " already it MAY fire before // it's depends - 'sammy_extended' is fully loaded. // Insdead i recommend that myapplication.js returns a generator // (app-object-generating function pointer) // that takes jQuery (with all loaded , applied plugins) // The expectation is that before the below return is executed, // all depends are loaded (in order of depends tree) // You would init your app here like so: return myapp_instantiator($) // then "Run" the instance in require( as shown below } ) // Third level require - the one that actually starts our application and relies on // dependency pyramid stat starts with jQuery + Shims, followed by jQuery plugins, Sammy, // followed by Sammy's plugins all coming in under 'sammy_extended' require(['jquery', 'myapp'], function($, myappinstance) { $(document).ready(function() {myappinstance.Run()}) }) }) // end of Second-level require }) // end of First-level require
wreszcie myapplication.js:
// this define is a double-wrap. // it returns application object instantiator that takes in jQuery (when it's available) and , then, that // instance can be "ran" by pulling .Run() method on it. define(function() { // this function does only two things: // 1. defines our application class // 2. inits the class and returns it. return function($) { // 1. defining the class var MyAppClass = function($) { var me = this this._sammy_application = $.sammy(function() { this.raise_errors = true this.debug = true this.run_interval_every = 300 this.template_engine = null this.element_selector = 'body' // .. }) this._sammy_application.route(...) // define your routes ets... this.MyAppMethodA = function(blah){log(blah)} // extend your app with methods if you want // ... // this one is the one we will .Run from require( in loader.js this.Run = function() { me._sammy_application.run('#/') } } // 2. returning class's instance return new MyAppClass($) // notice that this is INITED app, but not started (by .Run) // .Run will be pulled by calling code when appropriate } })
Ta struktura (luźno zastępuje (duplikuje?) Wtyczkę RequireJS's Order, ale) pozwala zmniejszyć liczbę plików potrzebnych do AJAX, dodając większą kontrolę do definicji drzewa zależności i drzewa zależności.
Istnieje również duży bonus do oddzielnego ładowania jQuery (które zwykle wynosi 100k) - możesz kontrolować buforowanie na serwerze lub buforować jQuery w localStorage przeglądarki. Spójrz na projekt AMD-Cache tutaj https://github.com/jensarps/AMD-cache, a następnie zmień definicję (instrukcje zawierające "cache!": I zostanie (na zawsze :)) zablokowana w przeglądarce użytkownika.
define( 'jquery' , ['cache!js/libs/jquery_old.min.js'] , function() { // we just pick up global jQuery here. // If you want more than one version of jQuery in dom, read a more complicated solution discussed in // "Registering jQuery As An Async-compatible Module" chapter of // http://addyosmani.com/writing-modular-js/ return window.jQuery } )
Uwaga dotycząca jQuery 1.7.x + Nie dołącza się już do obiektu okna, więc powyższe NIE będzie działać z niezmodyfikowanym plikiem jQuery 1.7.x +. Tam musisz dostosować swoje jquery **. Js, aby zawierało to przed zamykającym "}) (okno);":
;window.jQuery=window.$=jQuery
Jeśli masz w konsoli błędy „jQuery undefined”, oznacza to, że wersja jQuery, której używasz, nie dołącza się do okna.
Licencja kodu: domena publiczna.
Ujawnienia: JavaScript powyżej pachnie „pseudokodem”, ponieważ jest parafrazą (ręcznym przycinaniem) znacznie bardziej szczegółowego kodu produkcyjnego. Kod przedstawiony powyżej nie ma gwarancji, że będzie działał i NIE został przetestowany pod kątem działania zgodnie z prezentacją. Audyt, przetestuj. Średniki są celowo pomijane, ponieważ nie są wymagane zgodnie ze specyfikacją JS, a kod wygląda lepiej bez nich.
źródło
Oprócz odpowiedzi jhs zapoznaj się z nowszymi instrukcjami na stronie github require-jquery z pliku README.md. Obejmuje zarówno najprostsze podejście do korzystania z połączonego pliku jquery / require.js, jak i jak używać oddzielnego pliku jquery.js.
źródło