Open jonlepage opened 1 week ago
Is this just like an opt-in version of #32194 and #30462?
Is this just like an opt-in version of #32194 and #30462?
thank you i add a 4er suggest. The issues dates seems to indicate a certain difficulty in adding this functionality to the current TypeScript architecture. This is a widely used design pattern, for instance in an ECS architecture.
🔍 Search Terms
strictPropertyInitialization, Property has no initializer and is not definitely assigned in the constructor.
✅ Viability Checklist
⭐ Suggestion
Hello, have you ever considered adding a special hack to delegate the role of a class constructor when using
strictPropertyInitialization: true
in the tsconfig file?In fact, I have an issue with an architecture that makes the constructor unnecessary until the class is injected into a facade that activates the system and creates the private dependencies of the class.
There is no other solution except to disable this rule, which is frankly not great and very limiting when a project uses several design patterns requiring a distinct approach. To take advantage of the security of
strictPropertyInitialization
, would it be possible to have maybe a special utility type that tells TypeScript to check this method instead of the constructor?Here are examples that could potentially be good solutions: I personally prefer examples 2 and 3. The first example can bring more complexity
📃 Motivating Example
Suggest 1: method with special type
We add
methodname( this:ThisConstructor )
issues:
Suggest 2: detect with illegal
this
in constructor. It is currently illegal to use "this" in the constructor. We could take this opportunity to tell ts to check another methods for props initialisation. I using "string" here, but is juste for give the idea.issues:
protected
andprivate
method based ont how ts workSuggest 3: using comment
issues:
protected
andprivate
method based ont how ts workSuggest 4: tracking the flow from constructor: https://github.com/microsoft/TypeScript/issues/32194 https://github.com/microsoft/TypeScript/issues/30462
issues:
💻 Use Cases
What do you want to use this for? This is to address the need for an architecture that requires initialization after adding a loosely coupled facade. The idea is to maintain the security of declarations, which current solutions do not allow. This approach can also open the door to design patterns that are difficult to manage with TypeScript.
What shortcomings exist with current approaches? Currently, there are various tricks that do not allow to maintain the security and philosophy of TypeScript. 1:
//@ts-ignore
2:public props!:object
3:strictPropertyInitialization:false
What workarounds are you using in the meantime?
public props!:object