Validation on a `gr.Dataframe`

[davidbernat]

Many applications benefit from rich configuration files, most notably deep and machine learning. Yet, these create overhead for the backend system passing values between from the front-end, for the rendering system, for the design layout, and for the application software developer to maintain. For many technical users, these layouts are less necessary. In many cases, applications have large configuration files, with only a small number of first-tier configuration valuables which the user, whether technical or mainstream, should or may want to use.

I propose a new element which is like a gr.Table() yet loaded with a list of dictionaries, which an additional feature that each value may be specified with a type, i.e., one value may be typed to be string; another may be typed to a number; yet another may be typed to a Boolean. The editing interface can remain the same as the gr.Table() interface, i.e., the user is expected to type True or False or, in another field specify the string value.

The list of dictionaries input would be simple. dict(name='learning_rate', value=0.01, type='number', interactive=True) The type can be inferred implicitly from the value and the interactive can be inherited from the top-line instantiation of gr.TypedConfig()

The element would require an internal, small type-checking function upon .change, and a UI graphical function which notifies a user when an invalid type conflict has been created (such as a red box around the new value). More sophisticated versions could further prevent other buttons or functions to be called if the gr.TypedConfig() element is in conflict. The CSS parameters of elements at the render stage would appear to be capable of doing this, although I have not used that feature yet.

I have not yet used the Creating A New Component feature of Gradio. But if this is a good 'first issue' I would be happy to give this a go. I think this new feature could be very valuable to the community and lend insight into the backend restructuring of the ongoing Gradio development.

[abidlabs]

Thanks for the suggestion @davidbernat. I'm trying to understand the component you are requesting, but not sure I have a clear picture. Is the idea to have something like a gr.DataFrame (we don't have a gr.Table, so I think you are referring to the DataFrame component) whose columns can be set to different gradio components types?

[davidbernat]

(Yes. You are correct: I meant gr.DataFrame.) @abidlabs: Something even simpler: a DataFrame component who row/column elements can be type-enforced and CSS formatted. For instance, for the Galactica model, my application service ingests a YAML configuration file and automatically generates a wonderful Gradio GUI.

For technical users, or to save space, or for non first-tier parameters, a simpler gr.DataFrame component would suffice. I would add three bells-and-whistles:

1. I would like to type-enforce each element in the value column according to the variable datatype requirement. This can be implemented on a small lambda function applied at .change() to the element that changed. Simple.
2. I would like to CSS render the red box around the element when the type-enforced requirement fails. The CSS usage of Gradio still mystifies me.
3. Other improvements would be to identify the type implicitly and optimally remove the third column. Simple.

It sounds as though the proposed Gradio component does not exist and is a straightforward first issue for the the Creating A New Component feature of Gradio.

[abidlabs]

Ah I see, thanks for the clarfication @davidbernat. I agree, having the ability to do some validation on DataFrame components would be quite nice. However, we are working on making custom components a lot easier to write and easier to maintain (e.g. they wouldn't have to be added to the Gradio core codebase) -- my suggestion would be to wait until we have a better system for custom components, and then we can give pointers on how to implement custom component for this use case

[davidbernat]

Excellent. Did not know custom components needed to be in the gradio-app/gradio repository to be accessible. Agree. Can we link this thread to the main thread developing that extensibility?

I have found the CSS difficult to get ahold of, in part because it does not appear all CSS features are available; almost, mostly, I rarely use CSS. Where are the definitive best threads to start rolling up the sleeves on CSS?

[abidlabs]

Hey! We've now made it possible for Gradio users to create their own custom components -- meaning that you can write some Python and JavaScript (Svelte), and publish it as a Gradio component. You can use it in your own Gradio apps, or share it so that anyone can use it in their Gradio apps. Here are some examples of custom Gradio components:

• A "Rich Textbox" that allows you to write bold/italics/colored text
• A "Folium Map Viewer" component that allows you to use interactive maps

You can see the source code for those components by clicking the "Files" icon and then clicking "src". The complete source code for the backend and frontend is visible. In particular, its very fast if you want to build off an existing component. We've put together a Guide: https://www.gradio.app/guides/five-minute-guide, and we're happy to help. Hopefully this will help address this issue.

[abidlabs]

I'll go ahead and close this issue since we are not planning to include this in the core Gradio library. But happy to help if you are interested in making this a custom Gradio component (feel free to ask questions in this issue).

[davidbernat]

Guys. Between you and me, this is a year old ticket that I already solved in prototyping, and is entirely a result of Gradio not opening up its interfaces' code. Between you, me, FAIR, and Google BRAIN let us not fleece the public so early. Why do you?