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
We make a heavy use of factory method public static of() in our classes. Unfortunately, TS doesn't let us change the signature in derived classes, even through our case is fairly safe. This has been a very discussed topic in the TS community, we should keep an eye on it and streamline code where possible.
Currently, instead of using:
classFoo{publicstaticof(x: number): Foo{…}}classBarextendsFoo{// Rejected by TS due to incompatible signature of static function.publicstaticof(x: number,y: number): Bar{…}}
In turn, this forces instances of Bar to store y as an option (or to have Bar.of possibly erroring at runtime without clean way of detecting cases where we don't provide y). Further down, users of Bar need some extra isSome checks when getting y, which clutters the full construction.
Another possible pattern, which keeps consumer simple but complexifies a bit the producer is
classFoo{publicstaticof(x: number): Foo{…}}classBarextendsFoo{publicstaticof(x: number): Foopublicstaticof(x: number,y: number): Barpublicstaticof(x: number,y?: number): Foo{if(y!==undefined){// do Bar specific stuff}else{returnFoo.of(x)}}
where the explicit overload fixes the situation.
A notable case for this is extended Diagnostic where all the extra data needs to be "optional" due to this. Sometimes we can provide a decent default (e.g. empty array), but in several cases, we need to wrap it in Option even though we know there will always be something.
The text was updated successfully, but these errors were encountered:
This is blocked until microsoft/TypeScript#4628 / microsoft/TypeScript#39699 has landed.
We make a heavy use of factory method
public static of()
in our classes. Unfortunately, TS doesn't let us change the signature in derived classes, even through our case is fairly safe. This has been a very discussed topic in the TS community, we should keep an eye on it and streamline code where possible.Currently, instead of using:
We use patterns like:
In turn, this forces instances of
Bar
to storey
as an option (or to haveBar.of
possibly erroring at runtime without clean way of detecting cases where we don't providey
). Further down, users ofBar
need some extraisSome
checks when gettingy
, which clutters the full construction.Another possible pattern, which keeps consumer simple but complexifies a bit the producer is
where the explicit overload fixes the situation.
A notable case for this is extended
Diagnostic
where all the extra data needs to be "optional" due to this. Sometimes we can provide a decent default (e.g. empty array), but in several cases, we need to wrap it inOption
even though we know there will always be something.The text was updated successfully, but these errors were encountered: