You can preview d4103d6 at https://pr24943-d4103d6.ngbuilds.io/.

You can preview 7e5595a at https://pr24943-7e5595a.ngbuilds.io/.

You can preview 26f76b1 at https://pr24943-26f76b1.ngbuilds.io/.

presubmit

Before this change, private properties usage is fully supported in any template, but this change is going to make private properties usage quite inconsistent. Given the class:

class AppComponent {
  private foo = 42
}

Then using private property directly inside Component template is allowed:

<!-- Works always -->
<div>{{ foo }}</div>

But using private property inside any embedded template is NOT allowed:

<!-- Works before -->
<!-- Throws after -->
<div *ngIf="true">{{ foo }}</div>

Even supporting private property is not promised, but the implementation detail could make it confusing to users.

Update: I guess I was wrong and the condition seem even worse, given nextContext is not generic, so type-checking not happened at all?

@trotyl

1. Private references to context should never be supported and it is not supported in current version, so I am confused about your comment.
2. Type checking is a separate issues which is outside the scope of the runtime.

You can preview 180082e at https://pr24943-180082e.ngbuilds.io/.

@mhevery I didn't mean it's a breaking change from view engine, but having in-fact partial support is confusing (as it's indeed supported in component template by Ivy).

Imagine a user have private property already and everything is fine in AOT, once he/she added an *ngIf then it suddenly becomes an error.

Also polluting entire module scope with additional FunctionDeclarations is dangerous and could break users' code.

So how about using IIFE while and do NOT emit code outside the ClassDeclaration like:

class MyComponent {
  static ngComponentDef = ɵdefineComponent({
    template: (() => {
      function MyComponent_li_Template_2(rf: RenderFlags, ctx: SomeContext) {
        // ...
      }
      function MyComponent_Template(rf: RenderFlags, ctx: MyComponent) {
        if (rf & 1) {
          ɵE(0, "ul", null, $c1$);
          ɵC(2, MyComponent_li_Template_2, null, $c2$);
          ɵe();
        }
        // ...
      }
      return MyComponent_Template;
    })()
  })
}

I guess this is also what TypeScript does in their code emitting.

@mhevery Please also consider the possibility of ClassExpression (or non-top level ClassDeclaration) support in the future, a ClassExpression could have same name or even no name:

const createFooComponent = (val: number) => (flag ? @Component({}) class FooComp { foo = val } : @Component({}) class FooComp { foo = -val })
const createBarComponent = (val: number) => (@Component({}) class { bar = val })

And it's impossible to emit code to their own scopes, but only at top-level. Then the compiler would need to maintain an extra class counter per module.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}