Allow minimum and maximum value for component number props

[apedroferreira]

Initially just intended for this PR to be prep for fixing this issue #826, by using a single source of truth for the minimum component dimensions. But it seems like it's actually a solution, so it closes #826.
Also closes #461

Using it already for Select component minimum width as an example.

Screen.Recording.2022-08-30.at.19.21.52.mov

[render]

Your Render PR Server URL is https://toolpad-pr-871.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cc75a1cgqg4eu8ovpdrg.

[Janpot]

proptype is based on json-schema, I think that can describe min and max values. perhaps we should just reuse that?

[Janpot]

I'm still not understanding the minimum width use case and how it should behave. Suppose minimum width is 50px, and I put 100 Selects in one row, what happens? what overflows or wraps?
Also, if a select can be the fullWidth of its container, and the container is resizable, then why does it need a width property?

[apedroferreira]

proptype is based on json-schema, I think that can describe min and max values. perhaps we should just reuse that?

didn't know about that, i'll take a look

[apedroferreira]

I'm still not understanding the minimum width use case and how it should behave. Suppose minimum width is 50px, and I put 100 Selects in one row, what happens? what overflows or wraps? Also, if a select can be the fullWidth of its container, and the container is resizable, then why does it need a width property?

i'm still not sure about all that so this PR was just going to add this feature which is probably helpful anyway. we can remove the width prop i added to the Select though for now.

i was planning to try things and see what might work or not, and if limiting resizing based on minimum width could be helpful or not, even if the UI can still overflow in some cases (there's probably no way we can really stop it from happening).

right now we do have that way of resizing width: full width + resizing containers, but i wasn't sure if we intend for that to be the main way to resize the width of components, and then add some margins controls on top. i guess that could work. maybe we could also add an ability to resize directly on the component at some point, as some users might expect, and having this width prop could help for those cases?

maybe we can just add this min/max value feature for now without adding a width prop to the Select, and then I can tackle the issue with components visually overlapping in some other way, maybe just by showing that things are overflowing but making it be less visually confusing.

[apedroferreira]

Looks like I already solved the whole issue in this PR after all, slightly unintentionally:

Screen.Recording.2022-09-01.at.16.40.43.mov

By not setting a minimum width directly in the component CSS this kind of issue does not happen, the components always adjust to the width of the container.

If we make the screen very very narrow and have a lot of components they do overflow as it's inevitable, but I think the best option is to just let that happen rather than hiding the overflow.

In the future we can probably improve support for small device screens.

So what do you think? In my opinion we can merge this.


If you don’t agree with adding the new width prop to Selects it’s also not strictly necessary, we can remove it and use whatever default values the MUI component uses.
In my opinion this width prop is useful without being detrimental - it gives the user more control over how the element looks, and it sets a minimum width that doesn’t look so bad when the select is empty, just like the minimum width before this PR.
But the width prop is just an extra thing that I can remove.

[apedroferreira]

Also if you like this idea we can disable the width control when full-width is enabled, I just don't want to do it ahead of time if we don't want to go in this direction.

[Janpot]

👌

[prakhargupta1]

👌