Question: Isn't it possible to create a small public layer on top of the Ivy instruction set?
This will create a low-level API that still allows evolving the rendering stack, while also providing a flexible basis to build higher-level abstractions.

Another question: We can already mix-and-match more dynamic templates by using Angular Elements(web components generated by angular).
The current downside of using those is that you can't tell the language server you have those, so you need to turn off most of the syntax checking for templates.
Would fixing that, not already bring a lot of what this RFC is bringing?

@IgorMinar Thanks for this proposal! It really looks good.
What I'm missing in the createView array, is an option to add a portion using normal template syntax, something like:

  // this is where the magic happens
  return createView([
    html("<div>some static html, that will be automatically serialized by the `createTemplate` call</div>"),
    tempateText(`
          <app-user [userId]="userId"><app-user>
           <ul>
              <li *nfFor="let pref of preferences>{{pref.name} - {{pref.value}}</li>
           </ul>`)
     } ) ; 
    } ]) 
  ] ) ; 

Where it uses the same context as the myContext in your sample for the template.

Adding support for "normal" templates will name the use of this API a lot simpler. I know using it will need to ship the full Ivy compiler to the client, but I would like to be able to make that trade-off.

Question: Isn't it possible to create a small public layer on top of the Ivy instruction set?

I think that's exactly what this is - it's an API to imperatively construct an Ivy template function, but which doesn't require you to have specific knowledge about how to call the actual template instructions.

We can already mix-and-match more dynamic templates by using Angular Elements(web components generated by angular).
The current downside of using those is that you can't tell the language server you have those, so you need to turn off most of the syntax checking for templates.
Would fixing that, not already bring a lot of what this RFC is bringing?

I don't think so, because such components still need to be written statically, even if their instantiation is more dynamic. This proposal allows for very dynamic constructions of views, based on runtime data structures.

What I'm missing in the createView array, is an option to add a portion using normal template syntax,

This is a cool idea, too. One of the concerns here is that it would require some notion of a template scope (what @NgModule provides today for statically compiled components) and that might get very tricky or messy to specify. But it could be done.

@alxhub Thanks for the quick answers! It is good to have this cleared out of the way.
I do like your clarification on how this is a different dynamic as using Angular elements.

This is a cool idea, too. One of the concerns here is that it would require some notion of a template scope (what @NgModule provides today for statically compiled components) and that might get very tricky or messy to specify. But it could be done.

This would be the same thing as it is for stand-alone(module-less) components, or am I looking from the wrong side? Those problems need to be solved anyway for truly dynamic components as far as I can see.

@alxhub Thanks for the quick answers! It is good to have this cleared out of the way.
I do like your clarification on how this is a different dynamic as using Angular elements.

This is a cool idea, too. One of the concerns here is that it would require some notion of a template scope (what @NgModule provides today for statically compiled components) and that might get very tricky or messy to specify. But it could be done.

This would be the same thing as it is for stand-alone(module-less) components, or am I looking from the wrong side? Those problems need to be solved anyway for truly dynamic components as far as I can see.

Sort of. The problem is that this scope has to be defined at runtime instead of compile time.

One of the challenges here is that Angular actually erases scope information for NgModules during compilation - this prevents all components/directives/pipes in an application from being referenced by NgModules and thus ineligible for tree-shaking. Having a dynamic, runtime way to specify a compilation scope would require retaining this information across the board, since we can't know ahead of time which NgModules would be referenced from such a dynamic scope.

@SanderElias thanks for all the questions. I think @alxhub fielded all/most of them already.

I just want to chime in on:

    tempateText(`
          <app-user [userId]="userId"><app-user>
           <ul>
              <li *nfFor="let pref of preferences>{{pref.name} - {{pref.value}}</li>
           </ul>`)
     } ) ; 

Dynamic template creation out of templates is something that I'd really like to avoid - it would basically be just a glorified way of using the current JIT compiler in production, which has lots and lots of problems (critical security, performance, and maintenance issues). I have an RFC coming out today, exploring the possibility of eventually removing JIT compilation mode entirely from Angular. I should post it within the next few hours — please stay tuned.

The goal of this proposal is to enable dynamic composition of views in a way that is performant and secure. Many of us would like to have the good old $compile back from the AngularJS days, and this proposal tries to strike the balance between the flexibility of $compile and security and performance of AOT compilation.

I added a new section to the issue above describing the trade offs of this proposal.

@petebacondarwin kindly pointed out that my example TS code was not syntactically valid due to typos, misaligned braces, and most problematically the use of if within an array literal. I updated the code snippet to fix these. Thanks Pete!

@IgorMinar the first snippet has a const named myCustomView, created by calling the function createView. But the second snippet doesn't define a createView function. Instead it defines a myCustomView function calling another (framework-provided) createView function. I was a bit troubled when trying to understand it. Some renaming would make the code corrrect, and thus easier to understand IMHO. I guess some await and asyncare missing too

  protected async renderDynamically() {
    const myCustomView = await createMyCustomView('./myBlue.component',
      {userName: 'Kahless', myRoutePath: ['my-route'], showDetails: true});

    // appends the view
    viewContainerRef.appendEmbeddedView(myCustomView);
  }
  
  async function createMyCustomView(blueComponentESModulePath: string, myContext: {[key: string]: any}) {
    const blueComponent = (await import(blueComponentESModulePath)).default;

    // this is where the magic happens
    return createView(...);
  }

@jnizet thanks you so much for pointing this out! I think I updated the code with all of your suggestions.

I expected the code to have some minor syntax flaws when I was typing it out in the github issue editor, but I see that the next time I do something like this I should instead create a stackblitz that compiles but doesn't run.

I love this, it's basically what I always hoped Ivy would enable.

However, I'm confused about how updates will work. I realize the syntax is nowhere close to final, but I'll use it as a reference for discussion.

In the example, if you used plain JavaScript expressions (if, switch, for, etc.) in your createView() call instead of NgIf, NgSwitch, NgFor, etc., wouldn't you have to destroy and recreate your view each time your context changed (expensive)? If you limited yourself to using the built-in structural directives instead then you could simply pass a new context to your embedded view, but I can imagine that devs familiar with React might assume that plain expressions would "just work" as they do in React, which might be a pain point.

If we do need to limit ourselves to using structural directives over plain expressions then it may be appropriate to provide some helper functions for the built-in stuff, so maybe instead of this:

template([
       text("some details")
       ], {directives: [
         directive(NgIf, {binding: () => myContext.showDetails})
       ]})

You could do:

ngIfTemplate(
  [text("some details")],
  () => myContext.showDetails
)

Of course, the community could build helper functions like that themselves. My main concern is that the way expressions restrict the ability to update a view may trip people up.

Thanks for sharing this openly! I'm excited for all the things a more dynamic Angular could bring.

@sg-gdarnell great points, thanks for bringing them up!

The important thing to note is that the current design doesn't rely on reevaluating the createMyCustomView function on each change detection tick. Instead, this function executes just ones. If you need the view to have conditional parts that respond to model changes and change-detection after the view has been created and attached, then you'd have to use NgIf, NgForOf, etc.

This brings me to the second part of your suggestion, it absolutely makes sense to add native support for NgIf and friends using an API like ngIfTemplate. I'll think about it a bit more, and update the proposal to include this suggestion.

Awesome proposal! Thanks! (+ thanks for the hidden Star Trek reference)

(+ thanks for the hidden Star Trek reference)

@manfredsteyer wow, that was fast! I thought that it would take longer for someone to connect the dots. #highFive err... #elbowBump

@IgorMinar Thanks for the additions and the answers.
It is good to know that template compilation is out of the scope of this proposal. Makes a lot of sense.

After having seen enough examples of how compile$ was used, I was always glad it wasn't available in Angular 😉 (I'm not afraid to say, that a few of those were of my own hand tho 😁)
And I will not shed any tears on seeing the JIT compiler go when there is an alternative like this is in place.

Now a new question arises:

      // you can use javascript expressions instead of `NgIf` to conditionally add view "nodes":
      (Math.random() > 0.5) && text(" and followed by another component"),

That will put false into the array literal. No problem there. But it brings me to the question.
What will be rendered into the view? Will the createView function just filter out anything that's not a known-thing™? (Or a function that returns a known-thing™?)
Or will it just ignore falsy values, and render the rest as text (I hope this is not going to happen!)