2014-07-03 13 views
5

Byłem readingaboutes6 module loaders i po prostu nie bardzo rozumiem, jak to działa i mam nadzieję, że ktoś może mnie oświecić.Jak działa ładowanie modułu es6

w praktycznym workflow odwołuje powyżej mają przykład jak ten

System.import('app/app').then(function(app) { 
    // app is now the Module object with exports as getters 
}); 

ma z tym problemu - rozumiem. Ale potem widzę rzeczy takie jak ten i się bardzo zagmatwałem. Co się stanie, jeśli w czasie tego połączenia jquery nie zostało jeszcze przeniesione do przeglądarki? Czy wątek się kręci? Czy przeglądarka analizuje twój skrypt za kulisami i zmienia go w wywołanie zwrotne, tak jak robi to RequireJs? Czy to, co można konfigurować? Czy istnieją określone ograniczenia?

Czy ktoś może mi pomóc?

+1

Druga rzecz, którą widzisz to "ładowanie modułu CommonJS", a nie ES6 afaik. Naprawdę [nie działa (dobrze) w require.js] (http://requirejs.org/docs/api.html#cjsmodule) – Bergi

+0

@Bergi działa poprawnie w require.js, a ja nie wolę tego istnieją pewne strony w moim bieżącym projekcie, które używają requirejs ze stylem commonjs. Requirejs skanuje twój skrypt pod kątem wyrażeń commonjs i przepisuje go na format amd, dlatego nadal używa callbacków. Jednakże, o ile się nie mylę, propozycja es6 NIE używa callbacków - stąd moje zamieszanie. –

+0

Tak, a skanowanie skryptu nie działa dobrze we wszystkich, oprócz najprostszych przypadkach. Czy możesz powiązać część propozycji ES6, którą masz na myśli? 'System.import' oczywiście używa zwrotów. – Bergi

Odpowiedz

4

Moduł ładujący modułu ES6 pobierze źródło, określi zależności i poczeka, aż te zależności zostaną załadowane przed uruchomieniem modułu. Tak więc, do czasu wykonania żądania, zależność już czeka na wykonanie.

Podczas ładowania CommonJS przez moduł ładujący modułu ES6, polegamy na statycznym analizowaniu instrukcji require ze źródła i uruchamianiu źródła tylko po załadowaniu tych wymagań.

W ten sposób możemy wesprzeć CommonJS w przeglądarce ładowanej dynamicznie. Odwołania kołowe są traktowane identycznie, jak są obsługiwane w węźle.

Wyrażenia regularne analizujące wymagania są w rzeczywistości dość niezawodne i szybkie, z uwzględnieniem komentarzy i otaczających tokenów. Zobacz https://github.com/systemjs/systemjs/blob/master/lib/extension-cjs.js#L10 dla tego używanego przez SystemJS.

Jest jedno pozostałe ograniczenie z tym podejściem, które jest dynamiczne i warunkowe CommonJS wymaga takich jak if (condition) require('some' + 'name') nie są wykrywane poprawnie. Jest to jednak konieczny koszt, aby CommonJS zachowywał się w pełni asynchronicznym formatem modułu w przeglądarce.

+1

Jakiś czas po napisaniu tego pytania otrzymaliśmy [ten niesamowity artykuł na temat modułów es6] (http://www.2ality.com/2014/09/es6-modules-final.html). Jest to wprost sprzeczne z niektórymi z twoich wypowiedzi (np. Analiza składni regex, sposób działania zależności cyklicznych i dostępność dynamiczna). Wydaje się również, że niektóre z moich nieporozumień są takie, że moduły i moduły ładujące są osobnymi specyfikacjami, z których tylko pierwsza jest ukończona. –

+2

Moduł ładujący modułu ES6 ma dwa sposoby interpretacji modułów: 1. Moduły ES6 2. Wcześniejsze formaty modułów Możemy budować w starszym formacie modułu do modułu ładującego modułu ES6 poprzez hak zwany "instancją". Masz rację - ładowanie modułu ES6 ma swój własny styl odwołania, który różni się od CommonJS. Podczas pisania wsparcia CommonJS do programu ładującego, może to umożliwić pełne odwołanie do okrągłej obsługi odniesienia w stylu CommonJS. Pod względem specyfikacji, zachowanie klasy modułu ładującego moduł jest w specyfikacji ES6, czym jest osobna specyfikacja, to dokładne przechwytywanie środowiska. – guybedford

Powiązane problemy