gr.Number() max/min limit

[dawoodkhan82]

Description

Building off of artegoser PR (which is merged into this branch). Adding frontend support for min/max of gr.Number() component.

As of now, the border color for the input turns red when a number out of range is typed in.

Please include:

• relevant motivation
• a summary of the change
• which issue is fixed.
• any additional dependencies that are required for this change.

Closes: #934

Checklist:

• I have performed a self-review of my own code
• I have added a short summary of my change to the CHANGELOG.md
• My code follows the style guidelines of this project
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

A note about the CHANGELOG

Hello 👋 and thank you for contributing to Gradio!

All pull requests must update the change log located in CHANGELOG.md, unless the pull request is labeled with the "no-changelog-update" label.

Please add a brief summary of the change to the Upcoming Release > Full Changelog section of the CHANGELOG.md file and include
a link to the PR (formatted in markdown) and a link to your github profile (if you like). For example, "* Added a cool new feature by [@myusername](link-to-your-github-profile) in [PR 11111](https://github.com/gradio-app/gradio/pull/11111)".

If you would like to elaborate on your change further, feel free to include a longer explanation in the other sections.
If you would like an image/gif/video showcasing your feature, it may be best to edit the CHANGELOG file using the
GitHub web UI since that lets you upload files directly via drag-and-drop.

[gradio-pr-bot]

🎉 The demo notebooks match the run.py files! 🎉

[gradio-pr-bot]

All the demos for this PR have been deployed at https://huggingface.co/spaces/gradio-pr-deploys/pr-3991-all-demos

[abidlabs]

Very cool @dawoodkhan82! This is the first time we're doing any sort of validation in the frontend, so cc @pngwn @aliabid94 @gary149 on the design piece.

[abidlabs]

I tested this code:

import gradio as gr

gr.Interface(lambda x:x, gr.Number(min=10, max=20), gr.Number(min=15, max=25)).launch()

and on the default theme, it looks and works great:

However, on all of the other themes, I don't see any validation error bar:

import gradio as gr

gr.Interface(lambda x:x, gr.Number(min=10, max=20), gr.Number(min=15, max=25), theme="monochrome").launch()

[artegoser]

Wouldn't it be better if all input was red instead of borders? It would look more noticeable and most likely be displayed in all themes.

[abidlabs]

I think the border turning red like how @dawoodkhan82 has implemented it is more common, from what I've seen, e.g. see the examples here: https://www.nngroup.com/articles/errors-forms-design-guidelines/

[artegoser]

Okay, I changed my mind.

[aliabid94]

So if a user submits a number out of range, it gets clamped in the backend? That might be a bit "magical", a user might think the function ran on what they entered rather than the clamped value.

Proposal that may be out of the scope of this: I think we need to allow blocking an event trigger if an input component has an invalid input. Another use-case might be an optional kwarg, that when set to False, behaves as such:

• for Image/Audio/File/etc component , something must be uploaded for that event to trigger
• for Dropdown/Radio/CheckboxGroup with optional=False, something must be selected for that event to trigger
• Textboxes/Numbers cannot be empty

If an event tries to trigger with an empty optional=False component, the StatusTracker for that component could become a red outline, similar to how in "generating" mode the StatusTracker has a glowing orange outline.

[abidlabs]

So if a user submits a number out of range, it gets clamped in the backend? That might be a bit "magical", a user might think the function ran on what they entered rather than the clamped value.

Ohh good point @aliabid94. Maybe we raise a gr.Error() instead of clamping the values?

Proposal that may be out of the scope of this: I think we need to allow blocking an event trigger if an input component has an invalid input. Another use-case might be an optional kwarg, that when set to False, behaves as such:

Yup this would be handy also to block the Submit button while a file is uploading, but out of scope of this PR for sure

[artegoser]

Maybe then it would be better to limit the number in the frontend, too, so that the user can't add a number that is out of bounds. When the number changes, check it and limit it if necessary.

[abidlabs]

Maybe we raise a gr.Error() instead of clamping the values?

Can we do the same for Slider @dawoodkhan82? Would close #3878

[abidlabs]

Let's get this merged in @dawoodkhan82. For now, the only change that needs to be made is that we should raise a gr.Error() if a user submits a value that is outside of the range of the gr.Number(), instead of clamping it.

Later on, we can implement @aliabid94's suggestion, which is to block the submit button altogether

cc @hannahblair if you have any suggestions on validation of the gr.Number()

[aliabid94]

In Slider, we've called the arguments minimum and maximum. I feel like we should use the same arg names (could change slider to use min and max, and then pull minimum and maximum out of kwargs with a warning for backwards compatibility)

[aliabid94]

The error border theme variable that you've changed also affects the error messages. See below the pink borders.

[akx]

How are there 177 commits in this PR..?