Add example with type-safe destructuring #3325
Open
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.
What:
This adds an example of extending and styling an intrinsic element with type-safety.
Why:
The examples in the docs only show how to style intrinsic elements with no callback for the actual tag - this is clearly something React devs struggle with in TypeScript, and it's made more difficult by also needing the
styled
call.I spent almost a day before landing on a reasonably simple and satisfying approach, so I figured this can help others. :-)
I honestly feel like you should promote this pattern as the first-and-foremost option. Many of the other options will simply have you run into a wall, having to refactor to this pattern anyway. For example,
styled.div
doesn't give you any real control of anything - you'll need a custom prop, which you will then learn how to filter out usingshouldForwardProp
. Then you'll need a custom attribute, or you'll need a default value for a prop, really anything besides just forwarding, and you will need this pattern anyway. To be honest, I don't think all these "shortcuts" or "workarounds" should even exist, or at least I don't think they should be promoted - they are incomplete abstractions, so when things change, you'll need to refactor anyway. Just show me one approach first that always works - leave those shorthand options a secondary choices for people who insist on brevity over ease of change.Just my opinion! so I'm going to leave that for your consideration. :-)