{"guide": {"name": "interface-state", "category": "building-interfaces", "pretty_category": "Building Interfaces", "guide_index": 3, "absolute_index": 6, "pretty_name": "Interface State", "content": "# Interface State\n\nSo 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*.\n\n## Global State\n\nIf 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.\n\n```python\nimport gradio as gr\n\nscores = []\n\ndef track_score(score):\n    scores.append(score)\n    top_scores = sorted(scores, reverse=True)[:3]\n    return top_scores\n\ndemo = gr.Interface(\n    track_score, \n    gr.Number(label=\"Score\"), \n    gr.JSON(label=\"Top Scores\")\n)\ndemo.launch()\n```\n\nIn 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.\n\n## Session State\n\nAnother 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:\n\n1. Pass in an extra parameter into your function, which represents the state of the interface.\n2. At the end of the function, return the updated value of the state as an extra return value.\n3. Add the `'state'` input and `'state'` output components when creating your `Interface`\n\nHere's a simple app to illustrate session state - this app simply stores users previous submissions and displays them back to the user:\n\n\n```python\nimport gradio as gr\n\ndef store_message(message: str, history: list[str]):\n    output = {\n        \"Current messages\": message,\n        \"Previous messages\": history[::-1]\n    }\n    history.append(message)\n    return output, history\n\ndemo = gr.Interface(fn=store_message, \n                    inputs=[\"textbox\", gr.State(value=[])], \n                    outputs=[\"json\", gr.State()])\n\ndemo.launch()\n```\n<gradio-app space='gradio/interface_state'></gradio-app>\n\n\nNotice 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.\n\nThe 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. \n\nNote: 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](/guides/state-in-blocks/). Alternatively, if you are building a chatbot that maintains user state, consider using the `ChatInterface` abstraction, [which manages state automatically](/guides/creating-a-chatbot-fast).\n", "tags": [], "spaces": [], "url": "/guides/interface-state/", "contributor": null}}