sources/03_interface-state.md

Interface State

So far, we've assumed that your demos are stateless: that they do not persist information beyond a single function call. What if you want to modify the behavior of your demo based on previous interactions with the demo? There are two approaches in Gradio: global state and session state.

Global State

If the state is something that should be accessible to all function calls and all users, you can create a variable outside the function call and access it inside the function. For example, you may load a large model outside the function and use it inside the function so that every function call does not need to reload the model.

$code_score_tracker

In the code above, the scores array is shared between all users. If multiple users are accessing this demo, their scores will all be added to the same list, and the returned top 3 scores will be collected from this shared reference.

Session State

Another type of data persistence Gradio supports is session state, where data persists across multiple submits within a page session. However, data is not shared between different users of your model. To store data in a session state, you need to do three things:

1. Pass in an extra parameter into your function, which represents the state of the interface.
2. At the end of the function, return the updated value of the state as an extra return value.
3. Add the 'state' input and 'state' output components when creating your Interface

Here's a simple app to illustrate session state - this app simply stores users previous submissions and displays them back to the user:

$code_interface_state $demo_interface_state

Notice how the state persists across submits within each page, but if you load this demo in another tab (or refresh the page), the demos will not share chat history. Here, we could not store the submission history in a global variable, otherwise the submission history would then get jumbled between different users.

The initial value of the State is None by default. If you pass a parameter to the value argument of gr.State(), it is used as the default value of the state instead.

Note: the Interface class only supports a single session state variable (though it can be a list with multiple elements). For more complex use cases, you can use Blocks, which supports multiple State variables. Alternatively, if you are building a chatbot that maintains user state, consider using the ChatInterface abstraction, which manages state automatically.