Ez egyike volt azoknak a napoknak, amikor az irodai projektem új funkcióinak kidolgozásával foglalkoztam. Hirtelen valami lekötötte a figyelmemet:

A DOM vizsgálata során láttam, ngcontent
hogy az Angular alkalmazza az elemeket. Hmm ... ha ezek tartalmazzák az elemeket a végső DOM-ban, akkor mi haszna van ? Abban az időben összezavarodtam
és között
.
A kérdéseimre adott válaszok megismerése során felfedeztem a koncepciót . Meglepetésemre volt
*ngTemplateOutlet
. Elkezdtem utamat, hogy tisztázzam két fogalmat, de most már négy is volt, közel azonos hangzásúnak!
Voltál már ilyen helyzetben? Ha igen, akkor jó helyen jár. Tehát minden további nélkül vegyük őket egyenként.
1.
Ahogy a neve is sugallja az egy sablon elem, amely szögletes felhasználási strukturális irányelvek (
*ngIf
, *ngFor
, [ngSwitch]
és egyedi irányelvek).
Ezek a sablon elemek csak strukturális irányelvek jelenlétében működnek . A szögletes befogja a gazdagépet (amelyre az irányelvet alkalmazzák) belülre,és
a kész DOM-banelfogyasztja, diagnosztikai megjegyzésekkel helyettesítve.
Vegyünk egy egyszerű példát *ngIf
:

Fent látható a *ngIf
. Az Angular beleteszi a host elemet, amelyre az irányelvet alkalmazzák, és a hostot a jelenlegi állapotában tartja. A végső DOM hasonló ahhoz, amit a cikk elején láttunk:

Használat:
Láttuk, hogy az Angular hogyan használja, de mi van, ha használni akarjuk? Mivel ezek az elemek csak strukturális irányelvekkel működnek, így írhatunk:

Itt home
van boolean
az true
értékre beállított összetevő egyik tulajdonsága . A fenti kód kimenete a DOM-ban:

Semmi sem lett renderelve! :(
De miért nem láthatjuk üzenetünket akkor sem, ha a strukturális irányelvekkel helyesen alkalmazzuk?
Ez volt a várt eredmény. Amint arról már volt szó, az Angular a diagnosztikai megjegyzésekkel helyettesíti . Kétségtelen, hogy a fenti kód nem generál hibát, mivel az Angular tökéletesen megfelel a használati esettel. Soha nem fogod megtudni, mi történt pontosan a kulisszák mögött.
Hasonlítsuk össze a fenti két DOM-ot, amelyeket az Angular renderelt:


Ha alaposan figyel, van egy további megjegyzés címke a 2. példa utolsó DOM-jában . Az Angular által értelmezett kód a következő volt:

A szögletes befogadta a gazdáját egy másikba,
és nemcsak a külsőt
a diagnosztikai megjegyzésekbe, hanem a belsőbe is átalakította ! Ezért nem láthatta egyik üzenetét sem.
Ennek megszabadulásához kétféleképpen érheti el a kívánt eredményt:

1. módszer:
Ebben a módszerben az Angular szolgáltatást nyújtja a cukrozatlan formátumnak, amely nem igényel további feldolgozást. Ezúttal az Angular csak megjegyzésekké konvertál , de a benne lévő tartalmat érintetlenül hagyja (már nincsenek benne,
mint az előző esetben). Így helyesen jeleníti meg a tartalmat.
Ha többet szeretne megtudni arról, hogyan használhatja ezt a formátumot más strukturális irányelvekkel, olvassa el ezt a cikket.
2. módszer:
Ez egy egészen láthatatlan formátum, és ritkán használják (két testvér használatával ). Itt adunk egy sablon hivatkozást a-ra
*ngIf
, then
hogy megmondjuk, melyik sablont kell használni, ha a feltétel igaz.
Ilyen többszörös használata nem ajánlott (használhatná
helyette is), mivel nem erre szolgálnak. Tárolóként használják azokat a sablonokat, amelyek több helyen újrafelhasználhatók. Erről bővebben a cikk egy későbbi szakaszában foglalkozunk.
2.
Írt vagy látott már ehhez hasonló kódot:

Az ok, amiért sokan írjuk ezt a kódot, az, hogy nem tudunk több strukturális irányelvet használni egyetlen gazdaelemre az Angularban. Most ez a kód jól működik, de több extra üreset vezet be a DOM-ban, ha
item.id
ez olyan hamis érték, amelyre esetleg nincs szükség.

Lehet, hogy nem egy ilyen egyszerű példa miatt aggódik, de egy hatalmas alkalmazás, amely komplex DOM-mal rendelkezik (több tízezer adat megjelenítésére), ez problémát okozhat, mivel az elemekhez csatolhatnak hallgatók, amelyek továbbra is ott lesznek a DOM eseményeket hallgat.
Ami még rosszabb, az a fészkelés szintje, amelyet meg kell tennie a stílus (CSS) alkalmazásához!

Semmi gond, nekünk kell megmentenünk!
Az Angular olyan csoportosító elem, amely nem zavarja a stílusokat vagy az elrendezést, mert az Angular nem teszi be a DOM-ba .
Tehát ha az 1. példát a következővel írjuk :

A végső DOM-ot így kapjuk meg:

Lásd, megszabadultunk azoktól az üres s-től. Akkor kell használnunk,
amikor csak több strukturális irányelvet akarunk alkalmazni, anélkül, hogy bármilyen további elemet vezetnénk be a DOM-ba.
További információ: doc. Van még egy olyan eset, amikor a sablont dinamikusan injektálják egy oldalra. A cikk utolsó szakaszában kitérek erre a felhasználási esetre.
3.
Konfigurálható összetevők létrehozására szolgálnak. Ez azt jelenti, hogy az összetevőket a felhasználó igényeitől függően lehet konfigurálni. Ez közismert nevén Tartalomvetítés . A közzétett könyvtárakban használt összetevők felhasználják magukat konfigurálhatóvá.
Vegyünk egy egyszerű összetevőt:


A komponens nyitó és záró címkéin belül átadott HTML tartalom a kivetítendő tartalom. Ezt hívjuk Tartalom-vetítésnek . A tartalom
az alkatrész belsejében jelenik meg . Ez lehetővé teszi az
összetevő fogyasztójának, hogy átadjon minden egyedi láblécet az összetevőn belül, és pontosan ellenőrizhesse , hogyan szeretné megjeleníteni.
Több vetítés:
Mi lenne, ha el tudná dönteni, hogy melyik tartalmat hová kell elhelyezni? Az egyes tartalmakba vetített egyetlen tartalom helyett a . Attribútummal is szabályozhatja, hogy a tartalom hogyan fog kivetülni . Elemválasztó szükséges ahhoz, hogy eldöntse, melyik tartalmat kívánja kivetíteni egy adott részen belül .
select
Itt van, hogyan:

Módosítottuk a definíciót a több tartalmú vetítés végrehajtására. Az
select
attribútum kiválasztja az adott tartalomban megjelenítendő tartalom típusát . Itt először meg
select
kell adnunk a fejléc h1
elemet. Ha a kivetített tartalomnak nincs h1
eleme, az nem fog semmit megjeleníteni. Hasonlóképpen a második select
a div
. A tartalom többi része az utolsó belsejében jelenik meg, a nem
select
.
A komponens hívása a következőképpen fog kinézni:

4. * ngTemplateOutlet
… Sablonokként használják azokat a sablonokhoz, amelyeket több helyen is fel lehet használni. Erről bővebben a cikk egy későbbi szakaszában foglalkozunk.... Van egy másik felhasználási eset, amikor a sablont dinamikusan injektálják egy oldalra. A cikk utolsó szakaszában kitérek erre a felhasználási esetre.
Ebben a részben tárgyaljuk a fent említett két fenti pontot. *ngTemplateOutlet
két forgatókönyv esetén használatos - közös sablon beillesztése a nézet különböző szakaszaiba, ciklusoktól és feltételektől függetlenül, és egy jól konfigurált összetevő készítése.
Sablon újrafelhasználása:
Vegyünk egy nézetet, ahol több helyre be kell illeszteni egy sablont. Például egy vállalati embléma, amelyet egy weboldalon kell elhelyezni. Úgy érhetjük el, hogy egyszer megírjuk a logó sablonját, és a nézeten belül mindenhol újrafelhasználjuk.
A következő kódrészlet:

Mint látható, most írtuk egyszer a logó sablont, és háromszor használtuk ugyanazon az oldalon egyetlen kódsorral!
*ngTemplateOutlet
elfogad egy kontextus objektumot is, amely átadható a közös sablon kimenet testreszabásához. A kontextus objektummal kapcsolatos további információkért lásd a hivatalos dokumentumokat.
Testreszabható alkatrészek:
A második felhasználási eset a *ngTemplateOutlet
nagymértékben testreszabott alkatrészek. Tekintsük az előző példát a komponensről néhány módosítással:

Fent van a módosított változata komponens, amely elfogadja a három bemeneti tulajdonságok -
headerTemplate
, bodyTemplate
, footerTemplate
. A következő a részlet project-content.ts
:

Mi próbálunk elérni itt, hogy megmutassuk fejléc, törzs és a lábléc, amint megkapja a szülő eleme . Ha egyikük nincs megadva, összetevőnk az alapértelmezett sablont fogja megjeleníteni a helyén. Így egy nagymértékben testreszabott komponens létrehozása.
A nemrégiben módosított komponensünk használata:

Így adjuk át a sablon hivatkozásokat az összetevőnknek. Ha egyiküket sem adják át, akkor az összetevő megjeleníti az alapértelmezett sablont.
ng-content vs. * ngTemplateOutlet
Mindketten segítenek a nagymértékben testreszabott alkatrészek elérésében, de melyiket válasszuk és mikor?
Jól látható, hogy *ngTemplateOutlet
némi nagyobb hatalmat biztosítunk az alapértelmezett sablon megjelenítéséhez, ha nincs megadva.
Ez nem így van ng-content
. A tartalmat úgy jeleníti meg, ahogy van. Az select
attribútum segítségével legfeljebb feloszthatja a tartalmat, és megjelenítésének különböző helyein jelenítheti meg azokat . A tartalmat nem lehet feltételesen megjeleníteni a belül ng-content
. Meg kell mutatnia azt a tartalmat, amelyet a szülőtől kapott, semmilyen eszköz nélkül nem hozhat döntéseket a tartalom alapján.
A kettő közül való választás azonban teljesen a felhasználási esetétől függ. Legalább most van egy új fegyver *ngTemplateOutlet
az arzenálunkban, amely a tartalom jobb ellenőrzését teszi lehetővé a ng-content
!