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
[docs] Remove wrong migration instruction #22710
Conversation
Should we also add a note to the customization/spacing page "a function" section that the function must return a string? |
Why does it need to return a string? If a number is returned it will assume px. Maybe it should mention the default unit instead? |
@mbrookes There is another case that is unclear, what's the expected behavior when you provide an array for the spacing? The issue with the typing is to get be a number or a string, depending on the theme option input. I don't see how to make it happen. |
Could you add a runtime test for that behavior? It's not clear to me how spacing would ever return a number. |
@eps1lon Spacing used to return a number or a string, it's no longer possible, it can only be a string now. We have been discussing with Matt how to bring this behavior back, we couldn't see a simple approach with the types. |
Be aware that any code that's hard to express with types is also hard to explain to humans. What problem would overloading solve here? |
@eps1lon Agree, this is why I'm leaning toward giving up on a way to have v4 behavior, going for all-in in the new string approach.
Being able to have: const theme = createMuiTheme({
spacing: factor => 8 * factor,
});
theme.spacing(2); // = 8 right now we have: const theme = createMuiTheme({
spacing: factor => 8 * factor,
});
theme.spacing(2); // = 8px |
I understand the different return types. I'm asking what you'd do with this and why this problem should only be solved for a single argument. |
Oh, sorry, you were on the second order thinking. I don't know, also a reason why my proposal: so we get feedback and compeling use cases from developers 😁. |
Co-authored-by: Matt <github@nospam.33m.co>
Co-authored-by: Matt <github@nospam.33m.co>
A continuation of the discussion on bc45825#r42461020. From what I understand, our best option is to no support the previous case. Happy to consider alternatives.