blogg-vitalika.ru

  

Bästa artiklarna:

  
Main / Moduler var som helst parameterdefinition

Definitioner av parametrar var som helst

Vinkelmoduler är ett ganska komplext ämne. Angular team har gjort ett bra jobb med att lägga upp en ganska lång dokumentationssida på NgModule som finns här. Det ger en klar förklaring till de flesta ämnen men vissa områden saknas fortfarande och missförstås därför ofta av utvecklare. Den här artikeln ger en sådan fördjupad förklaring och klargör vanligt missförstånd som jag ser varje dag vid stackoverflow.

Angular introducerar konceptet modulinkapsling på ett sätt som liknar ES-moduler. Till exempel, om jag försöker använda a-comp från A-modulen inuti App-komponenten från App-modulen :. Om jag vill använda den här komponenten måste jag importera modulen där den här komponenten är definierad.

Detta kan göras så här :. Och här är där inkapsling spelar in. För att denna inställning ska fungera måste A-modulen deklarera a-comp som offentlig genom att lägga till den i exportmatrisen :. Om du använder dynamiska vyer och dynamiska komponenter instantiering som beskrivs i Här är vad du behöver veta om dynamiska komponenter i Angular kan du använda komponenter från A-modulen utan att lägga till dem i exportmatrisen.

Naturligtvis måste du fortfarande importera A-modulen. Men det finns ingen. En leverantör som deklareras i alla moduler som inte är lata kan nås var som helst i applikationen. Och följande kapitel förklarar varför. Den största förvirringen när det gäller importerade moduler är att utvecklare tror att de skapar en hierarki. Alla moduler slås samman under sammanställningsfasen. Precis som med komponenter genererar Angular compiler en fabrik för rotmodulen. Rotmodulen är den som du anger i metoden bootstrapModule i huvudsak.

Fabriken som Angular compiler genererar använder createNgModuleFactory-funktionen som tar :. Du har bara sammanfogat modulen. Anta att du har A- och B-moduler som definierar var och en en leverantör och en inmatningskomponent :. App-rotmodulen definierar också en leverantör och en root-appkomponent och importerar A- och B-modulerna :. När kompilatorn genererar en modulfabrik för App-rotmodulen slås den samman leverantörer från alla moduler och skapar en fabrik endast för den här sammanslagna modulen.

Så här ser den här fabriken ut :. Du kan se att leverantörerna och postkomponenterna från alla moduler slås samman och skickas till moduleDef-funktionen. Så oavsett hur många moduler du importerar skapas bara en fabrik med sammanslagna leverantörer. Denna fabrik används för att skapa en modulinstans med en egen injektor. Nu kanske du undrar vad som händer om du definierar två moduler med samma leverantörstoken? Den första regeln är att leverantören som definieras i modulen som importerar annan modul alltid vinner.

Den andra regeln är att leverantören från den senast importerade modulen åsidosätter leverantörer i de föregående modulerna som förväntas för den importerande modulen följer av den första regeln. Så nu importerar App-moduler A- och B-moduler i följande ordning :.

Okej, det bevisar regeln. Leverantören innehåller b-värde som specificerades på B-modulen. Japp, allt som förväntat. Eftersom vi bytte moduler nu åsidosätter leverantören en från en modul leverantören med samma symbol från B-modulen. Här är vad den officiella dokumentationen säger om dem :.

Så vi vet att Angular skapar en egen injektor för de lata laddade modulerna. Detta händer eftersom Angular genererar en separat fabrik för varje laddad modul. Det betyder att leverantörer som definieras i en sådan modul inte slås samman till huvudmodulinsprutaren.

Alla importerade moduler slås fortfarande samman till en fabrik under sammanställningen på samma sätt som med icke-lata moduler. Här är den relevanta källkoden från RouterConfigLoader som laddar lata moduler och skapar injektorhierarki :.

Där varje importerad modul CarouselModule, CheckboxModule etc. ser jag ingen anledning att använda förRoot här. När du importerar en modul använder du vanligtvis en referens till modulklassen :.

På detta sätt läggs alla leverantörer som definieras på modul A till i rotinjektorn och kommer att vara tillgängliga för hela applikationen. Angular stöder också ett annat sätt att registrera en modul hos leverantörer. Istället för att klara modulklassreferensen kan du skicka ett objekt som implementerar ModuleWithProviders-gränssnittet :. Här är hur vi kan använda denna metod för vårt exempel ovan :. Och istället för att importera och använda objektreferensmodulenWithProviders direkt är det bättre att definiera en statisk metod på en modulklass som returnerar objektet.

Det var bara för demonstrationsändamål. Det är meningsfullt när vi vill dela våra leverantörer och definiera olika uppsättningar leverantörer beroende på var vår modul kommer att importeras till. Till exempel vill vi tillhandahålla global A-tjänst för icke-lat laddad modul och B-tjänst för en lat laddad modul. Nu är det vettigt att använda metoden ovan. Vi använder metoden forRoot för att returnera leverantörer för modulen som inte är lata och ForChild för modulen som är lata :.

Eftersom icke-lat laddade moduler slås samman, kommer de leverantörer du anger i forRoot att vara tillgängliga för hela applikationen. Men eftersom laddade moduler har sina egna injektorer, kommer de leverantörer du anger i forChild endast tillgängliga för injektion i den här laddade modulen. Så komma tillbaka till vårt exempel ovan :. Eftersom detta bara är enkla metoder kan du skicka valfritt alternativ eller ytterligare leverantörer när du ringer till dem.

Ett bra exempel här är RouterModule. Det definierar forRoot-metoden som tar både ytterligare leverantörer och konfiguration :. Och alternativ som du skickar som den andra parametern används för att konfigurera andra leverantörer :. Som du kan se använder RouterModule metoderna forRoot och forChild för att dela leverantörsuppsättningen och även för att konfigurera den baserat på de godkända alternativen. Ibland dyker en ny fråga upp vid stackoverflow från en utvecklare som är orolig för att import av en modul till både lat och icke-lat modul kommer att resultera i duplicering av en modulkod under körning.

Men ingen anledning att oroa dig eftersom alla befintliga modullastare cachar modulen de laddar. När SystemJS laddar en modul placeras den i cachen. Detta är processen som händer för varje modul. Du refererar till paketet många gånger i applikationen. Den laddar den en gång och cachar den. Något liknande händer med Webpack om du använder vinkel-cli eller konfigurerar webbpaketet själv. Den innehåller modulkoden bara en gång i ett paket och ger den ID. Alla andra moduler importerar symboler från den här modulen med detta ID.

Logga in Kom igång. Om Support Us ag-Grid: 9 aug 2017. Modulinkapsling Angular introducerar konceptet modulinkapsling på ett sätt som liknar ES-moduler. Till exempel, om jag försöker använda a-comp från A-modulen inuti App-komponenten från App-modulen: Template-fel: Detta kan göras så här: För att denna inställning ska fungera måste A-modulen deklarera a-comp som offentlig genom att lägga till den i exportmatrisen: Modulhierarki Den största förvirringen när det gäller importerade moduler är att utvecklare tror att de skapar en hierarki.

Anta att du har A- och B-moduler som var och en definierar en leverantör och en inmatningskomponent: Så här ser den här fabriken ut: Här är vad den officiella dokumentationen säger om dem: Angular skapar en lat laddad modul med en egen injektor, ett barn av rotinjektorn ... Så en lat laddad modul som importerar den delade modulen gör sin egen kopia av tjänsten. Här är den relevanta källkoden från RouterConfigLoader som laddar lata moduler och skapar injektorhierarki: Lägg till en CoreModule.

När du importerar en modul använder du vanligtvis en referens till modulklassen: I stället för att skicka modulklassreferensen kan du skicka ett objekt som implementerar ModuleWithProviders-gränssnittet: A, leverantörer: Vi använder metoden forRoot för att returnera leverantörer för icke-lat laddad modul och forChild för lat laddad modul: Observera att namnen på metoder som du använder för att returnera ModuleWithProviders-strukturen kan vara helt godtyckliga. Namnen på Child och forRoot som jag använde i exemplen ovan är bara konventionella namn som rekommenderas av Angular-teamet och används i RouterModule-implementeringen.

Så att komma tillbaka till vårt exempel ovan: Det definierar forRoot-metoden som tar både ytterligare leverantörer och konfiguration: Routes, config ?: RouterModule, providers: PreloadingStrategy, useExisting: Module caching Ibland dyker en ny fråga upp på stackoverflow från en utvecklare som är orolig att importera en modul till både lat och icke-lat modul kommer att resultera i duplicering av en modulkod under körning.

(с) 2019 blog-vitalika.ru