Clarity and/or discussion on "private" property/method naming

📚 Docs or angular.io bug report

Description

I was hoping to gain more clarity or talk about a “nice to have” in regards to the Angular Styleguide suggestion not to use the underscore prefix for “private” properties and methods if possible. Specifically, it’s use and the way “private” interacts from ts within templates between the default dev and prod builds - it seems like there could be a gap here.

This question helps illustrate part of the issue, and has been talked about at length in a few more references (and more), here_1, here_2.

While these talk more specifically about access methods conflicting with prop names, I wanted to bring up the interaction with templates. Issues like this one, while they are not a problem with the framework, throwing an error that a property is “private” while looking at the template currently requires extra step(s) (explained more here).

While JavaScript (default ng serve / ES5) does not care about “private,” tsc (default prod build) does.TS has support for letting the developer know if a private property or method is being used, but I’m not familiar with a way of seeing this in the templates. Developers who are more familiar with Angular may not have an issue here, but using a pattern like this could be a “nice to have” for newer/unfamiliar developers, or a timesaving naming/visual pattern when working in templates.

🔬 Minimal Reproduction

What’s the affected URL?**

https://angular.io/guide/styleguide#properties-and-methods

Reproduction Steps**

ng new test-ng
cd test-ng

Inside of app.component.ts:

  public test = 'test';
  private testPrivate = 'testPrivate';
  private _testPrivate = '_testPrivate';

and inside of app.component.html:

<div>
  {{test}}
</div>
<div>
  {{testPrivate}}
</div>
<div>
  {{_testPrivate}}
</div>

Running the default ng serve works just fine as expected / noted above, but ng build --prod will fail (also as expected). The difference (at least for me) is that with the IDEs I’ve used, I can immediately tell by looking just at the template that _testPrivate probably is private-

Expected vs Actual Behavior**

Actual behavior: while it’s an agreed upon mistake by the developer, no ahead of time warning for private props/methods in templates, requires additional steps.

Expected: Can be a range from noting the alternative naming with underscore, adding more detail to the existing info of TS vs JS “private”, or leave the docs alone and provide/suggest tooling out of the box that catches this at dev time.

[trotyl]

@IgorMinar @pkozlowski-opensource I’m not sure why Angular team decide on not allowing private access, but that’s only a design choice, not technical limitation. In current Ivy implementation it can be simply move the code generation position:

https://github.com/angular/angular/blob/30d1f292c930d0ba8c198757b3333d4b594692d8/packages/compiler-cli/src/ngtsc/typecheck/src/context.ts#L265-L266

from:

class SomeCmp {}

function _tcb_1(ctx: SomeCmp) {
  // generated here
}

to:

class SomeCmp {
  static _tcb_1(ctx: SomeCmp) {
    // generated here
  }
}

The only requirement here is making private/protected accessor part of requiresInlineTypeCheckBlock criteria.

Given there’s no real cost for supporting private access, can you share the reason why not support this in post-Ivy infrastructure?

[pkozlowski-opensource]

I agree that private members of component and their visibility in a template should be clarified. Marking as confusing aspects of the framework so we can update docs and / or think of a better mental model.