[Rating] Make input ids less predictable

[eps1lon]

Incomplete. Please review by commit.

Previous usage of useId was incompatible with the upcoming React.useOpaqueIdentifier. We can refactor the item() factory to a <Item /> component which allows us to to use React.useOpaqueIdentifier for each item.

This may break tests if you relied on stable ids for the individual radio inputs. However, you can use [value] attribute selectors instead which also means you no longer have to provide an explicit name in your tests:

-container.querySelector('input[name="rating-test-2"]')
+container.querySelector('input[value="2"]')

(This example queries for the input for the rating value "2")

Given that your container only has a single input of course. Otherwise you probably should provide an explicit name.

Preview: https://deploy-preview-26493--material-ui.netlify.app/components/rating/

[mui-pr-bot]

Details of bundle changes (experimental)

@material-ui/core: parsed: +0.08% , gzip: +0.09%
@material-ui/lab: parsed: +0.10% , gzip: +0.08%

Generated by 🚫 dangerJS against 3be8c95

[oliviertassinari]

Something I have noticed that changed: a double focus ring instead of a single one:

https://deploy-preview-26493--material-ui.netlify.app/components/rating/#rating-precision

[eps1lon]

Something I have noticed that changed: a double focus ring instead of a single one:

deploy-preview-26493--material-ui.netlify.app/components/rating/#rating-precision

Greatch catch 👍 Reproduced it in a visual regression test (https://www.argos-ci.com/mui-org/material-ui/builds/4211) and fixed it in 3be8c95 (#26493)

The implementation is still a bit hard to follow but it's now clearer where the odd part happens (active state is located in different components between precise (precision % 1 > 0) and non-precise (precision % 1 === 0) ratings.

[oliviertassinari]

I can't notice anything else. Looks good

reactjs/rfcs#32 (comment) doesn't seem to happen (it would allow the usage of a single opaque identifier).

For context, in the initial implementation of the rating, I didn't use a component for the rating items to avoid the overhead of React components, in the order of +10% CPU per extra component (but I don't have a benchmark to prove it). With precision={0.5} we render a lot of DOM, the rating doesn't seem fast to render. But I understand that without a component, we can't use useId.

If reactjs/rfcs#32 (comment) ever happen in the future 👍 for: 1. adding a perf benchmark, 2. calling RatingItem as a function, instead of a React component and measure if it makes a difference or not.

[eps1lon]

reactjs/rfcs#32 (comment) doesn't seem to happen (it would allow the usage of a single opaque identifier).

This does not match the latest information I was given:

Yes, all of these things are on the list to get back to.

-- reactwg/react-18#9 (reply in thread)

calling RatingItem as a function, instead of a React component and measure if it makes a difference or not.

I don't find it helpful that we constantly have to get back to this discussion. If you want to start a discussion whether Reacts lazy evaluation model vis components is useful then go for it. But starting it whenever it suits to make an argument against a change that wasn't explicitly sanctioned by you is just not helpful. So either start an RFC on the appropriate channels to get a good understanding when we should use function calls and when compoent or stop constantly opening this unconfirmed issue.

[oliviertassinari]

an argument against a change

I don't think that it goes against the changes done here. I was interested in the opportunity it could yield later on, once these changes are on HEAD.

this unconfirmed issue.

AFAIK, the overhead was confirmed at the root. Here are two examples where we measured it:

1. https://github.com/mui-org/material-ui/blob/next/benchmark/browser/README.md#output React primitives vs. React components. In this very logs, the difference is +23% ±20%.
   If I run it locally, I get: "React primitives: 37 ±1%, React components: 42 ±0%". The difference is +14% ±4%.
2. table-raw vs. table-components. I get a difference of +22% on a single run (but not ranges of uncertainty)

red to

My question was: Will we need to care in this specific context of the Rating? Will it ever be significant? Anyway, it's not for us to consider today, but in the future :). #17001 might be one where we can have a larger impact first.

[oliviertassinari]

To unlock the PR, as it doesn't seem to get interest from other maintainers :)