From @ecraig12345 in HackMD:
At least IMO it's strongly preferable to have explicit type declarations, and this is one of the things I'd like to write a conformance test for. (Also the & React.RefAttributes part isn't needed because it's included in ComponentProps somewhere.) It's a cleaner API from a consumer standpoint and sometimes shows up MUCH cleaner in API reports by preventing unnecessary type expansion.

It can be simplified to: export const Accordion: React.FunctionComponent<AccordionProps> = React.forwardRef((props, ref) => ...)

from Guest Rodriquez in HackMD:
#19614 (comment)

from Guest Weaver in HackMD:
Please use at least ForwardRefExoticComponent

from @ecraig12345 in HackMD:
Maybe this should be obvious but I'm not totally clear on what you mean here, sorry. Can you give an example of what it looks like in a component that doesn't use this?

This isn't a consistency problem per se. I think we want to make sure that the types of each of the slots make sense. As the components using the ComponentPropsCompat are converted to using ComponentProps and start having slots then we will want to check the consistency.

from @ecraig12345 in HackMD:
This should also be addressed by the simplified prop merging issues

from @ecraig12345 in HackMD:
This is an interesting one, and a very good case for conformance testing. There are a couple sub-cases:

1. Explicitly declaring (as original type) for documentation purposes => probably fine (example: people get confused if the docs for Link don't explicitly mention href)
2. Explicitly declaring as limited sub-type => TBD if this is okay. If we allow it, it should be paired with Omit on the native props.
3. Accidental reuse of name for a different purpose => should come up with a different name (example: for Input I wanted to use size but had to rename it since that's a native input prop with different meaning)

from @ecraig12345 in HackMD:
Are you aware of any cases where this would cause conflicts?

I don't think it would cause a compile or runtime issue, but it could confuse users who might think it has to be set to an HTML element.

ComponentPropsCompat has been removed from Popover since #19767

Good to know. As expected, this document will age out quickly as beta work continues.

funnily enough, noArrow was used both in Popover and Tooltip initially, I wonder what requirement resulted in the divergence @behowell ?

The design for Tooltip was changed to not have an arrow by default, so I inverted the property naming so its default value would still be false.

I think I asked design to follow up about whether Popover's default should also change to not have an arrow, but I'm not sure if that happened.

I'm wondering if there should be two props here: One for that lets you specify 'ring' and maybe future values and another for 'shadow' | 'glow'. Are these specific appearances or is this union trying to cover the permutations of two different things?

Per chat with Levi, we should break these up if they are enumerating permutations. I'll follow up with Avatar owner to find out.

Could you add an example of what the final result would look like in code ?

I think the best example would be a PR :)

I think that this worth a separate RFC as it that affects all components. This a huge breaking change even for beta as there are already customers that are using v9 components.

We should clearly understand motivation, pros and cons of this proposal. This affects not only us, but also customers that will develop reusable components as they should follow similar patterns.

For example, to cons I can add bundle size/memory concern that should be validated first.

JSX props are compiled to JS objects:

<Button iconSlot={<div />} />
// ⬇⬇⬇
React.createElement(Button, { iconSlot: React.createElement('div') })

• properties of such objects cannot be mangled by Terser, this means that "iconSlot" will stay in minified JS
• (is it valid?) properties of objects in memory will be longer

So, Slot suffix will add additional 4 bytes to every slot's usage, at least for bundle size. 4 bytes is nothing, but in terms of huge apps with thousands of components/slots usages it's something.

For example, 1k definitions for slots will result in 4000 bytes in minified code, that gives us almost 4kB for nothing ¯_(ツ)_/¯

Yes, GZIP will compress this, but browsers will still parse uncompressed code.