Avoid tokens weird type checking/eliding

[mattcosta7]

Describe your changes here.

Relates to #2760

In this pr we omitted onResize and onResizeCapture as typescript was causing these to elide a mandator unknown type, which was super confusing.

I believe this was caused by the fact that these props aren't equally defined across all polymorphic types, and forwardRef swallows polymorphism, making things wonky.

I've re-typed these components using the polymorphic helper, and added some type tests to help validate they don't regress. I think we would be well served extending our type tests further to cover most/all components, as I'm sure others are limited in the same or similar ways

Screenshots

Please provide before/after screenshots for any visual changes

Merge checklist

• Added/updated tests
• Added/updated documentation
• Tested in Chrome
• Tested in Firefox
• Tested in Safari
• Tested in Edge

Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.

[changeset-bot]

🦋 Changeset detected

Latest commit: 3ea4e32

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@primer/react	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/browser.esm.js	87.38 KB (0%)
dist/browser.umd.js	88.03 KB (0%)

[broccolinisoup]

👍🏼

[broccolinisoup]

I believe this was caused by the fact that these props aren't equally defined across all polymorphic types, and forwardRef swallows polymorphism, making things wonky.

This makes perfect sense!

I think we would be well served extending our type tests further to cover most/all components, as I'm sure others are limited in the same or similar ways.

Thanks for the suggestion ✨ I see there are type tests for quite a few components but the recent ones seem to lack of them. I'll chat with the team about it.

This looks great to me! 🚀 Thanks for raising this PR 🙏🏼

[joshblack]

I believe this was caused by the fact that these props aren't equally defined across all polymorphic types, and forwardRef swallows polymorphism, making things wonky.

Would there be a good place to learn more about how forwardRef swallows polymorphism? (Or this concept more broadly). It was the first time I had seen the output of a type get inlined in such a way that information was lost and I would love to learn more about it if you have any suggestions 👀

For the type tests, is this something that should be a part of the testing requirements for components/props added or changed in a component? It doesn't really seem like there are other alternatives to guarantee that things are showing up, curious if there are other approaches that teams use or if this is kind of our best best moving forward to catch issues like this. Would love to hear your thoughts!

[mattcosta7]

I believe this was caused by the fact that these props aren't equally defined across all polymorphic types, and forwardRef swallows polymorphism, making things wonky.

Would there be a good place to learn more about how forwardRef swallows polymorphism? (Or this concept more broadly). It was the first time I had seen the output of a type get inlined in such a way that information was lost and I would love to learn more about it if you have any suggestions 👀

I don't know of one offhand, but a quick search brings up things like

https://fettblog.eu/typescript-react-generic-forward-refs/
https://twitter.com/jaredpalmer/status/1217149616082296833?lang=en

the crux of the issue is that a HOC in a static context can't return a generic that infers from an internal generic which seem related. Which is a mouthfull but this might be more easy to grok

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/0e64955901599be1e43a2e50c556d141a2b8fdd8/types/react/index.d.ts#L776-L781

the types for forwardRef don't return a component that's possible of generically defining something based on a certain prop, so it effectively 'swallows' up the as prop (which can't be inferred because it can't be defined)

For the type tests, is this something that should be a part of the testing requirements for components/props added or changed in a component? It doesn't really seem like there are other alternatives to guarantee that things are showing up, curious if there are other approaches that teams use or if this is kind of our best best moving forward to catch issues like this. Would love to hear your thoughts!

I think there definitely should be some level of requirement for adding these, even if they're only limited in the scope of the props validated!

[mattcosta7]

Not sure offhand whether this would be something we want to land in the current/next release - so feel free to merge when it makes sense (I don't want to merge too early!)

[joshblack]

@mattcosta7 makes perfect sense, thanks so much!

@broccolinisoup I'm going to merge this is as the follow-up to the TODO from: #2760 if that makes sense, let me know if it makes the release more complicated and I'd be happy to revert/add it back in after the release 👍