Obecnie piszę aplikację internetową przy użyciustos MEAN i próbuję napisać kod w ECMAScript 6 JavaScript; jednak podczas używania składni importu i eksportu pojawiają się błędy zarówno w Chrome, jak i Firefox. Czy istnieją obecnie przeglądarki, które w pełni obsługują ECMAScript 6?
Uwaga: nie pytam, kiedy przeglądarki ECMAScript 6 będą obsługiwane. Pytam, które przeglądarki obsługują składnię importu i eksportu ECMAScript 6. Zobacz https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla#Features_not_yet_supported_by_Firefox
Odpowiedzi:
10 dla odpowiedzi № 1Obsługa Chrome i Firefox import i export składnia (istnieją testy dla właściwy rozbiór gramatyczny zdania).
To, co nie jest obsługiwane, to ładowanie modułu - tynie można załadować modułu w żaden sposób, ponieważ specyfikacja dla niego nie jest kompletna. W tym celu musisz użyć jakiegoś modułu do pakowania modułów. Nie jestem front-endowym deweloperem, ale słyszałem o nim dobre opinie Rollup od moich współpracowników.
28 dla odpowiedzi nr 2
Obsługiwany jest w:
- Safari 10.1
- Chrome 61
- Firefox 54 - za ustawieniem dom.moduleScripts.enabled w about: config.
- Edge 16
3 dla odpowiedzi nr 3
Teraz jest pollyfill którego możesz użyć do importowania modułu ES6.
Testowałem to z powodzeniem na Chrome.
Tutaj jest link: http://github.com/ModuleLoader/browser-es-module-loader
Jest również implementowany natywnie w Krawędź 14:
https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond
3 dla odpowiedzi № 4
Jak powiedzieli inni, wsparcie jest nadal bardzo ograniczone. Ale nawet gdyby było pełne wsparcie… czy byłoby mądrze z niego skorzystać? Jak byśmy to zrobili?
Pomyśl o tym. Typowa aplikacja JS napisana przy użyciu modułów Node JS z łatwością zawiera dziesiątki, a nawet setki (bardzo małych) pakietów. Czy naprawdę chcemy tak wielu próśb?
Browserify, Webpack, Rollup itp. Są tak popularne, ponieważ pozwalają nam łączyć wiele małych pakietów w jednym szybkim pobieraniu. Z dzielenie kodu możemy pozwolić, aby dostawca modułu zdecydował oczas transpilacji, w oparciu o kod, którego faktycznie używają nasze strony i niektóre ustawienia konfiguracji, liczbę pakietów do utworzenia i co w nich umieścić. W ten sposób możemy napisać wiele mały pakiety i służą jako (kilka) dużych pakietów.
Chodzi mi o to, że powinniśmy podzielić nasz kod napakiety, które działają dobrze na poziomie koncepcyjnym, a następnie łączą je w pakiety, które działają dobrze na poziomie technicznym (sieciowym). Jeśli piszemy nasz kod w oparciu o optymalny rozmiar pakietu sieciowego, w rezultacie poświęcamy modułowość.
W międzyczasie korzystanie z niego prawdopodobnie tylko zwiększy zamieszanie. Na przykład spójrz na przykład na blogu Edge:
import { sum } from "./math.js";
Zwróć uwagę, jak dodają rozszerzenie .js do from strunowy? W Node JS zwykle piszemy to jako:
import { sum } from "./math";
Czy powyższy kod będzie działał również na Edge? A co z nazwanymi pakietami? Obawiam się, że zobaczymy tutaj wiele niezgodności, zanim wymyślimy, jak sprawić, by te ścieżki działały we wszystkich obszarach.
Zaryzykowałbym zgadnięcie, że dla większości programistów System.import pozostanie w większości niewidoczny w przeglądarkach i że tylko oprogramowanie do tworzenia pakietów zacznie go używać (w celu zwiększenia wydajności), gdy stanie się głównym nurtem.
0 dla odpowiedzi № 5
Według Przewodnik po stylu Javascript Google:
Nie używaj jeszcze modułów ES6 (tj
exportiimportsłowa kluczowe), ponieważ ich semantyka nie jest jeszcze sfinalizowana. Pamiętaj, że ta zasada będzie odwiedzimy ponownie, gdy semantyka stanie się w pełni standardowa.
// Don"t do this kind of thing yet:
//------ lib.js ------
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}
//------ main.js ------
import { square, diag } from "lib";
Jednak, import i export są zaimplementowane w wielu transpilerach, takich jak Traceur Compiler, Babel lub Rollup.