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

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

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.

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()

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.

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/

Okay, I changed my mind.

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.

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

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.

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

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

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()

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)

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

How are there 177 commits in this PR..?