blog/angular-template-context

[giscus[bot]]

blog/angular-template-context

The Angular "Template Context" is a practically useful mental model, which once internalized, will be your main guide on the journey to build the best possible Angular applications!

https://angularexperts.io/blog/angular-template-context

[tomastrajan]

Hey folks!

Hope you enjoyed the content! Let me know if you would like to expand this topic to cover things like how this applies to Angular libraries and more real world examples of managing “template context” in large Angular applications!

[jbandi]

Thanks for the post!
It's a pretty long post going deep on the "how". Next I would be interested in the "why" ... why is Angular using this separate context to manage the scope of "declarables"?
JavaScript modules already provide a construct to manage the scope of any "declarable" on the language level.
Any other modern JS framework I know is using JavaScript modules and lexical scoping to manage the scope of "components" (this is obvious with JSX based frameworks, but also true for Vue or Svelte ...).
Why is Angular needing another "scoping" mechanism "on top" of JavaScript modules? What are the advantages that we get with this additional "mental model" that we have to understand on top of the JavaScript "mental model" when using Angular?

Minko quickly talks about this in WebRush episode 198 (https://webrush.io/episodes/episode-198-angular-v14-and-beyond), when he talks about "selector based components".
I would be interested in "real world" examples that show the power/advantages of this explicit "template context" mental model ...

[tomastrajan]

Hey @jbandi!

Thanks for the response! The why you ask for is the original why of why Angular introduced NgModules in the first place and yes, it's all about being able to just use component selectors (HTML tags like <my-org-user-item> in the template within same context without the need to import it in every single component which wants to use it.

This is great because in the base reality of JavaScript bundles, it doesn't really help to have it scoped per component as the split into multiple JS files doesn't happen on that level but on the level of lazy feature instead.

Now you could argue that every component should have been lazy loaded and sure that would come with its own set of tradeoffs (explored by the qwik, even though that's even more granular on the level of handler)

So now back to original reason, in Angular bundling happens on the level of navigation (routing), then everything within that bundle can be accessible in the HTML template without the need to manage explicit imports in every single component, that's the main optimization tradeoff delivered by the "template context" model.

Hope that clarifies it further!

[jbandi]

Thanks for the response ...
Somehow I was hoping for a deeper insight, for something I have missed so far ... :-)

I have some differences in my perspective on the topic:

1. Don't see the "bundling aspect" a driving force behind NgModules
   a) For historical reasons: At the time when NgModules were introduced (RC5) the Angular CLI (and also the Angular team was not using Webpack, but SystemJS to deliver an Angular application. At that point there was no bundling. So I guess the Angular compiler was the driving force, but not the bundler ...
   Also, if I remember correctly the initial Angular router did not do the lazy loading on route-level. This was only introduced in Angular 4 with the "new" router ...

b) Following your argumentation of "scoping happens on the level of the lazy feature ... therefore not every component should have to import its dependencies" ... applying the same thinking to the rest of the Angular application would mean that it would also be a good thing if we would not have to import services and utilities etc. in our JavaScript as long as we are in the same "chunk"? ... basically negating the ideas behind ES modules ... I don't think you would argue for that ...
For me ES modules (import/export) and NgModules are primarily about managing dependencies on a logical level ...
For me bundling is an orthogonal concern to ES modules (import/export) and NgModules ...
Especially because bundlers do not natively know about NgModules ...

2. I see the reason for NgModules and the "template context" in two areas:
   (based on the thread here: https://twitter.com/IgorMinar/status/1447593478834188291)

a) At the point of Angular2 RC4 it seemed tedious to have the explicit dependency imports in every component. Especially since AngularJS developers were not used to it.
In the meantime frameworks like React, Vue or Svelte have "proven" that this is not an issue but rather an advantage when we are only talking about components.
But in Angular it's more than just components. Templating in Angular is designed very flexible ... everything is a directive ... so it is indeed tedious if we have to import NgIf, NgFor etc into all the components ...
Also some directives are applied "automatically" as soon as you import a NgModule ... see "superpower" below ...

b) There was/is a problem with libraries and compilation of Angular libraries, that is somehow fixed with NgModules.
Igor mentions this in the tread (https://twitter.com/IgorMinar/status/1447593478834188291) .
.. I don't understand it. I was hoping you could explain it to me ... :-)

3. As far as I understand, a "superpower" of the "template context" model is, that selectors can be applied automatically ("secretly") to a template element and even several "selectors" can be applied to a single template element.
   I don't think that other frameworks can do that with their templating mechanisms. I think that is a reason why you see so much "wrapping components" in React component trees ...
   An example is the "form" directive that is automatically applied to any <form> in Angular, as soon as you load the FormsModule. Another example would probably be the new NgOptimizedImage that is applied to <img>...

Maybe I am wrong about this "superpower", so I would be interested in your perspective about this ...

[tomastrajan]

Hey Jonas!

Thanks for a very thorough reply, it reminded me of things I one knew and then forgot 😅

1. bundling

Agreed, with the way things happened historically the @NgModules we're definitely solving this as their first concern but would still argue that they (and template context) fit that use case very well, even if that might have been lucky coincidence.

2a. tedious to have the explicit dependency imports in every component

yes this is solved by the template context, more so SACs force us to have full lists (or workarounds with arrays or even @NgModules to prevent the need to manage it manually which is a better DX (especially if the context fully matches the underlying reality of lazy bundle) in that case there is no benefit from manual list management and single lazy context is definitely better DX, while also optimized perf.

2b. the libraries

I have not researched / tried in depth but gonna try to answer based on my current understanding of what is going on. As mentioned in twitter thread by Igor, libs are pre-built only partially, and the main building, eg compilation of templates in to IVY instructions happens during the consumer SPA build process.

That means there is one global compiler as Igor mentioned, with its config, eg

type CompilerOptions = {
    useJit?: boolean;
    defaultEncapsulation?: ViewEncapsulation;
    providers?: StaticProvider[];
    missingTranslation?: MissingTranslationStrategy;
    preserveWhitespaces?: boolean;
};

which could differ from the one which run to pre built lib, so I guess modules were either

a) a way to preserve that config per lib so it can run consistently across different consumers

or

b) a way to NOT need to fully pre build lib and enable partial per builds instead so that the whole thing is then compiled fully within the context of specific consumer SPA

again, no idea just guessing...

3. several "selectors"

Also the point about pipes and directives, it's true and it's one of the "superpowers" of Angular which allows composition of behavior with directives which is NOT POSSIBLE in React (and prolly others), very typical example being something like draggable directive which can attach that behavior to ANY Angular component or HTML element without coupling their implementation! This is going to play even bigger role with the advent of hostDirectives.

[Yexan]

Thanks for the article and comments bellow!
I'm new to the Angular SAC it was interesting to get to comparison to the NgModule approach I'm more familiar with and it was nicely explained thanks. :)
Have a great day