Skip to content

Add parallel fragments description#1490

Open
pplettner wants to merge 1 commit into
streamlit:mainfrom
pplettner:parallel-fragments-docs
Open

Add parallel fragments description#1490
pplettner wants to merge 1 commit into
streamlit:mainfrom
pplettner:parallel-fragments-docs

Conversation

@pplettner

Copy link
Copy Markdown

📚 Context

Added a whole section in "Working with fragments" describing the behaviour of parallel fragments.

Contribution License Agreement

By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.

@pplettner pplettner requested a review from a team as a code owner June 17, 2026 16:44
@netlify

netlify Bot commented Jun 17, 2026

Copy link
Copy Markdown

Deploy Preview for streamlit-docs ready!

Name Link
🔨 Latest commit 55cc197
🔍 Latest deploy log https://app.netlify.com/projects/streamlit-docs/deploys/6a32cf04cc5fbf000849aa06
😎 Deploy Preview https://deploy-preview-1490--streamlit-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.


When `parallel=True`, the behavior depends on the type of rerun:

- **During a full-app rerun**, Streamlit dispatches the fragment to a thread pool. It runs concurrently with your other parallel fragments and with the rest of your main script, rather than blocking on each fragment in turn. If `slow_chart` and `slow_table` each take two seconds, running them in parallel lets your app finish in about two seconds instead of four.

@sfc-gh-lwilby-1 sfc-gh-lwilby-1 Jun 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] I am not super familiar with the formatting in the docs repo, but I am wondering if this should be unbolded? We should keep it consistent with the rest of the docs.


- **During a fragment rerun** (when a user interacts with a widget inside the fragment), execution stays sequential. The fragment runs by itself on the main thread, exactly like a non-parallel fragment. This keeps your state updates predictable when a user is actively interacting with a fragment.

Parallel fragments are most helpful when each fragment does independent, time-consuming work. If your fragments are fast or depend on each other's results, running them in parallel adds complexity without a meaningful speedup.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[suggestion] I think if they depend on each other's results it won't be possible to design the code with parallel fragments, perhaps we should drop that, or clarify that there is no mechanism to sync content between parallel fragments.

- [`st.switch_page`](/develop/api-reference/navigation/st.switch_page)
- Writing to containers created outside the fragment.

These commands work normally during a fragment rerun (for example, after a user interacts with a widget inside the fragment), because fragment reruns are sequential. If you need one of these commands, call it from a non-parallel fragment or from the main body of your script.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[suggestion] Maybe we should give an example of how to run these from a fragment rerun. Basically, you can conditionally open a dialog based on a user interaction with the fragment (that would trigger a fragment rerun) but not open the dialog unconditionally in the fragment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants