-
Notifications
You must be signed in to change notification settings - Fork 13.3k
strictPropertyInitialization should allow private initialization helpers #32194
Description
Search Terms
- strictPropertyInitialization
- class initialization helper
Suggestion
It's a common pattern to delegate class initialization to helper methods to reduce the size of the constructor. This makes it more maintainable. However, when using --strictNullChecks and --strictPropertyInitialization, TypeScript complains because it's unable to infer the initialization since it's in a helper function. The argument in #21132 is that it's because of inheritance, but I think it should work if the helper method is marked a private (or private class field #), since a subclass would not be able to access it.
Not only is it annoying to have to do private foo!: string;, but it's also hard to know to do that, so most just end up either removing the helper methods or using // @ts-ignore. It's also TS's goal to support common JS pattern as best as possible.
Use Cases
Explained above.
Examples
class A {
private foo: string; // <== TypeScript complains
constructor() {
this.initStuff();
}
private initStuff() {
this.foo = 'foo';
}
}Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.