[AdvancedLayouts] Adds a width parameters to st.line_chart.#11923
[AdvancedLayouts] Adds a width parameters to st.line_chart.#11923sfc-gh-lwilby merged 28 commits intodevelopfrom
st.line_chart.#11923Conversation
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
0468898 to
fc51e5b
Compare
✅ PR preview is ready!
|
eb252fd to
8235550
Compare
st.line_chart.
There was a problem hiding this comment.
Pull Request Overview
This PR introduces width and height parameters to the st.line_chart function as part of the AdvancedLayouts project. The change begins the deprecation of use_container_width in favor of the new width parameter, with a mapping that treats use_container_width=True as equivalent to width="stretch" and use_container_width=False as equivalent to width="content".
Key changes:
- Adds new
widthandheightparameters tost.line_chartwith support for "stretch", "content", and integer values - Deprecates
use_container_widthparameter with warnings and migration guidance - Updates frontend components to handle new width/height configuration through layout config
Reviewed Changes
Copilot reviewed 14 out of 29 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| lib/streamlit/elements/vega_charts.py | Adds width/height parameters to line_chart function, implements use_container_width deprecation with validation |
| lib/tests/streamlit/elements/vega_charts_test.py | Adds comprehensive test coverage for new width/height parameters and deprecation behavior |
| frontend/lib/src/components/elements/ArrowVegaLiteChart/. | Updates Vega chart components to handle new layout configuration system |
| frontend/lib/src/components/shared/Toolbar/styled-components.ts | Updates toolbar styling to support string height values |
| frontend/lib/src/components/shared/FullScreenWrapper/styled-components.tsx | Ensures full screen wrapper has 100% height |
| frontend/lib/src/components/core/Block/StyledElementContainerLayoutWrapper.tsx | Adds layout handling for new width configuration in Vega charts |
| e2e_playwright/st_line_chart*.py | Adds E2E tests for new width/height functionality and visual regression testing |
| e2e_playwright/st_layouts_container_min_width*.py | Tests width behavior in horizontal container layouts |
st.line_chart.st.line_chart.
frontend/lib/src/components/shared/FullScreenWrapper/styled-components.tsx
Show resolved
Hide resolved
frontend/lib/src/components/core/Block/StyledElementContainerLayoutWrapper.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
This screenshot looks of. Is this intended, e.g. why is there such a big top padding? and most of the charts seem to be cut-off
There was a problem hiding this comment.
I think this is just a limitation of the screenshots, it can't fit all of the charts. It looks normal when the app is run locally. I was debating leaving out this snapshot for this one and just doing the regular screen width. Maybe I will check if I can also control the height.
...s_elements_test/st_layouts_container_various_elements-layout-dashboard-example[chromium].png
Show resolved
Hide resolved
| width = "stretch" if use_container_width else "content" | ||
|
|
||
| validate_width(width, allow_content=True) | ||
| validate_height(height, allow_content=True) |
There was a problem hiding this comment.
Could all this logic be moved into some kind of shared validation method or into generate_chart or self._altair_chart? Otherwise, it needs to be replicated for all our built-in commands, even though they are almost the same.
There was a problem hiding this comment.
I think only _vega_lite_chart should probably do all validation for built-in charts, altair, and vega_lite_chart. Maybe its even better to first add width & height to altair_chart and vega_lite_chart and after that to built-in charts. Since built-in charts are build on top of altair -> vega_lite_chart
There was a problem hiding this comment.
That makes sense, since I have this one ready now, I think it would be OK to do altair_chart and vega_lite_chart next and move this logic as part of that?
Originally I was going to do one PR for all, but it was feeling too large and I wanted to break it up and test each chart type individually. Line charts seemed like the easier ones, whereas vega_lite and altair have more potential issues since there are many types of charts and known issues with the facet charts so that's why I started with this one.
There was a problem hiding this comment.
I think that's fine, but probably makes sense to put the focus next on altair_chart & vega_lite_chart before touching any of the other built-in charts. Also, since all of these charts are using the exact same frontend implementation, it might be a bit too much overhead to add these comprehensive e2e tests for all these chart commands. E.g, it's probably fine to just have one vega chart command tested in the st_layouts_container test.
There was a problem hiding this comment.
Yeah, the min width ones I was not planning on adding for all chart types. But we may not want snapshot tests for the width for all chart types either. Probably some more coverage for the facet charts with fixed width since that is new.
db72831 to
5dfc9b5
Compare
frontend/lib/src/components/elements/ArrowVegaLiteChart/useVegaElementPreprocessor.ts
Show resolved
Hide resolved
| if ("vconcat" in spec) { | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any -- TODO: Replace 'any' with a more specific type. | ||
| spec.vconcat.forEach((child: any) => { | ||
| child.width = width | ||
| }) | ||
| } |
There was a problem hiding this comment.
Is this not required anymore for concat charts? The below part is only activated when useContainerWidth, do vconcat charts still work fine if a specific pixel width is set?
There was a problem hiding this comment.
So, there shouldn't be any change in this PR for vconcat charts because we default them to use_container_width in the backend. This is an assumption on my part that these are only st.vegalite_chart or st.altair_chart charts, not the convenience charts like area etc. Let me know if you think this is wrong ... it seems based on the docstrings this is the case.
Additionally, for fixed pixel charts useContainerWidth will be true here, but the logic is checking the new pixel width param so only for line charts so far.
When I get to altair_chart and vegalite_chart with pixel width I will have to test how it works with that since it will be a new feature.
There was a problem hiding this comment.
ok, got it. So this was only used for isFullScreen below which is covered by the useContainerWidth below
There was a problem hiding this comment.
I looked at this again and what I wrote above is not quite the right answer. This covers the same scenarios because previously we did this vconcat logic for useContainerWidth and isFullScreen, and now both of those are covered by useContainerWidth and useContainerHeight. Determining these including checking isFullScreen is done in ArrowVegaLiteChart now. I had to refactor this logic so it would cover stretching the height as well as the width now that we have height="stretch".
Describe your changes
This PR is part of the [AdvancedLayouts] project and introduces a new width parameter to the chart elements.
This PR also begins the process of deprecating use_container_width. The default is updated to None, and width will be used instead. If the user explicitly passes a value for use_container_width then that will take precedence. use_container_width=True is equivalent to width="stretch" and use_container_width=False is equivalent to width="content". The user will be given a warning and suggestion to use width instead. We will remove use_container_width after 12-31-2025`.
GitHub Issue Link (if applicable)
#8197
Testing Plan
Unit Tests (JS and/or Python) ✅
E2E Tests ✅
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.