Ordering of Angular component class members.

angular-member-ordering.md

Ordering of Angular component class members

Use the following order of groups to organize Angular components:

1. Private properties.
2. Data binding properties.
3. View and content properties.
4. UI properties.
5. Component API properties.
6. Constructor.
7. Lifecycle hooks.
8. Event handlers.
9. Component API methods.
10. Private methods.

Group	Description
Component API methods	Public methods intended to be used by other components, directives, or services.
Component API properties	Public properties intended to be used by other components, directives, or services.
Data binding properties	Properties decorated by Input/Output or initialized with input/output.
Event handlers	protected methods used by the component template.
Lifecycle hooks	Methods implementing the AfterContentChecked, AfterContentInit, AfterViewChecked, AfterViewInit, DoCheck OnChanges, OnDestroy, or OnInit interfaces.
Private properties	Properties marked by private or #.
UI properties	protected properties used by the component template.
View and content properties	Properties decorated by ContentChild, ContentChildren, ViewChild, or ViewChildren.

• Private means private and protected alike?
• Do UI properties need to be public? As far as I can tell, template is a child of component class and thus logically private means accessibility only inside class, but protected covers a wider scope (as in template as well).

Hi @jeserkin,

Thanks for your interest in these guidelines.

Private means private and protected alike?

No, private as in private (TypeScript-specific) or # (ECMAScript standard).

Do UI properties need to be public? As far as I can tell, template is a child of component class and thus logically private means accessibility only inside class, but protected covers a wider scope (as in template as well).

After these guidelines were written, Angular made it possible to use protected component properties in its corresponding template. I will update the description to suggest protected for UI properties.

There are also some values, that are readonly, so maybe, they would also have some spot in the table. Also, let's not forget about static. It is also widely used.

Also this

protected properties used by the component template.

should take into consideration, that input/output signals/Decorators are (or at least from my perspective - should be) public. Yes you can assign protected and it will still be accessible in a usual way, but it doesn't represent the level of isolation as it should.
IMO, if you can provide or listen to it from outside, it is public.