Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[utils] Allow passing NaN as defaultValue to useControlled #41559

Merged
merged 3 commits into from
Jun 8, 2024

Conversation

iammminzzy
Copy link
Contributor

@iammminzzy iammminzzy commented Mar 19, 2024

This fixes an issue with a warning getting logged when passing NaN as defaultValue to useControlled due to using === instead of Object.is. However, Object.is is not supported in IE11 so I made the change in a backwards-compatible way.

@mui-bot
Copy link

mui-bot commented Mar 19, 2024

Netlify deploy preview

https://deploy-preview-41559--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against e364f14

@iammminzzy iammminzzy changed the title [utils] Allow passing NaN as defaultValue to useControlled [utils] Allow passing NaN as defaultValue to useControlled Mar 19, 2024
@zannager zannager added the package: material-ui Specific to @mui/material label Mar 19, 2024
@zannager zannager requested a review from mj12albert March 19, 2024 13:15
@NMinhNguyen
Copy link
Contributor

NMinhNguyen commented Mar 19, 2024

Just curious - are all changes supposed to go into next branch starting from today, and not master anymore? If next, then I guess IE support could be dropped already.. And if not, then should this PR target master?

Comment on lines +109 to +113
it('should not raise a warning if setting NaN as the defaultValue when uncontrolled', () => {
expect(() => {
render(<TestComponent defaultValue={NaN}>{() => null}</TestComponent>);
}).not.toErrorDev();
});
Copy link
Member

@oliviertassinari oliviertassinari Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why should it support this? It looks like more bundle size and complexity for no clear value in exchange.

Object.is is not supported in IE11

We don't support IE 11 anymore, so maybe Object.is would make it, a light DX improvement for no real UX cost.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One example is if you have a Select component where one of the options has value of NaN and you set the defaultValue to NaN you would incorrectly get the "component is changing the default value state" warning.

Copy link
Contributor

@NMinhNguyen NMinhNguyen Mar 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bundle size shouldn’t be impacted at all because the whole effect is wrapped in a process.env.NODE_ENV check, and nowhere else in the codebase uses Object.is and there are IE11 comments, so we figured it’s better to keep the partial IE11 support but more than happy to use Object.is (that’s what React uses for dependency arrays, for example)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One example is if you have a Select component where one of the options has value of NaN

Isn't it wrong that an option has a value of NaN?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One example is if you have a Select component where one of the options has value of NaN

Isn't it wrong that an option has a value of NaN?

Respectfully, I don't think there's anything wrong with using NaN as a value. For example I could use it to represent a "None" value, or maybe the number value comes from user input and NaN represents an invalid input.

@oliviertassinari oliviertassinari added package: base-ui Specific to @mui/base and removed package: material-ui Specific to @mui/material labels Mar 19, 2024
Copy link
Member

@ZeeshanTamboli ZeeshanTamboli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you provide a reproduction? This StackBlitz sandbox template may be a good starting point.

@QingqiShi
Copy link

QingqiShi commented Apr 28, 2024

Could you provide a reproduction? This StackBlitz sandbox template may be a good starting point.

Simple repro with the Autocomplete component, but essentially anything that uses the useControlled hook suffers from the same issue. https://stackblitz.com/edit/stackblitz-starters-unpbpo?file=src%2FApp.tsx

@ZeeshanTamboli ZeeshanTamboli added package: utils Specific to the @mui/utils package enhancement This is not a bug, nor a new feature and removed package: base-ui Specific to @mui/base labels Apr 30, 2024
Copy link
Member

@ZeeshanTamboli ZeeshanTamboli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine to me, but since it's also used in MUI X, it should be reviewed by others too. cc @flaviendelangle @Janpot (Tagging Jan because it might be used in Toolpad too).

Copy link
Member

@Janpot Janpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no problems with this, the warning is about comparing values of props between renders and React also use Object.is for this purpose. It doesn't affect production bundle sizes.
Doesn't mean I think it's a good idea to use NaN as a value to represent state, but it should probably be left to the consumer of this hook to decide how to handle it.

@mj12albert
Copy link
Member

Doesn't mean I think it's a good idea to use NaN as a value to represent state, but it should probably be left to the consumer of this hook to decide how to handle it.

I agree 👍 generally we are moving towards using null for "no value" (e.g. Material UI's Select vs Base UI's Select) but it's totally the user's decision ~
(I think I've seen RA use NaN internally for "no value" as well)

@NMinhNguyen
Copy link
Contributor

Completely contrived example but you could imagine an educational calculator component that lets you pick from values like NaN, -10, 10 to see the impact of multiplying it by another hard-coded number. Sure, you could write code to treat null as NaN, but seems a bit annoying 😛

@ZeeshanTamboli
Copy link
Member

@mj12albert Since you approved it, could you merge it? Let's not leave it hanging, unless you're waiting for something specific. Should we also consider cherry-picking this to the master branch?

@mj12albert
Copy link
Member

mj12albert commented May 15, 2024

One example is if you have a Select component where one of the options has value of NaN and you set the defaultValue to NaN

Just occurred to me to quickly test this out:

<Select defaultValue={NaN}>
  <MenuItem value={NaN}>NaN</MenuItem>
</Select>

useControlled doesn't warn, but the component logged 2 other warnings:

Warning: Received NaN for the `value` attribute. If this is expected, cast the value to a string.
    at input

and

Warning: Received NaN for the `data-value` attribute. If this is expected, cast the value to a string.
    at li

Though this doesn't necessarily block the PR, just wanted to ask @iammminzzy if you tried these changes with any (other) Material UI component successfully!

@ZeeshanTamboli
Copy link
Member

@iammminzzy Any updates on #41559 (comment)?

@QingqiShi
Copy link

useControlled doesn't warn, but the component logged 2 other warnings

Though this doesn't necessarily block the PR, just wanted to ask @iammminzzy if you tried these changes with any (other) Material UI component successfully!

The stackblitz link in this comment uses an AutoComplete component which doesn't throw these warnings with NaN value #41559 (comment)

Personally I think we should "fix" the other two warnings as well but that's unrelated to this PR.

@ZeeshanTamboli ZeeshanTamboli requested a review from mj12albert June 5, 2024 13:34
@iammminzzy
Copy link
Contributor Author

iammminzzy commented Jun 7, 2024

@iammminzzy Any updates on #41559 (comment)?

It's the same repro as @QingqiShi shared above.

@ZeeshanTamboli ZeeshanTamboli added the needs cherry-pick The PR should be cherry-picked to master after merge label Jun 8, 2024
@ZeeshanTamboli ZeeshanTamboli merged commit c66a51d into mui:next Jun 8, 2024
20 checks passed
github-actions bot pushed a commit that referenced this pull request Jun 8, 2024
)

Co-authored-by: ZeeshanTamboli <zeeshan.tamboli@gmail.com>
@oliviertassinari
Copy link
Member

It looks good 👍

@oliviertassinari
Copy link
Member

oliviertassinari commented Jun 8, 2024

On making this work:

<Select defaultValue={NaN}>
  <MenuItem value={NaN}>NaN</MenuItem>
</Select>

I think it's important to understand what NaN is about, from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN, NaN in JavaScript behaves like in IEEE-754.

So from, there, we can check why the IEEE-754 committee made it so that NaN !== NaN?
Some lights on this: https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values. As I read this, it's effectively:

  • Before, the isNaN(x) function didn't exist, developers would test this with x === x. This is no longer a problem.
  • NaN - NaN = NaN, and not NaN - NaN = 0, so NaN != NaN. Kind of the same idea as https://stackoverflow.com/a/1565254/2801714

If I hand you two boxes, and tell you that neither of them contains an apple, would you tell me that the boxes contain the same thing? NaN contains no information about what something is, just what it isn't. Therefore these elements can never definitely be said to be equal.

So I think that NaN shouldn't be used for anything else than arithmetic errors, and definitely not for a component value. I think we could still support it but on the only condition that it doesn't harm the majority of the users, e.g. no real bundle size increase / not code complexity increase, it wouldn't be worth it if it did.

joserodolfofreitas pushed a commit to joserodolfofreitas/material-ui that referenced this pull request Jul 29, 2024
…#41559)

Co-authored-by: ZeeshanTamboli <zeeshan.tamboli@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This is not a bug, nor a new feature needs cherry-pick The PR should be cherry-picked to master after merge package: utils Specific to the @mui/utils package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants