Dojo require() i AMD (1.7)

Question

Mam czas heckuva przejście do Dojo i nowej struktury AMD, i mam nadzieję, że ktoś może rzucić trochę światła na całą koncepcję. Mieszkam w Google od kilku tygodni, próbując znaleźć informacje na temat nie użycia, ale tendencje w strukturze i wzorach w używaniu tego.

To dziwne, że dla relatywnie złożonej aplikacji javascript, takiej jak strona główna, gdzie Dijits muszą być tworzone i stylizowane, elementy DOM utworzone itp., Które muszę wymagać, a zatem używać, TON różne moduły, które w przeciwnym razie były dostępne w przestrzeni nazw dojo przed systemem AMD (lub przynajmniej nie przypisane do 23 różnych zmiennych).

Przykład:

require(['dijit/form/ValidationTextBox', 'dijit/form/SimpleTextarea', 'dijit/form/CheckBox', 'dijit/Dialog', 'dijit/form/Form']) 
require(['dojo/ready', 'dojo/parser', 'dojo/dom-style', 'dijit/registry', 'dojo/dom', 'dojo/_base/connect', 'dojo/dom-construct'], 
function(ready, parser, style, registry, dom, event, construct){ 
    //...etc 
} 

To tylko niektóre z modułów dla jednej ze stron, ja pracuję nad. Z pewnością istnieje lepszy, nie wtrącający się w przyszły sposób sposób dostępu do tych metod itp. Czy naprawdę muszę zaimportować całkowicie nowy moduł, aby użyć byId()? A jeszcze inny do łączenia wydarzeń? Poza tym wszystkie bałagany tworzone przez konieczność przypisania nazwy zmiennej na liście argumentów funkcji, aby po prostu wyglądać jak taki backstep.

Pomyślałem, że możesz require() moduł tylko w razie potrzeby, na przykład moduł query, ale jeśli potrzebuję go więcej niż raz, to jest szansa, że ​​zmienna, do której jest przypisany, jest poza zakresem, i musiałbym umieść go w rozmowie domReady! lub ready. reaalllly .... ??!

Dlatego mogę tylko założyć, że to mój brak zrozumienia dla dojo.

Naprawdę szukałem, szukałem i kupowałem książki (choć przed AMD), ale ta biblioteka naprawdę daje mi szansę na moje pieniądze. Doceniam światło, które każdy może rzucić na to.

Edycja dla przykładu

require(['dijit/form/ValidationTextBox']) 
require(['dojo/ready', 'dojo/parser', 'dojo/dom-style', 'dijit/registry', 'dojo/dom', 'dojo/_base/connect', 'dojo/dom-construct'], function(ready, parser, style, registry, dom, event, construct){ 
    /* perform some tasks */ 
    var _name = new dijit.form.ValidationTextBox({ 
     propercase : true, 
     tooltipPosition : ['above', 'after'] 
    }, 'name') 

    /* 
    Let's say I want to use the query module in some places, i.e. here. 
    */ 
    require(['dojo/query', 'dojo/dom-attr'], function(query, attr){ 
     query('#list li').forEach(function(li){ 
      // do something with these 
     }) 
    }) 
} 

Opierając się tego formatu, który jest używany z wieloma przykładami zarówno od ludzi Dojo Toolkit, a także stron osób trzecich, byłoby, moim skromnym zdaniem, absolutnie śmieszne Załaduj wszystkie wymagane moduły, ponieważ pierwszy function(ready, parser, style, registy... będzie dłuższy i dłuższy, i spowoduje problemy z nazewnictwem kolizji, itp.

Rozpalanie i require() wszystkie moduły, których potrzebuję w życiu skryptu, wydaje mi się głupie. . Biorąc to pod uwagę, musiałbym przyjrzeć się niektórym skryptom "menedżera pakietów". Ale dla tego przykładu, gdybym chciał użyć modułu zapytań w wybranych miejscach, musiałbym załadować go do reszty w głównej instrukcji require(). Rozumiem, dlaczego w pewnym stopniu, ale co jest tak źle w ogólnych obszarach nazw dot-syntaktyka? dojo.whatever? dijit.findIt()? Dlaczego moduł ładujący, odniesienie w unikalnej nazwie, przechodzi przez zamknięcie, bla bla bla?

Chciałbym, żeby to było łatwiejsze pytanie, ale mam nadzieję, że ma to sens.

Rozdrażnienie

Zadzwoń do mnie NEWB, ale to jest naprawdę .. naprawdę .. doprowadza mnie do szału. Nie jestem noob jeśli chodzi o JavaScript (podobno nie), ale wow. Nie mogę wymyślić tego !

Oto, co gromadzę. W adder.js:

define('adder', function(require, exports){ 
    exports.addTen = function(x){ 
     return x + 10 
    } 
}) 

w jakiejś stronie wzorcowej lub cokolwiek:

require(['./js/cg/adder.js']) 

... co nie wynika estetyczny formatu require(['cg/adder']) ale cokolwiek. W tej chwili nie ważne.

Następnie użycie adder powinno być:

console.log(adder.addTen(100)) // 110 

Najbliżej Dostałem console.log(adder) powrocie 3. Tak. 3. W przeciwnym razie jest to adder is not defined.

Dlaczego to musi być takie trudne? Używam mojej karty noob, bo naprawdę nie mam pojęcia, dlaczego to się nie zgadza.

Dzięki chłopaki.

Answer 1

Zależność Format tablicy:

define(["a", "b", "c"], function (a, b, c) { 
}); 

rzeczywiście może być denerwujące i podatne na błędy. Dopasowanie wpisów tablicy do parametrów funkcji jest prawdziwym problemem.

Preferuję format ten require ("Simplified CommonJS Wrapper"):

define(function (require) { 
    var a = require("a"); 
    var b = require("b"); 
    var c = require("c"); 
}); 

To utrzymuje swoje linie krótki i pozwala zmienić/usunąć/dodać linie bez konieczności pamiętania aby zmienić ten stan rzeczy w dwóch miejscach.

Ten drugi format nie będzie działać na przeglądarkach mobilnych na PS3 i starszych przeglądarkach Opery, ale mam nadzieję, że Cię to nie obchodzi.

---

Jak, dlaczego to robi, zamiast ręcznie przestrzeni nazw obiektów, odpowiedź @ Peller daje dobry przegląd dlaczego modułowość jest rzeczą dobrą i my answer to a similar question rozmowy o tym, dlaczego AMD i systemy modułowe jako sposób osiągania modułowość są dobra rzecz.

Jedyną rzeczą, którą chciałbym dodać do odpowiedzi @pellera jest rozszerzenie na "zwracanie uwagi na zależności, które faktycznie powodują znacznie lepszy kod". Jeśli twój moduł wymaga zbyt wielu innych modułów, to zły znak! Mamy luźną regułę w naszej bazie kodów JavaScript 72K LOC, że moduł powinien mieć ~ 100 linii i wymagać od zera do czterech zależności. To nam dobrze służyło.

Answer 2

requirejs.org daje całkiem niezły przegląd tego, czym jest AMD i dlaczego warto z niego korzystać. Tak, Dojo porusza się w kierunku mniejszych modułów, które chciałbyś odnieść osobno. Powoduje to, że ładujesz mniej kodu, a twoje odniesienia do niego są wyraźne. Uważam, że zwracanie uwagi na zależności faktycznie tworzy znacznie lepszy kod. AMD umożliwia optymalizacje, a po zakończeniu migracji nie trzeba już ładować wszystkiego do globaliów. Nigdy więcej kolizji! Blok require() opakowuje kod, który używa różnych modułów. domReady! odnosi się do ładowania DOM i nie ma nic wspólnego ze zmiennymi będącymi w zasięgu.

W każdym razie jest to niezgodne z formatem SO. Możesz zadać konkretne pytania.