Czy warto używać Require.js z Angular.js? [Zamknięte]

Jestem nowicjuszem w Angular.js i próbuję zrozumieć, czym różni się od Backbone.js ... Kiedyś zarządzaliśmy zależnościami pakietów w Require.js podczas korzystania z Backbone. Czy ma sens robić to samo z Angular.js?

Tak, sensowne jest używanie angular.jswraz z tym, w require.jsktórym można używać require.jsdo modularyzacji komponentów.

Istnieje projekt seed, który wykorzystuje both angular.js and require.js.

Podsumowując to, co moim zdaniem, pytanie OP naprawdę brzmi:

Jeśli buduję aplikację głównie w Angular 1.x i (domyślnie) robię to w erze Grunt / Gulp / Broccoli i Bower / NPM, i być może mam kilka dodatkowych zależności bibliotek, czy wymaga dodania jasnego, konkretnego wartość ponad to, co otrzymuję, używając Angular bez wymagania?

Lub, mówiąc inaczej:

„Czy waniliowa aplikacja Angular wymaga efektywnego zarządzania podstawowym ładowaniem komponentów Angular, jeśli mam inne sposoby obsługi podstawowego ładowania skryptów? ”

Uważam, że podstawową odpowiedzią na to jest: „nie, chyba że dzieje się coś innego i / lub nie możesz używać nowszych, bardziej nowoczesnych narzędzi”.

Wyjaśnijmy na wstępie: RequireJS to świetne narzędzie, które rozwiązało niektóre bardzo ważne problemy i zaprowadziło nas na dalszy plan, w kierunku bardziej skalowalnych, bardziej profesjonalnych aplikacji JavaScript. Co ważne, po raz pierwszy wiele osób spotkało się z koncepcją modularyzacji i wyjścia z globalnego zasięgu. Jeśli więc zamierzasz zbudować aplikację Javascript, która wymaga skalowania, to Require i wzorzec AMD nie są złymi narzędziami do tego.

Ale czy jest coś szczególnego w Angular, co sprawia, że ​​Require / AMD jest szczególnie dobrym rozwiązaniem? Nie. W rzeczywistości Angular zapewnia własny wzorzec modularyzacji i enkapsulacji, który na wiele sposobów czyni zbędnymi podstawowe funkcje modularyzacji AMD. Zintegrowanie modułów Angular ze wzorcem AMD nie jest niemożliwe, ale jest trochę ... wybredne. Na pewno będziesz spędzać czas na ładnym zintegrowaniu dwóch wzorców.

Dla pewnej perspektywy samego zespołu Angular, jest to , autorstwa Briana Forda, autora Angular Batarang, a teraz członka głównego zespołu Angular:

Nie polecam używania RequireJS z AngularJS. Chociaż z pewnością jest to możliwe, nie widziałem żadnego przypadku, w którym RequireJS byłby korzystny w praktyce.

Tak więc na bardzo szczegółowe pytanie AngularJS: Angular i Require / AMD są ortogonalne, a miejscami nakładają się. Państwo może używać ich razem, ale nie ma powodu, szczególnie odnoszące się do natury / wzorców samej kątowej.

Ale co z podstawowym zarządzaniem wewnętrznymi i zewnętrznymi zależnościami dla skalowalnych aplikacji Javascript? Czy Require nie robi dla mnie czegoś naprawdę krytycznego?

Polecam sprawdzić Bower i NPM, a zwłaszcza NPM. Nie próbuję rozpoczynać świętej wojny o porównywalne korzyści z tych narzędzi. Chcę tylko powiedzieć: są inne sposoby na skórowanie tego kota, a te sposoby mogą być nawet lepsze niż AMD / Require. (Z pewnością mają znacznie bardziej popularny impet pod koniec 2015 r., Szczególnie NPM, w połączeniu z modułami ES6 lub CommonJS. Zobacz powiązane pytanie SO .)

Co powiesz na leniwe ładowanie?

Pamiętaj, że leniwe ładowanie i leniwe pobieranie są różne. Leniwe ładowanie Angulara nie oznacza, że ​​wyciągasz je bezpośrednio z serwera. W aplikacji w stylu Yeoman z automatyzacją javascript łączymy i minimalizujemy cały shebang razem w jednym pliku. Są obecne, ale nie są wykonywane / tworzone, dopóki nie będą potrzebne. Poprawa prędkości i przepustowości, którą uzyskujesz dzięki temu, znacznie przewyższa wszelkie domniemane ulepszenia wynikające z leniwego pobierania konkretnego kontrolera 20-liniowego. W rzeczywistości zmarnowane opóźnienie sieci i narzut transmisji dla tego kontrolera będzie o rząd wielkości większy niż rozmiar samego kontrolera.

Powiedzmy jednak, że naprawdę potrzebujesz leniwego pobierania, być może w przypadku rzadko używanych elementów aplikacji, takich jak interfejs administratora. To bardzo uzasadniony przypadek. Require może rzeczywiście zrobić to za Ciebie. Ale istnieje również wiele innych , potencjalnie bardziej elastycznych opcji, które pozwalają osiągnąć to samo. I Angular 2.0 najwyraźniej zajmie się tym za nas, wbudowany w router . ( Szczegóły .)

Ale co w trakcie tworzenia mojego lokalnego dewelopera?

Jak mogę załadować wszystkie moje dziesiątki / setki plików skryptowych bez konieczności ręcznego dołączania ich wszystkich do pliku index.html?

Spójrz na pod-generatory w generatorze kątowym Yeomana lub na wzorce automatyzacji zawarte w generatorze-kątowniku lub na standardową automatyzację Webpack dla React. Zapewniają one czysty, skalowalny sposób na: automatyczne dołączanie plików w momencie rusztowania elementów lub po prostu przechwytywanie ich wszystkich automatycznie, jeśli znajdują się w określonych folderach / pasują do określonych wzorców globalnych. Nigdy więcej nie będziesz musiał myśleć o własnym ładowaniu skryptu, gdy będziesz mieć te ostatnie opcje.

Konkluzja?

Wymagaj to świetne narzędzie do niektórych rzeczy. Ale idź z ziarnem, gdy tylko jest to możliwe, i oddzielaj swoje obawy, gdy tylko jest to możliwe. Niech Angular martwi się o własny wzorzec modularyzacji Angulara i rozważ użycie modułów ES6 lub CommonJS jako ogólnego wzorca modularyzacji. Niech nowoczesne narzędzia automatyzacji martwią się ładowaniem skryptów i zarządzaniem zależnościami. I zajmuj się asynchronicznym leniwym ładowaniem w bardziej szczegółowy sposób, zamiast mieszać go z pozostałymi dwoma problemami.

To powiedziawszy, jeśli tworzysz aplikacje Angular, ale z jakiegoś powodu nie możesz zainstalować Node na swoim komputerze, aby korzystać z narzędzi automatyzacji Javascript, to Require może być dobrym alternatywnym rozwiązaniem. I widziałem naprawdę skomplikowane konfiguracje, w których ludzie chcą dynamicznie ładować komponenty Angular, które deklarują swoje zależności lub coś w tym rodzaju. I chociaż prawdopodobnie spróbowałbym rozwiązać ten problem w inny sposób, widzę zalety tego pomysłu w tej bardzo szczególnej sytuacji.

Ale poza tym ... zaczynając od zera dzięki nowej aplikacji Angular i elastyczności, aby stworzyć nowoczesne środowisko automatyzacji ... masz wiele innych, bardziej elastycznych, bardziej nowoczesnych opcji.

(Aktualizowane wielokrotnie, aby nadążać za rozwijającą się sceną JS).

Tak, to ma sens.

Moduły kątowe nie próbują rozwiązać problemu porządkowania obciążenia skryptu lub opóźnionego pobierania skryptu. Cele te są ortogonalne i oba systemy modułów mogą żyć obok siebie i spełniać swoje cele.

Źródło: oficjalna strona Angular JS

Uważam to za subiektywne pytanie, dlatego przedstawię swoją subiektywną opinię.

Angular ma wbudowany mechanizm modularyzacji. Gdy tworzysz aplikację, pierwszą rzeczą, którą powinieneś zrobić

var app = angular.module("myApp");

i wtedy

app.directive(...);

app.controller(...);

app.service(...);

Jeśli spojrzysz na ziarno kątowe, które jest zgrabną aplikacją startową dla kątownika, rozdzieliły one dyrektywy, usługi, kontrolery itp. Na różne moduły, a następnie załadowały te moduły jako zależności w głównej aplikacji.

Coś jak :

var app = angular.module("myApp",["Directives","Controllers","Services"];

Angular również leniwie ładuje te moduły (do pamięci), a nie ich pliki skryptów.

Jeśli chodzi o leniwe ładowanie plików skryptów, szczerze mówiąc, chyba że piszesz coś bardzo dużego, byłoby to przesadą, ponieważ kątowe z samej swojej natury zmniejsza ilość pisanego kodu. Typowa aplikacja napisana w większości innych frameworków mogłaby oczekiwać zmniejszenia LOC o około 30-50%, jeśli jest napisana pod kątem.

Używanie RequireJS z AngularJS ma sens, ale tylko wtedy, gdy zrozumiesz, jak każdy z nich działa w odniesieniu do wstrzykiwania zależności , ponieważ chociaż oba wstrzykują zależności, wstrzykują bardzo różne rzeczy.

AngularJS ma własny system zależności, który pozwala wstrzykiwać moduły AngularJS do nowo utworzonego modułu w celu ponownego wykorzystania implementacji. Załóżmy, że utworzyłeś „pierwszy” moduł, który implementuje filtr „pozdrawiam” AngularJS:

angular
  .module('first', [])
  .filter('greet', function() {
    return function(name) {
      return 'Hello, ' + name + '!';
    }
  });

A teraz załóżmy, że chcesz użyć filtru „pozdrawiam” w innym module o nazwie „drugi”, który implementuje filtr „do widzenia”. Możesz to zrobić, wstrzykując moduł „pierwszy” do modułu „drugi”:

angular
  .module('second', ['first'])
  .filter('goodbye', function() {
    return function(name) {
      return 'Good bye, ' + name + '!';
    }
  });

Chodzi o to, że aby działało poprawnie bez RequireJS, musisz upewnić się, że „pierwszy” moduł AngularJS jest załadowany na stronie przed utworzeniem „drugiego” modułu AngularJS. Cytowanie dokumentacji:

W zależności od modułu oznacza to, że wymagany moduł musi zostać załadowany przed załadowaniem wymaganego modułu.

W tym sensie RequireJS może ci pomóc, ponieważ RequireJS zapewnia czysty sposób na wstrzykiwanie skryptów na stronę, pomagając w organizacji zależności między nimi.

Wracając do „pierwszego” i „drugiego” modułu AngularJS, oto jak możesz to zrobić za pomocą RequireJS oddzielającego moduły w różnych plikach, aby wykorzystać ładowanie zależności skryptu:

// firstModule.js file
define(['angular'], function(angular) {
  angular
    .module('first', [])
    .filter('greet', function() {
      return function(name) {
        return 'Hello, ' + name + '!';
      }
    });
});

// secondModule.js file
define(['angular', 'firstModule'], function(angular) {
  angular
    .module('second', ['first'])
    .filter('goodbye', function() {
      return function(name) {
        return 'Good bye, ' + name + '!';
      }
    });
});

Widać, że jesteśmy zależni od pliku „firstModule”, który zostanie wstrzyknięty, zanim będzie można wykonać treść wywołania zwrotnego RequireJS, który wymaga załadowania „pierwszego” modułu AngularJS do utworzenia „drugiego” modułu AngularJS.

Uwaga dodatkowa: Wstrzykiwanie „kątowego” do plików „firstModule” i „secondModule”, ponieważ zależność jest wymagana, aby używać AngularJS wewnątrz funkcji wywołania zwrotnego RequireJS i należy go skonfigurować w konfiguracji RequireJS, aby odwzorować „angular” na kod biblioteki. Możliwe, że AngularJS również został załadowany na stronę w tradycyjny sposób (tag skryptu), chociaż pokonuje zalety RequireJS.

Więcej szczegółów na temat obsługi RequireJS z AngularJS od wersji 2.0 na moim blogu.

Na podstawie mojego postu na blogu „Sensing of RequireJS with AngularJS” , oto link .

Jak wspomniał @ganaraj, AngularJS ma zastrzyk zależności w swoim rdzeniu. Kiedy budowałem aplikacje z ziarnami zabawek z RequireJS i bez niego, osobiście odkryłem, że RequireJS był prawdopodobnie przesadny w większości przypadków użycia.

To nie znaczy, że RequireJS nie jest użyteczny ze względu na możliwości ładowania skryptów i utrzymywania bazy kodu w czystości podczas programowania. Połączenie optymalizatora r.js ( https://github.com/jrburke/r.js ) z migdałami ( https://github.com/jrburke/almond ) może stworzyć bardzo wąską historię ładowania skryptów. Jednak ponieważ jego funkcje zarządzania zależnościami nie są tak ważne, ponieważ kątowanie stanowi rdzeń aplikacji, możesz również oceniać inne rozwiązania ładowania skryptów po stronie klienta (HeadJS, LABjs, ...), a nawet po stronie serwera (MVC4 Bundler, ...) do konkretnego zastosowania.

Tak, szczególnie w przypadku bardzo dużych SPA.

W niektórych przypadkach RequireJS jest koniecznością. Na przykład tworzę aplikacje PhoneGap przy użyciu AngularJS, który również korzysta z Google Map API. Bez programu ładującego AMD, takiego jak RequireJS, aplikacja po prostu zawiesiłaby się po uruchomieniu w trybie offline, ponieważ nie może pozyskiwać skryptów interfejsu API Map Google. Moduł ładujący AMD daje mi możliwość wyświetlenia użytkownikowi komunikatu o błędzie.

Jednak integracja między AngularJS i RequireJS jest nieco trudna. Stworzyłem angularAMD, aby ten proces był mniej bolesny:

http://marcoslin.github.io/angularAMD/

Krótka odpowiedź brzmi: ma sens. Ostatnio zostało to omówione na ng-conf 2014. Oto wykład na ten temat:

http://www.youtube.com/watch?v=4yulGISBF8w

Sensowne jest używanie wymaganego z angularjs, jeśli planujesz leniwe ładowanie kontrolerów i dyrektyw itp., A także łączenie wielu leniwych zależności w pojedyncze pliki skryptowe dla znacznie szybszego leniwego ładowania. RequireJS ma narzędzie do optymalizacji, które ułatwia łączenie. Zobacz http://ify.io/using-requirejs-with-optimization-for-lazy-loading-angularjs-artefacts/

Tak, sensowne jest użycie wymagaJS z Angularem, spędziłem kilka dni na testowaniu kilku rozwiązań technicznych.

Zrobiłem Angular Seed z RequireJS po stronie serwera. Bardzo prosty. Używam notacji SHIM dla żadnego modułu AMD, a nie AMD, ponieważ myślę, że bardzo trudno jest poradzić sobie z dwoma różnymi systemami wstrzykiwania zależności.

Używam grunt i r.js do łączenia plików js na serwerze w zależności od pliku konfiguracyjnego (zależności) SHIM. Odsyłam więc tylko jeden plik js w mojej aplikacji.

Aby uzyskać więcej informacji, odwiedź mój github Angular Seed: https://github.com/matohawk/angular-seed-requirejs

Unikałbym używania Require.js. Aplikacje, które widziałem, które to robią, kończą się bałaganem wielu rodzajów architektury wzorców modułów. AMD, Revealing, różne wersje IIFE itp. Istnieją inne sposoby ładowania na żądanie, takie jak mod Angular loadOnDemand . Dodanie innych rzeczy po prostu wypełnia twój kod pełen cruft i tworzy niski stosunek sygnału do szumu i sprawia, że ​​kod jest trudny do odczytania.

Oto moje podejście: http://thaiat.github.io/blog/2014/02/26/angularjs-and-requirejs-for-very-large-applications/

Strona pokazuje możliwą implementację AngularJS + RequireJS, gdzie kod jest podzielony według funkcji, a następnie typu komponentu.

Odpowiedź Briana Forda

AngularJS ma własny system modułowy i zwykle nie potrzebuje czegoś takiego jak RJS.

Odniesienie: https://github.com/yeoman/generator-angular/issues/40

Myślę, że zależy to od złożoności projektu, ponieważ kątowość jest właściwie zmodularyzowana. Twoje kontrolery można zmapować i możesz po prostu zaimportować te klasy JavaScript na stronie index.html.

Ale na wypadek gdyby Twój projekt stał się większy. Lub przewidujesz taki scenariusz, powinieneś zintegrować grę kątową z wymaganiami. W tym artykule możesz zobaczyć aplikację demonstracyjną do takiej integracji.