Alternative Component Update API in 4.0

[freddyaboulton]

• [x] I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe.
In https://github.com/gradio-app/gradio/issues/4774, there is a new api for component updates being proposed. In short, the proposal is to return a new component instance rather than using the update method. For example, gr.Dropdown(choices=['a', 'b', 'c']) as opposed to gr.Dropdown.update(choices=['a', 'b', 'c']).

I like this, but it requires every component's default value be None and then do some stuff under the hood to determine when components are created with event handlers and then back out what the values changed were.

I don't like having to enforce a particular signature on __init__ for components (an extra barrier for custom components) and it treats updating the value vs updating the other props of a component as different concepts.

Given we'll be storing the component state internally for each session, we can pass the current instance of the component to the event handler. Updating the component's props, will just be updating the properties of the component.

For an example:

def update_dropdown(dd):
    dd.value = 'b'
    dd.choices = ['a', 'b', 'c']
    return dd

Another example, inspired by modelscope demo that I've been looking at this week, where the event generates a video and opens an accordion:

def generate_video(prompt):
    vid = pipeline.generate(prompt.value)
    return gr.Video(value=vid), gr.Accordion(open=True)

Here's what I see as the pros and cons:

Pros

• updating components is updating properties. I think this is an api users would find intuitive. People ask in discord why updating properties in the event does not reflect in the frontend.
• No need to have strict guidelines along init signatures of components. Once the event handler returns a component, we take the returned value's state as the new current state. Some work would have to happen behind-the-scenes to only apply the diff in state in the backend though.
• No distinction between updating value vs updating prop. Everything is an update now.

Cons

• Very big breaking change. Every demo would break lol because event handlers only expect to receive the value, not a component instance. Maybe we can make this behavior opt-in for the inputs. Maybe via type hints.

[abidlabs]

The downside I see with:

def update_dropdown(dd):
    dd.value = 'b'
    dd.choices = ['a', 'b', 'c']
    return dd

is that now we are passing components as parameters instead of regular values, which means that you have to think about your Gradio app when you are writing your functions, and you can't test your functions in isolation from your Gradio app. Also, the API seems to have limited utility since you can only update a component's attributes if they are also inputs to your function, otherwise you have to return a gr.Component(...) anyways, like we do in this example:

def generate_video(prompt):
    vid = pipeline.generate(prompt.value)
    return gr.Video(value=vid), gr.Accordion(open=True)

I would be in favor of eliminating the .update() and instead just providing an instance of the component itself, which I think @aliabid94 also suggested in #4774

[aliabid94]

I have thought about a similar approach, where we embrace this "attribute getter/setter" API style entirely:

with gr.Blocks() as demo:
  num1 = gr.Number()
  num2 = gr.Number()
  operation = gr.Radio("add", "subtract", ...)
  result = gr.Number(visible=False)

  def calculate():
    result.visible = True
    if operation.value == "add"
      result.value = num1.value + num2.value
    elif operation.value == "subtract"
      ...

In this API, we override the getters and setters of all components, and use thread locals and websockets to get / send component updates immediately, in the same manner as we send gr.Warnings. Clearly a huge departure from our current style of event listeners.

Pros	Cons
No need to specify inputs and outputs	Need to specify interactive as it cannot be determined beforehand
Intuitive API	Very different from our current style

[abidlabs]

Two more cons:

• You can't test functions in isolation of your Gradio code anymore
• Because we no longer know the inputs/outputs, we can't generate API endpoints for functions

[abidlabs]

This has been implemented now!