Gradio 4.0 Tracking Issue

[abidlabs]

Tracking Issue for Gradio 4.0 (see milestone)

Goals

• Launch 4.0 with support for community components
• Launch quickly (speed & experimentation, not perfection)
• Minimize breaking changes in 4.0 as much as possible so users can easily upgrade
• Have no need for breaking changes from 4.0 to 4.x

TODOs

Build End-to-End Test Suite

• [x] Get the kitchen sink test suite working without mocks (@pngwn)
• [x] Brainstorm various paths (queue vs. no queue, mount vs. no mount, then(), cancels, every, embedded demos) and write tests for them (@dawoodkhan82)
• [x] Reduce CI time to <10 minutes (@freddyaboulton)

Strengthening Core Components (@hannahblair for frontend, @abidlabs for backend)

• [x] Go through all 33 components one-by-one and fix bugs so that the components serve as good templates for community components. Be good to take an accessibility pass while we’re doing this, as well as organize code for readability
• [x] Known dataframe improvements: #2209, #2666, #3284, #3286
• [x] Consolidate Dataframe and Dataset components - mentioned in slack and noting here so we don't forget. Can remove if we disagree
• [x] Improve names of parameters - make breaking changes where necessary. For example in #4470, we noted that the preview and enable_preview parameters (both bool) of Gallery are confusing and kind of overlap.

Refactor components.py to simplify creation of new components (@aliabid94 @freddyaboulton)

• [x] simplify components.py to have just a couple of functions
• [x] Make it so that examples can accept any value in preprocess
• [x] Remove as_example(), style(), interpetation, IOComponent
• [x] Simplify update() so it doesn't need to be explicitly written for every component
• [x] See #3438

Standardize the data types between frontend/backend (@freddyaboulton)

• [x] Use dataclasses instead of dictionaries
• [x] Consistency between components
• [x] Fix API for Image component
• [x] Fix API for File component
• [x] Fix API for all JSONSerializable components
• [x] Use the same dataclass/schema for different components where possible

Creating community components locally (@freddyaboulton @pngwn)

• [x] Define workflow for creating components
• [x] Be able to load a folder containing py/js (register custom components)
• [x] Frontend decides how to display component examples

Dev environment for local components (@freddyaboulton @pngwn)

• [x] CLI tooling
• [x] Watch/reload script

Share community components on Spaces and load components from Spaces (@freddyaboulton @pngwn)

• [x] Upload via CLI
• [x] Use via Python (perhaps require versioning as a security measure)

Use /upload for all components (@aliabid94)

• [x] #6218
• [x] #6219
• [x] Any “blob” gets uploaded. Two options: every blob gets uploaded or the schema determines whether the data gets uploaded

Support dynamic configs (@aliabid94)

• [ ] at least the backend should be able to work with an updated config
• [ ] Split the config into two: app level config vs component state
• [ ] might enable gr.If / gr.List later on

Make the queue enabled by default (@aliabid94)

• [x] Potentially with larger concurrency
• [x] Ping google colab about websockets

Deprecation (@abidlabs)

• [x] Deprecate inputs.py, outputs.py, interpretation.py
• [x] Deprecate deprecation.py (ability to pass in arbitrary kwargs to many Gradio classes)
• [x] Deprecate gr.Timeseries

Internationalization (@hannahblair)

• [x] Update all i18n tokens (#1078)
• [x] Provide a way for users to provide i18n for custom components
• [x] Provide a way for users to provide their own i18n for labels, etc. for built-in Gradio components

Have all endpoints named by default (@freddyaboulton)

• [x] three options: None (infers from fn name), str, False
• [x] Interfaces still have “/predict” name

When multiple events are submitted, ensure the final event runs (@dawoodkhan82)

• [x] #1592
• [x] #1954

_Properly expose and document _js parameter_ (@dawoodkhan82)

• [x] More research should be done by looking at usage on Spaces, but we think there are 3 use cases / needs:
• [x] Manipulate data: this is the intended behavior of _js and we just need documentation (and renaming _js -> js)
• [x] Change behavior of component: this should be discouraged and instead custom component should be used (when released
• [x] Usage within Blocks.load(). Instead, we should add a separate mechanism for loading app-level js by specifying a filepath to the Blocks() class itself

[akx]

Nice to see the roadmap. Can I add some thoughts:

• (soft) deprecation of various app-wide kwargs for Blockses or Interfaces, such as theme= and analytics_enabled=. (We touched on this on #3957); maybe a hard look at all of the arguments for the classes to consider whether they're in the right place?
• removal of **kwargs wherever possible, for a less "anything goes" API, and on a similar note, more kwargs-only APIs (e.g. constructors).
• ESlint for frontend code quality (as touched upon on the unfortunate #4277) – there's a branch I made around that time that sets it up with a basic config, just rebased now (can make a PR too): https://github.com/gradio-app/gradio/compare/main...akx:gradio:eslint
• (maybe a bit wild) fn_index -> fn_id, and attempting to find human-readable function names when possible

• 4300

• 4278

[abidlabs]

Thanks @akx for the suggestions!

removal of **kwargs wherever possible, for a less "anything goes" API, and on a similar note, more kwargs-only APIs (e.g. constructors).

I'm in favor of adding this to the milestone^

deprecation of various app-wide kwargs for Blockses or Interfaces, such as theme= and analytics_enabled=

I don't think we'll do this^ at this time as this is a pretty handy DX for simple apps

The other items are not backwards-incompatible so we can add after 4.0 release incrementally if they make sense.

[abidlabs]

Added deprecation and i18n to the list above

[freddyaboulton]

Most of this got done! What did not got turned into a new issue!