[ad_1]
This can be a very quick and attention-grabbing topic to me. In Angular, each element can have its personal hooked up kinds. Kinds might be in the identical file or in separated recordsdata, just like the templates.
As well as, we are able to encapsulate kinds. There are two strategies of encapsulation: Emulated and ShadowDom. This text describes each kinds of encapsulation and their affect on the efficiency of the entire app.
Earlier than you start, take a look at some Angular dev instruments you possibly can strive in 2023.
Simply earlier than we begin with the “difficult” stuff, I wish to point out one of many myths related to the place the place you’ll be able to put your type.
Just a few occasions, I heard that retaining kinds within the file with logic and the template. It’s straightforward to verify and confirm this fantasy.
First, I created two parts with code like under:
import { Part, OnInit } from '@angular/core';@Part({
selector: 'app-styles',
template: `<p>kinds works!</p>`,
kinds: [`
.app-styles {
display: flex;
}
`]
})
export class StylesComponent implements OnInit {
constructor() { }
ngOnInit(): void {
}
}
I see no purpose to stick right here the content material of the ./style-urls.element.css file. Imagine me that it seems virtually the identical .app-styles CSS class like within the code above. It’s not that necessary in our investigation.
import { Part, OnInit } from '@angular/core';@Part({
selector: 'app-style-urls',
template: `<p>style-urls works!</p>`,
styleUrls: ['./style-urls.component.css']
})
export class StyleUrlsComponent implements OnInit {
constructor() { }
ngOnInit(): void {
}
}
Nothing particular, proper? So, after that, I’ve disabled the minification of the artifacts in angular.json file and run ng construct. This command ought to produce javascript code in /dist listing, and for us essentially the most attention-grabbing file is important.js.
Utilizing your IDE, you’ll be able to seek for traces with StylesComponent and StyleUrlsComponent phrases.
StylesComponent.ɵcmp = /*@__PURE__*/ _angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵdefineComponent"]({ sort: StylesComponent, selectors: [["app-styles"]], decls: 2, vars: 0, template: perform StylesComponent_Template(rf, ctx) { if (rf & 1) {_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementStart"](0, "p");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵtext"](1, " kinds works! ");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementEnd"]();
} }, kinds: [".app-styles[_ngcontent-%COMP%] {n show: flex;n }"] });
// ...
StyleUrlsComponent.ɵcmp = /*@__PURE__*/ _angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵdefineComponent"]({ sort: StyleUrlsComponent, selectors: [["app-style-urls"]], decls: 2, vars: 0, template: perform StyleUrlsComponent_Template(rf, ctx) { if (rf & 1) {
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementStart"](0, "p");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵtext"](1, " style-urls works! ");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementEnd"]();
} }, kinds: [".app-style-urls[_ngcontent-%COMP%] {n show: flex;n}"] });
Yup, the identical consequence for kinds and styleUrls. Do we’d like higher proof that it’s a fantasy and kinds is just not sooner than styleUrls…?
Now we are able to dig deeper into an encapsulation topic.
To verify the variations between the encapsulation sorts, I’m utilizing the identical methodology as within the earlier chapter of this text. I’ve generated three parts, one for every potential worth from ViewEncapsulation enum, I’ve modified the setting within the angular.json and I checked the consequence.
export enum ViewEncapsulation {Emulated = 0,
// Traditionally the 1 worth was for `Native` encapsulation which has been eliminated as of v11.
None = 2,
ShadowDom = 3
}
After this, JavaScript ought to seem like within the code snippet under:
NoEncapsulationComponent.ɵcmp = /*@__PURE__*/ _angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵdefineComponent"]({ sort: NoEncapsulationComponent, selectors: [["app-no-encapsulation"]], decls: 2, vars: 0, template: perform NoEncapsulationComponent_Template(rf, ctx) { if (rf & 1) {_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementStart"](0, "p");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵtext"](1, " no-encapsulation works! ");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementEnd"]();
} }, kinds: ["n .app-no-encapsulation {n display: flex;n }n "], encapsulation: 2 });
// ...
EmulatedComponent.ɵcmp = /*@__PURE__*/ _angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵdefineComponent"]({ sort: EmulatedComponent, selectors: [["app-emulated"]], decls: 2, vars: 0, template: perform EmulatedComponent_Template(rf, ctx) { if (rf & 1) {
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementStart"](0, "p");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵtext"](1, " emulated works! ");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementEnd"]();
} }, kinds: [".app-emulated[_ngcontent-%COMP%] {n show: flex;n }"] });
// ...
ShadowComponent.ɵcmp = /*@__PURE__*/ _angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵdefineComponent"]({ sort: ShadowComponent, selectors: [["app-shadow"]], decls: 2, vars: 0, template: perform ShadowComponent_Template(rf, ctx) { if (rf & 1) {
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementStart"](0, "p");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵtext"](1, " shadow works! ");
_angular_core__WEBPACK_IMPORTED_MODULE_0__["ɵɵelementEnd"]();
} }, kinds: ["n .app-shadow {n display: flex;n }n "], encapsulation: 3 });
Essentially the most seen distinction is after all [_ngcontent-%COMP%] half. It was generated by the compiler, however why?
To verify this, we once more have to return to the Renderer2 class. When you’re new, verify my earlier submit about it.
For every element, I’ve checked the Renderer2 implementation. The outcomes have been:
ViewEncapsulation.Emulated=EmulatedEncapsulationDomRenderer2ViewEncapsulation.None=DefaultDomRenderer2ViewEncapsulation.ShadowDom=ShadowDomRenderer
OK. We all know that for each element with encapsulation set to Emulated Angular generates one thing that was not the in supply code. From CSS, we all know that added half makes these components with class app-emulated and attribute will use this type. It seems suspicious, nevertheless it’s nothing greater than HTML attributed with an odd title.
.app-emulated[_ngcontent-%COMP%] {
show: flex;
}
Figuring out that we might count on that Angular provides that attribute in runtime. Actually, it does. Try the code of EmulatedEncapsulationDomRenderer2 which is utilized by the framework for emulated encapsulation parts.
Two elements of that code are necessary. First, within the constructor, class is producing property contentAttr. This area is used later in overridden methodology createElement, each factor created by this implementation of Renderer2 will add this particular attribute by default.
class EmulatedEncapsulationDomRenderer2 extends DefaultDomRenderer2 {personal contentAttr: string;
personal hostAttr: string;
constructor(
eventManager: EventManager, sharedStylesHost: DomSharedStylesHost,
personal element: RendererType2, appId: string) {
tremendous(eventManager);
const kinds = flattenStyles(appId + '-' + element.id, element.kinds, []);
sharedStylesHost.addStyles(kinds);
this.contentAttr = shimContentAttribute(appId + '-' + element.id);
this.hostAttr = shimHostAttribute(appId + '-' + element.id);
}
applyToHost(factor: any) {
tremendous.setAttribute(factor, this.hostAttr, '');
}
override createElement(dad or mum: any, title: string): Ingredient {
const el = tremendous.createElement(dad or mum, title);
tremendous.setAttribute(el, this.contentAttr, '');
return el;
}
}
I answered the place is the code chargeable for including that attribute, however nonetheless, we’ve one necessary query: WHY?
Principally, it’s quite simple. Angular is including this attribute to CSS code and in runtime to the parts, it’s a very good and native method to make it possible for added type will probably be utilized solely to components from the Angular app scope. You merely aren’t in a position to make use of it someplace exterior the app, for instance, straight in index.html file, since you can not know the title of the attribute earlier than construct.
As I mentioned, a really good method of encapsulating kinds.
A distinct method to encapsulation is to make use of Shadow DOM. To be trustworthy, perhaps I dwell in a really monotonic atmosphere, or it’s very not often used, as a result of I noticed usages of this technique just a few occasions but. The entire thought consumes the Shadow DOM API of the browser, proper now; in response to caniuse.com virtually all fashionable browsers are supporting it.
ShadowDomRenderer in constructor is attaching shadow to the host, and later it appends kinds to created shadow root. There isn’t a have to create bizarre named attributes or one thing, just a few javascript code.
class ShadowDomRenderer extends DefaultDomRenderer2 {personal shadowRoot: any;
constructor(
eventManager: EventManager, personal sharedStylesHost: DomSharedStylesHost,
personal hostEl: any, element: RendererType2) {
tremendous(eventManager);
this.shadowRoot = (hostEl as any).attachShadow({mode: 'open'});
this.sharedStylesHost.addHost(this.shadowRoot);
const kinds = flattenStyles(element.id, element.kinds, []);
for (let i = 0; i < kinds.size; i++) {
const styleEl = doc.createElement('type');
styleEl.textContent = kinds[i];
this.shadowRoot.appendChild(styleEl);
}
}
personal nodeOrShadowRoot(node: any): any {
return node === this.hostEl ? this.shadowRoot : node;
}
override destroy() {
this.sharedStylesHost.removeHost(this.shadowRoot);
}
override appendChild(dad or mum: any, newChild: any): void {
return tremendous.appendChild(this.nodeOrShadowRoot(dad or mum), newChild);
}
override insertBefore(dad or mum: any, newChild: any, refChild: any): void {
return tremendous.insertBefore(this.nodeOrShadowRoot(dad or mum), newChild, refChild);
}
override removeChild(dad or mum: any, oldChild: any): void {
return tremendous.removeChild(this.nodeOrShadowRoot(dad or mum), oldChild);
}
override parentNode(node: any): any {
return this.nodeOrShadowRoot(tremendous.parentNode(this.nodeOrShadowRoot(node)));
}
}
I made a decision to not give attention to this technique so much, as a result of as I discussed earlier, I’m unsure if it’s extremely popular.
If you wish to make investments a while in studying how Shadow DOM is working, right here you’ve gotten an excellent article from MDN; developer.mozilla.org/en-US/docs/Internet/Web_Components/Using_shadow_DOM.
One other attention-grabbing a part of styling that’s value understanding is a part of including kinds to the web page by the framework. Did you ever marvel how Angular is doing that? Are the kinds loaded eagerly utilizing HTML hyperlink tag? Possibly some form of dynamic/lazy loading?
To calm you, after all, element kinds usually are not loading eagerly. It could be doubtlessly straightforward to interrupt the efficiency.
As soon as once more, I’m going to stick some code from Angular sources 🙂 Please forgive me for that, however I nonetheless assume that you shouldn’t belief me. Bear in mind: “Belief the code”.
This time we begin once more with EmulatedEncapsulationDomRenderer2. Within the constructor we’ve only a few issues injected and, one of many arguments is an occasion of sophistication DomSharedStylesHost. Within the third line of the constructor methodology addStyles known as. That is our investigation entry level.
class EmulatedEncapsulationDomRenderer2 extends DefaultDomRenderer2 {personal contentAttr: string;
personal hostAttr: string;
constructor(
eventManager: EventManager, sharedStylesHost: DomSharedStylesHost,
personal element: RendererType2, appId: string) {
tremendous(eventManager);
const kinds = flattenStyles(appId + '-' + element.id, element.kinds, []);
sharedStylesHost.addStyles(kinds);
this.contentAttr = shimContentAttribute(appId + '-' + element.id);
this.hostAttr = shimHostAttribute(appId + '-' + element.id);
}
// ...
}
And naturally, code for it may be discovered within the sources. It’s necessary to know that DomSharedStylesHost extends the category SharedStylesHost, there may be one other class that extends it ServerStylesHost. We are able to assume that this operation is applied in a different way for server aspect rendering configuration.
As all the time I wish to encourage you to verify it, however for now, I’ll give attention to the browser model as a result of it’s in all probability essentially the most generally used implementation.
@Injectable()export class DomSharedStylesHost extends SharedStylesHost implements OnDestroy {
// Maps all registered host nodes to an inventory of fashion nodes which have been added to the host node.
personal _hostNodes = new Map<Node, Node[]>();
constructor(@Inject(DOCUMENT) personal _doc: any) {
tremendous();
this._hostNodes.set(_doc.head, []);
}
personal _addStylesToHost(kinds: Set<string>, host: Node, styleNodes: Node[]): void {
kinds.forEach((type: string) => {
const styleEl = this._doc.createElement('type');
styleEl.textContent = type;
styleNodes.push(host.appendChild(styleEl));
});
}
addHost(hostNode: Node): void {
const styleNodes: Node[] = [];
this._addStylesToHost(this._stylesSet, hostNode, styleNodes);
this._hostNodes.set(hostNode, styleNodes);
}
removeHost(hostNode: Node): void {
const styleNodes = this._hostNodes.get(hostNode);
if (styleNodes) {
styleNodes.forEach(removeStyle);
}
this._hostNodes.delete(hostNode);
}
override onStylesAdded(additions: Set<string>): void {
this._hostNodes.forEach((styleNodes, hostNode) => {
this._addStylesToHost(additions, hostNode, styleNodes);
});
}
ngOnDestroy(): void {
this._hostNodes.forEach(styleNodes => styleNodes.forEach(removeStyle));
}
}
Okay, let’s begin with the constructor. There is just one object injected. It’s the doc international object. Why it’s typed as any…? Most likely there’s a purpose, however I don’t understand it, and I don’t wish to create a brand new fantasy about it
In DomSharedStylesHost class strategies _addStylesToHost and onStylesAdded are used so as to add new <type> factor with the kinds contend when it’s needed.
However when it’s needed…? Nice query!
Angular has so as to add type when addStyles methodology has been known as (look again to the constructor of the EmulatedEncapsulationDomRenderer2). This methodology is applied within the SharedStylesHost base class.
Try the code bellow.
@Injectable()export class SharedStylesHost {
/** @inside */
protected _stylesSet = new Set<string>();
addStyles(kinds: string[]): void {
const additions = new Set<string>();
kinds.forEach(type => {
if (!this._stylesSet.has(type)) {
this._stylesSet.add(type);
additions.add(type);
}
});
this.onStylesAdded(additions);
}
onStylesAdded(additions: Set<string>): void {}
getAllStyles(): string[] {
return Array.from(this._stylesSet);
}
}
From the implementation of the tactic whe know few issues:
- There’s a international set object that retains all of the kinds added to the appliance.
- Kinds are all the time filtered utilizing this set, so Angular won’t ever add the identical type twice.
- On the finish of the tactic
onStylesAddedknown as, and it’ll name one of many “browser” or “server” implementations.
Sadly, you can’t use SharedStylesHost by your self so as to add kinds “manually”. This class is just not part of Angular public API, and it’s not exported.
On the finish, the code could be very easy, and you may implement it in your mission. Why…? A great use case it once you wish to load the kinds dynamically with the code and webpack dynamic imports.
I described all of the encapsulation kinds supplied by the Angular framework. After studying tons of the code, it’s time to match the efficiency of every methodology.
As all the time, I create a repository with silly easy software that can be utilized for testing functions. You could find it right here github.com/galczo5/experiment-angular-encapsulation.
To grasp the take a look at, it’s needed to know the parts. Beneath I pasted the code of the AppComponent and its template.
To check it properly, I made a decision to run it within the loop with 100 iterations; every iteration is rendering 10 000 parts. It seems prefer it’s sufficient to get satisfying outcomes.
import {ChangeDetectionStrategy, ChangeDetectorRef, Part} from '@angular/core';@Part({
selector: 'app-root',
templateUrl: './app.element.html',
changeDetection: ChangeDetectionStrategy.OnPush
})
export class AppComponent {
sort: 'clear' | 'emulated' | 'shadow' | 'none' = 'clear';
array = new Array(10000).fill(0);
constructor(
personal readonly changeDetectorRef: ChangeDetectorRef
) {
}
render(sort: 'clear' | 'emulated' | 'shadow' | 'none'): void {
let testTime = 0;
for (let i = 0; i < 100; i++) {
const begin = efficiency.now();
this.sort = sort;
this.changeDetectorRef.detectChanges();
const finish = efficiency.now();
testTime += (finish - begin);
this.sort = 'clear';
this.changeDetectorRef.detectChanges();
}
console.log('TOTAL', testTime);
console.log('AVG', testTime / 100);
}
}
And naturally, the template:
<h1>Kinds encapsulation</h1><div>
<h2>Emulated</h2>
<app-emulated></app-emulated>
</div>
<div>
<h2>None</h2>
<app-no-encapsulation></app-no-encapsulation>
</div>
<div>
<h2>ShadowDom</h2>
<app-shadow></app-shadow>
</div>
<div>
<h2>Take a look at - 100 * Create 10000 parts</h2>
<button (click on)="render('clear')">Clear</button>
<button (click on)="render('emulated')">Emulated</button>
<button (click on)="render('none')">None</button>
<button (click on)="render('shadow')">ShadowDom</button>
</div>
<div *ngIf="sort === 'emulated'">
<app-emulated *ngFor="let x of array"></app-emulated>
</div>
<div *ngIf="sort === 'shadow'">
<app-shadow *ngFor="let x of array"></app-shadow>
</div>
<div *ngIf="sort === 'none'">
<app-no-encapsulation *ngFor="let x of array"></app-no-encapsulation>
</div>
When you don’t wish to do the exams in your pc, listed here are my outcomes. If you wish to do it, bear in mind to open dev instruments. The time of the take a look at will probably be printed there.
There’s virtually no distinction between the Emulated and disabled encapsulation. The distinction between ShadowDom and the remainder of the encapsulation sorts is large.
It scares me slightly that I wrote an article about encapsulation and its efficiency the place the take a look at is a really small a part of the entire textual content. I simply needed to explain variations properly 😀
To sum up, the default Emulated encapsulation is as quick as no encapsulation in any respect. It seems that this may be defined by the implementation. Ultimately, it’s solely a sensible method of utilizing native CSS attribute selectors. The ShadowDom method is considerably slower, perhaps it’s the rationale why it’s not extremely popular in my atmosphere.
PS. This submit was printed initially on https://mythical-angular.dev/. I submit all the things on medium with a small delay, so if you wish to have recent content material, take a look at my weblog 🙂
[ad_2]