Refine generated type for assignable fragments on abstract types #4603
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #4560
This is quality-of-life change to the type generation for the assignable fragments (aka. typesafe updaters). For the cases where the assignable fragment is defined on the abstract type, and is spread on a concrete implementation of that type. Issue #4560 has a more true-to-life example. But the minimal case is:
Same applies to the interfaces as well.
Previously, the generated type for fragment
Foo
would include__isAssignable_c?: "A"
(since the assignable fragment is defined on an abstract type). In some sense, this type is misleading.__isAssignable_c
can never be undefined, sinceA
always implements (is member of) abstract typeC
. This would require writing a gnarly validator. The validator turns out to be redundant in the end, and is just there to satisfy the type system.This is a small patch that checks if the abstract type spread is done on the concrete subtype of the supertype (ie. fragment of union
C
is spread its memberA
). If the check is successful, the optionality of__isAssignable_c?: "A"
is removed. This is a safe assumption, since the only way forA
not to be a subtype ofC
:A
as a member of unionC
(if C is a union)A
to the interfaceC
(if C is an interface)Both of which are breaking schema changes anyhow.