innan ES6 hade Javascript modulkontrollsystem som RequireJS, CommonJS och Angular ’ s Dependency injection system. Andra verktyg som Browserify och Webpack själv har löst många problem i detta sammanhang.
i 2015 hade vi en första implementering av modulsystemet i vanilj Javascript för nod.js använder require vi vet alla. Men det här har ännu inte kommit till webbläsare.
strikt läge
innan något vi behöver prata lite om strikt läge., Utan det kan vi inte prata absolut ingenting om moduler.
strikt läge är aktiverat som standard när vi arbetar med ES6 moduler, om du fortfarande inte vet vad strikt läge är, kommer jag att ge en grundläggande introduktion.,ad6″>, I Anropet av metoder är inte längre tvungen att göra en Object
Det är inte möjligt att använda fn.caller och fn.arguments, för att komma åt stacken, JavaScript
reserverade ord (till exempel protectedinterface) lider inte av bind
om du inte har en ledtråd ska du använda i 'use strict', på alla rätt ställen blir det standard i ES6, det är fortfarande en bra praxis att använda den varje gång. – herr talman!,
Export
No modelo CommonJS podemos exportar valores atribuindo eles ao module.exports como no snippet abaixo:
Sintaxe atual
No ES6, os módulos são arquivos que dão export uma API (basicamente igual ao CommonJS)., Deklarationerna, variablerna, funktionerna och allt från den modulen finns endast i modulens omfattning, vilket innebär att alla variabler som deklareras inom en modul inte är tillgängliga för andra moduler (såvida de inte uttryckligen exporteras som en del av API: n och senare importeras till den modul som använder dem).,
exportera standard
Du kan simulera beteendet hos en CommonJS i princip, ersätta module.exports med en export default:
Syntaxmodulen
å andra sidan av modulerna i CommonJS, deklarationerna i export, kan endast placeras på toppnivån i din kod, och inte i någon del av den., Vi antar att denna begränsning finns för att göra livet enklare för tolkar när de ska identifiera moduler, men om man tittar på det är det en mycket giltig begränsning, eftersom det inte finns många bra skäl för oss att definiera dynamisk export inom våra API-funktioner.
en annan anledning till detta finns i talet om vår kära vän William Grasel under Intercon 2017, på web app performance (som finns här).,
han säger att ett av sätten att förlänga dess prestanda är att använda moduler, det beror på att modulerna sammanställs statiskt och innan din kod ens passerar till webbläsarens tolk (som V8 till exempel). På detta sätt är det möjligt att extrahera endast de delar av koden som faktiskt används i ansökan istället för att importera hela modulen, och detta skulle bara vara möjligt om modulerna deklarerades på toppnivå, eftersom något inuti en funktion skulle bli något dynamiskt, inte statiskt.,
namngiven export
i CommonJS kan vi helt enkelt skapa variabelbindningar direkt i module.exportssom sedan kommer att ha egenskaperna uppdaterade i realtid:
module.exports.foo = 'bar'
module.exports
module.exports.foo = 'bar'
kan vi deklarera alla variabler vi vill exportera.,
Observera att koden nedan är inte att vara omstrukturerade för att extrahera deklaration av en variabel på en enda rad (och sedan använda den i en export foo), det kommer att ge oss ett fel i syntaxen, men, mer och mer ES6 för statisk analys, i stället för de kassaflöden, dynamisk:
export var foo = 'bar'
det Är viktigt att hålla i minnet att vi är exportanto bindings, det finns inga värden.
bindningar., Inte värden
en viktig punkt att notera är att moduler i ES6 inte exporterar värden eller referenser, utan snarare bindningar av variabler. Detta innebär i praktiken att en variabel som heterfoo, som exporteras, kommer att ha en länk till modulensfoo variabel, och de värden som tilldelats dem kommer att bli föremål för de värdeförändringar som gjorts ifoo.,=”ef1b1c4fb0″>,
och exportlistor
som du kan se nedan låter modulerna i ES6 exportemos listorna över de medlemmar som utsetts till toppnivå:
exportlistor
om du föredrar att exportera det till något med ett annat namn som du kan använda i export { foo as fuz }, som visas nedan:
utöver detta kan du ange något liknande default, när du vill exportera det till något med ett annat namn listorna heter., Koden nedan är samma sak som att göra en export default foo och efter export bar, men det är i en unik position:
export { foo as default, bar }
det är dock en bra idé att bara använda en export default I slutet av filen.
bästa praxis i linje med exporten
alla möjligheter att exportera modulen kommer att introducera en hel del förvirring i människornas sinnen. I de flesta fall uppmuntras det att endast använda en export default (och gör detta endast i slutet av modulen)., Då kan du importera API som namnet på modulen själv.
fördelarna är:
gränssnittet som exporteras blir mycket uppenbart, snarare än att behöva leta efter var vi exporterar gränssnittet inuti modulen.
du skapar inte förvirring om var du ska använda enexport default eller en namngiven export (eller en lista över namngivna export). Försök att hålla fast vid konsistensenexport default
. I CommonJS är det normalt att använda en enda metod i en modul., Att göra detta med namngiven export är omöjligt eftersom du kommer att exponera ett objekt med en metod inuti, om du inte använderas default I listan export. Har redan export default, vilket är den mest mångsidiga, eftersom du kan exportera bara en sak.
använd
blirimport snabbare
Import
import, vilket är motsvarigheten iexport, det kan också användas för att ladda en modul från den andra.,
först och främst beror hur moduler laddas på genomförandet av varje plats. För närvarande ingen webbläsare implementerar en lastare.
för att kringgå vad som sagts ovan är det möjligt att använda resurser som transpilers (som Babel), för att skriva ES6-kod medan utvecklingsteam i webbläsarna oroar sig för hur man får laddningen av moduler att fungera.
ett coolt exempel är lodash., Följande rad laddar helt enkelt lodash-biblioteket inuti vår modul. Det skapar dock inga variabler. Det kommer att utföra någon kod på toppnivå Lodash.
import 'lodash'
innan vi går vidare, en snabb anteckning:
import precis somexport är endast tillåtet på toppnivå av modulen, och inte inom andra omfattningar, förmodligen av samma skäl som jag sa ovan.,
importerar standardvärden
i CommonJS har vi en import medrequire:
var _ = require('lodash')
för att importera enexport default från en annan modul med ES6 behöver vi bara välja ett namn. Syntaxen ändras lite eftersom du inte importerar själva objektet, utan en bindning., Och det gör det enkelt för analys:
import _ from 'lodash'
oavsett exporten den namngivna
syntaxen är mycket lik den som används ovan:
import { map, reduce } from 'lodash'
det är mycket lik den förstöringstilldelningen, som vi har i den nya specifikationen.,namnet importerar, med export till standarder utan användning av nycklarna (men tyvärr kommer du inte att kunna ge ett alias till dem.
blanda alla
se vår import av mönster kan visas på utsidan av nyckeln.
importera alla
om du vill importera namnområdet för en modul., Till skillnad från den namngivna importen eller defaults importerar den allt.
Observera att syntaxen nedan måste följas av ett alias där alla bindningar kommer att placeras. (Export till standarder ska placeras i alias.default):
import * as _ from 'lodash'
bindning _.default kommer att vara innehållet i export default LoDash
slutsats
var noga med att följa mer av mitt innehåll på min blogg och registrera dig till nyhetsbrevet för att få veckovisa nyheter!,
med detta stänger vi en annan guide på ES6! Jag rekommenderar starkt att läsa mer innehåll om ämnet, och även fördjupa eftersom detta är en spec som är att komma i alla webbläsare och måste användas för att optimera allt vi har idag!,
Några resurser bacanas são:
Livro cangaceiro JavaScript
Livro SS6
Kurs SS6 göra William Justen
Kurs SS6 kom Webpack göra José Bernardo Cunha
PonyFoo (de onde eu tirei muito göra material deste artigo, främst os exemplos)
Sida gör MDN på importera
Blogg 2ality på moduler (de onde veio também algum material deste artigo)