Skip to content

[AdvancedLayouts] Adds a width parameters to st.line_chart.#11923

Merged
sfc-gh-lwilby merged 28 commits intodevelopfrom
feature/add-width-to-vega-charts
Aug 27, 2025
Merged

[AdvancedLayouts] Adds a width parameters to st.line_chart.#11923
sfc-gh-lwilby merged 28 commits intodevelopfrom
feature/add-width-to-vega-charts

Conversation

@sfc-gh-lwilby
Copy link
Copy Markdown
Collaborator

@sfc-gh-lwilby sfc-gh-lwilby commented Jul 13, 2025

Describe your changes

This PR is part of the [AdvancedLayouts] project and introduces a new width parameter to the chart elements.

Screenshot 2025-08-19 at 5 02 30 PM

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.

@snyk-io
Copy link
Copy Markdown
Contributor

snyk-io bot commented Jul 13, 2025

🎉 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)

@sfc-gh-lwilby sfc-gh-lwilby force-pushed the feature/add-width-to-vega-charts branch from 0468898 to fc51e5b Compare July 13, 2025 11:47
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Jul 13, 2025

✅ PR preview is ready!

Name Link
📦 Wheel file https://core-previews.s3-us-west-2.amazonaws.com/pr-11923/streamlit-1.48.1-py3-none-any.whl
🕹️ Preview app pr-11923.streamlit.app (☁️ Deploy here if not accessible)

@sfc-gh-lwilby sfc-gh-lwilby force-pushed the feature/add-width-to-vega-charts branch 2 times, most recently from eb252fd to 8235550 Compare August 18, 2025 10:06
@sfc-gh-lwilby sfc-gh-lwilby changed the title [WIP][AdvancedLayouts] Adds a width parameters to vega lite charts. [WIP][AdvancedLayouts] Adds a width parameters to st.line_chart. Aug 18, 2025
@sfc-gh-lwilby sfc-gh-lwilby added security-assessment-completed change:feature PR contains new feature or enhancement implementation impact:users PR changes affect end users labels Aug 18, 2025
@sfc-gh-lwilby sfc-gh-lwilby requested a review from Copilot August 19, 2025 14:50
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

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 width and height parameters to st.line_chart with support for "stretch", "content", and integer values
  • Deprecates use_container_width parameter 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

@sfc-gh-lwilby sfc-gh-lwilby marked this pull request as ready for review August 19, 2025 18:55
@sfc-gh-lwilby sfc-gh-lwilby changed the title [WIP][AdvancedLayouts] Adds a width parameters to st.line_chart. [AdvancedLayouts] Adds a width parameters to st.line_chart. Aug 19, 2025
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

width = "stretch" if use_container_width else "content"

validate_width(width, allow_content=True)
validate_height(height, allow_content=True)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

@sfc-gh-lwilby sfc-gh-lwilby force-pushed the feature/add-width-to-vega-charts branch from db72831 to 5dfc9b5 Compare August 22, 2025 17:16
Comment on lines -124 to -129
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
})
}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

ok, got it. So this was only used for isFullScreen below which is covered by the useContainerWidth below

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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".

Copy link
Copy Markdown
Collaborator

@lukasmasuch lukasmasuch left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@sfc-gh-lwilby sfc-gh-lwilby merged commit 5757402 into develop Aug 27, 2025
37 of 39 checks passed
@sfc-gh-lwilby sfc-gh-lwilby deleted the feature/add-width-to-vega-charts branch August 27, 2025 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

change:feature PR contains new feature or enhancement implementation impact:users PR changes affect end users

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants