[feature request] [ux] `gradio.TextArea` to display elements of string arrays as lines

[vadimkantorov]

Currently it would just display the passed string array as

["a", "b"]

instead of

a
b

[abidlabs]

Thanks @vadimkantorov but I would disagree with this suggestion. The gr.Textbox() is a basic component that should not do any sort of postprocessing input. We are working on creating custom components, which will allow you to easily "clone" the existing Gradio components and make modifications, so this is something we can try then! I'll relabel this issue accordingly.

[vadimkantorov]

I guess that's why I mentioned TextArea :) as it makes clear that multiple lines are being displayed (there is even a lines/max_lines args)

Currently TextArea derives from TextBox, but it might grow in functionality and also support string lists

[pngwn]

The problem is that we'd have to make some pretty significant assumptions about how people wanted such data structures to render.

What if someone wanted lists rendered comma separated on the same line? (Which is more natural to me)

And if we support lists then why not dicts or sets etc.

Additionally, for the case cited, it would be very simple to construct the appropriate string yourself. ",\n".join(List). For more complex cases it might be useful but it would be impossible to come up with an approach that actually did what people wanted as usecases vary so much for visual rendering of data structures.

I can't see us implementing this in core. If anything a formatting library would be more appropriate here.

[vadimkantorov]

Overall, I see your point.

The problem is that we'd have to make some pretty significant assumptions about how people wanted such data structures to render.

In this particular case, I think it might be okay to break the existing behavior as it was sort of implicit and not documented that it returns str/repr of passed object. So adding a special case for a list of strings might be okay (by default or with some option). And the users might preserve the existing undocumented behavior by adding return str(res). It might also be more explicit e.g. to add a separate control gradio.Repr or sth like this which would render an arbitrary Python object by applying repr to it (or it could be an alias for gradio.JSON)

In the meanwhile I'm using join/split fixups as a workaround :)

[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.