Kõik, mida peate teadma ng-template, ng-content, ng-container ja * ngTemplateOutlet nurkades

See oli üks neist päevadest, kui olin hõivatud oma kontoriprojekti uute funktsioonide väljatöötamisega. Ühtäkki köitis mu tähelepanu:

DOM-i kontrollides nägin, kuidas ngcontentAngular rakendas neid elementidele. Hmm ... kui need sisaldavad elemente lõplikus DOM-is, siis millest see kasu on ? Sel ajal ajasin segadusse ja .

Püüdes teada saada vastuseid oma küsimustele, avastasin selle mõiste . Minu üllatuseks oli ka *ngTemplateOutlet. Alustasin oma teekonda, et otsida selgust kahe mõiste kohta, kuid nüüd oli mul neli neist, mis kõlasid peaaegu ühesugused!

Kas olete kunagi selles olukorras olnud? Kui jah, siis olete õiges kohas. Nii et võtame pikema mõtlemiseta need ükshaaval.

1.

Nagu nimigi ütleb, on nurgakujuline mallelement, mida Angular kasutab struktuurdirektiivide ( *ngIf, *ngForja [ngSwitch]ja kohandatud direktiivide) puhul.

Need malli elemendid töötavad ainult struktuuriliste direktiivide olemasolul . Nurk keerab hostelemendi (millele direktiivi kohaldatakse) sisseja tarbibvalmis DOM-is, asendades selle diagnostiliste kommentaaridega.

Mõelge lihtsale näitele *ngIf:

Ülal on näidatud *ngIf. Nurgeline paneb hostelemendi, millele direktiivi kohaldatakse, sisse ja hoiab hostit sellisena, nagu see on. Lõplik DOM on sarnane sellele, mida oleme näinud selle artikli alguses:

Kasutamine:

Oleme näinud, kuidas nurk kasutab, aga mis siis, kui me tahame seda kasutada? Kuna need elemendid töötavad ainult struktuurilise direktiiviga, võime kirjutada järgmiselt:

Siin homeon väärtuseks booleanseatud komponendi omadus true. Ülaltoodud koodi väljund DOM-is:

Midagi pole renderdatud! :(

Aga miks me ei näe oma sõnumit isegi pärast korrektset kasutamist struktuuridirektiiviga?

See oli oodatud tulemus. Nagu me juba arutlesime, asendab Angular diagnostiliste kommentaaridega. Kahtlemata ei tooda ülaltoodud kood ühtegi viga, kuna Angular sobib teie kasutusjuhtumiga täiesti hästi. Sa ei saaks kunagi teada, mis täpselt kulisside taga juhtus.

Võrdleme kahte ülaltoodud DOM-i, mille renderdas nurk:

Lähemalt jälgides on näite 2 viimases DOM- is üks lisakommentaaride silt . Kood, mida Angular tõlgendas, oli:

Nurga all mähkis teie host teise sisse ja teisendas lisaks välistele kommentaaridele ka sisemise! Seetõttu ei saanud te ühtegi oma sõnumit näha.

Sellest vabanemiseks on soovitud tulemuse saamiseks kaks võimalust:

1. meetod:

Selles meetodis pakute Angularile suhkruvaba vormingut, mis ei vaja täiendavat töötlemist. Seekord teisendaks nurgeline ainult kommentaarideks, kuid jätaks selle sees oleva sisu puutumata (need pole enam üheski sees, nagu olid eelmisel juhul). Seega renderdab see sisu õigesti.

Sellest artiklist leiate lisateavet selle kohta, kuidas seda vormingut kasutada koos teiste struktuuriliste direktiividega.

2. meetod:

See on üsna nähtamatu formaat ja seda kasutatakse harva (kasutades kahte õde-venda ). Siinkohal anname mallile viite *ngIfsaidile, thenet öelda, millist malli tuleks kasutada, kui tingimus on tõene.

Selliste mitmete kasutamist ei soovitata (võite selle asemel kasutada ), kuna see pole nende jaoks mõeldud. Neid kasutatakse mallide konteinerina, mida saab mitmes kohas uuesti kasutada. Selle kohta räägime lähemalt selle artikli hilisemas jaotises.

2.

Kas olete kunagi sellele sarnast koodi kirjutanud või näinud:

Põhjus, miks paljud meist selle koodi kirjutavad, on võimetus kasutada nurkade ühe hostelemendi jaoks mitut struktuurdirektiivi. Nüüd töötab see kood hästi, kuid see lisab DOM-i mitu ekstra tühja , kui item.idsee on vale väärtus, mida ei pruugi vaja minna.

Võib-olla ei muretse sellise lihtsa näite pärast, kuid tohutu rakenduse jaoks, millel on keeruline DOM (kümnete tuhandete andmete kuvamiseks), võib see muutuda tülikaks, kuna elementidele võib olla lisatud kuulajaid, mis on endiselt seal DOM sündmuste kuulamine.

Veelgi hullem on pesitsemise tase, mida peate oma stiili (CSS) rakendamiseks tegema!

Pole muret, peame päästma!

Nurk on rühmituse element, mis ei häiri stiile ega paigutust, kuna nurk ei pane seda DOM-i .

Nii et kui kirjutame näite 1 järgmisega :

Lõpliku DOM-i saame järgmiselt:

Näeme, et saime neist tühjadest s lahti . Peaksime kasutama, kui soovime lihtsalt rakendada mitut struktuurdirektiivi, lisamata oma DOM-i täiendavaid elemente.

Lisateavet leiate dokumentidest. On veel üks kasutamisjuhtum, kus seda kasutatakse malli dünaamiliseks sisestamiseks lehele. Ma käsitlen seda kasutusjuhtumit selle artikli viimases jaotises.

3.

Neid kasutatakse konfigureeritavate komponentide loomiseks. See tähendab, et komponente saab konfigureerida sõltuvalt kasutaja vajadustest. See on tuntud kui sisuprojekt . Avaldatud raamatukogudes kasutatavad komponendid kasutavad neid ise konfigureeritavaks muutmiseks.

Mõelge lihtsale komponendile:

Komponendi avamis- ja sulgemissiltide kaudu edastatud HTML-sisu on projitseeritav sisu. Seda me nimetame sisuprojektsiooniks . Sisu renderdatakse komponendi sees . See võimaldab komponendi tarbijal läbida komponendis kõik kohandatud jalused ja kontrollida täpselt, kuidas nad renderdamist soovivad.

Mitu projektsiooni:

Mis oleks, kui saaksite otsustada, milline sisu kuhu paigutada? Iga üksikusse projitseeritud sisu asemel saate ka selectatribuudiga kontrollida, kuidas sisu projitseeritakse . Elemendi valijal on vaja otsustada, millist sisu konkreetses projitseerida .

Nii toimige järgmiselt.

Oleme mitut sisu sisaldava projektsiooni teostamiseks määratlust muutnud . selectAtribuut valib tüüpi sisu, mis renderdatakse sees eriti . Siin peame kõigepealt selectrenderdama päise h1elemendi. Kui projitseeritud sisul pole h1elemente, ei renderda see midagi. Samamoodi selectotsib teine a div. Ülejäänud sisu renderdatakse viimase koos nr-ga select.

Komponendile helistamine näeb välja selline:

4. * ngTemplateOutlet

… Neid kasutatakse mallide konteinerina, mida saab mitmes kohas uuesti kasutada. Selle kohta räägime lähemalt selle artikli hilisemas jaotises.

... On veel üks kasutamisjuhtum, kus seda kasutatakse malli dünaamiliseks sisestamiseks lehele. Ma käsitlen seda kasutusjuhtumit selle artikli viimases jaotises.

See on osa, kus käsitleme kahte ülalnimetatud punkti. *ngTemplateOutletkasutatakse kahe stsenaariumi jaoks - ühise malli lisamiseks vaate erinevatesse osadesse, olenemata tsüklitest või tingimusest, ja kõrgelt konfigureeritud komponendi valmistamiseks.

Malli taaskasutamine:

Mõelge vaatele, kus peate malli lisama mitmesse kohta. Näiteks ettevõtte logo, mis pannakse veebisaidile. Saame selle saavutada, kirjutades logo malli üks kord ja kasutades seda kõikjal vaates.

Järgmine on koodilõik:

Nagu näete, kirjutasime lihtsalt ühe korra logo malli ja kasutasime seda kolm korda samal lehel ühe koodireaga!

*ngTemplateOutletaktsepteerib ka konteksti objekti, mille saab edastada ühise malli väljundi kohandamiseks. Kontekstiobjekti kohta lisateavet leiate ametlikest dokumentidest.

Kohandatavad komponendid:

Teiseks kasutuskohaks *ngTemplateOutleton kõrgelt kohandatud komponendid. Mõelge meie eelmisele komponendi mõnele modifikatsioonile:

Ülal on modifitseeritud versioon komponent, mis võtab kolm sisendi omadused -  headerTemplate, bodyTemplate, footerTemplate. Järgmine on koodilõik project-content.ts:

Mida me siin saavutada tahame, on näidata päist, keha ja jalust sellisena, nagu need on saadud ettevõtte vanemkomponendilt . Kui mõnda neist ei pakuta, kuvab meie komponent selle asemel vaikemalli. Seega luues väga kohandatud komponendi.

Meie hiljuti muudetud komponendi kasutamiseks:

Nii edastame malli viited oma komponendile. Kui mõnda neist ei edastata, renderdab komponent vaikemalli.

ng-sisu vs * ngTemplateOutlet

Need mõlemad aitavad meil saavutada väga kohandatud komponente, kuid milliseid valida ja millal?

Selgelt on näha, et see *ngTemplateOutletannab meile vaikimalli kuvamiseks veel mõne jõu, kui seda pole.

See pole nii ng-content. See renderdab sisu sellisena, nagu see on. Maksimaalselt saate selectatribuudi abil sisu jagada ja renderdada vaate erinevates kohtades . Te ei saa selle sisu tingimustes renderdada ng-content. Peate näitama sisu, mis vanemalt saadakse, ilma et oleks võimalik sisu põhjal otsuseid teha.

Nende kahe vahel valimise valik sõltub aga täielikult teie kasutusjuhtumist. Vähemalt on *ngTemplateOutletmeie arsenalis nüüd uus relv , mis pakub lisaks funktsioonidele ka rohkem kontrolli sisu üle ng-content!