You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a difference in TS behavior that depends on whether the type of this for method is explicitly declared or inferred: typescript playground link
classExample2{privatefield=1;show(this: Example2){returnthis.field;}}letexample2=newExample2();letshow2=example2.show;example2.show();show2();// Compile-time error: The 'this' context of type 'void' is not assignable to method's 'this' of type 'Example2'.
I believe it would be more consistent and type-safe if it behaved in Example1 the same way as in Example2: if method is using this then it requires this to be object of given class.
🔍 Search Terms
this
context
constraint
type
✅ Viability 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, new syntax sugar for JS, etc.)
This will probably be a breaking change for mobx code that uses decorators to automatically bind methods to objects.
⭐ Suggestion
Make inferred type for methods that use this be methodName(this: ClassName, ...): ReturnType instead of simply methodName(...): ReturnType.
📃 Motivating Example
More errors will be caught at compile-time: if developer tries to pass method as callback it will fail except for cases where this isn't used.
Example:
classSomeState{// ...doCoolStuff(){// ...this.evenCoolerStuff();}}functionSomeComponent(props: {state: SomeState}){const{ state }=props;return(<divonClick={state.doCoolStuff}/>/* will emit error at compile-time */);}
💻 Use Cases
It allows to detect errors early when passing methods as callbacks and forgetting about .bind.
The text was updated successfully, but these errors were encountered:
Edit: or not exactly. At this time we already have an option to declare this constraint explicitly and typechecking already can catch those errors; but for some reason type inferrence doesn't work as expected. I don't know if this was the case at 2018 when #28548 was filed.
Suggestion
There is a difference in TS behavior that depends on whether the type of
this
for method is explicitly declared or inferred: typescript playground linkIf inferred:
If declared explicitly:
I believe it would be more consistent and type-safe if it behaved in Example1 the same way as in Example2: if method is using
this
then it requiresthis
to be object of given class.🔍 Search Terms
✅ Viability Checklist
My suggestion meets these guidelines:
This will probably be a breaking change for mobx code that uses decorators to automatically bind methods to objects.
⭐ Suggestion
Make inferred type for methods that use
this
bemethodName(this: ClassName, ...): ReturnType
instead of simplymethodName(...): ReturnType
.📃 Motivating Example
More errors will be caught at compile-time: if developer tries to pass method as callback it will fail except for cases where
this
isn't used.Example:
💻 Use Cases
.bind
.The text was updated successfully, but these errors were encountered: