Support inheritance when parsing interfaces #395
Merged
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.
This PR adds support for inherited properties when parsing interfaces such as component prop interfaces or site settings. Something like this is now supported:
If we're not able to resolve the type that's being extended to an object type, we throw an error. This would include extending a non-object type like
HexColor
(which is invalid TS), extending a built-in type likeRecord
, etc. We also aren't adding any additional support for type unions or intersections, beyond our current support for string unions, since TS does more complicated merging when properties are shared in those cases. For interfaces that inherit properties, if a property is shared between the inherited type and the new type, the new property's type is required by TS to be a subset of the inherited property's type, and the new property's type is used in the final, generated type. In other words, only type narrowing is allowed.J=SLAP-2938
TEST=auto, manual
In the test-site, see that prop editors for inherited props show up as expected in the UI.