New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add st.status
container
#7140
Add st.status
container
#7140
Conversation
st.status
containerst.status
layout container
frontend/lib/src/components/elements/Expander/Expander.test.tsx
Outdated
Show resolved
Hide resolved
lib/tests/streamlit/external/langchain/streamlit_callback_handler_test.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments about the tests. Implementation looks good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for the proto changes (note I didn't give the rest of the code a thorough review)
@@ -44,7 +44,8 @@ message Block { | |||
|
|||
message Expandable { | |||
string label = 1; | |||
bool expanded = 2; | |||
optional bool expanded = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the addition of the optional
keyword needed here? fields in proto3 are always technically optional, so I'm not sure if this makes any real difference (+ I'm not entirely sure if it can somehow affect backwards-compatibility-related things but don't see why it would hurt)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While fields are indeed optional
as default, they are not nullable
(as far as I understand this). For the update
functionality, we need to differentiate between expanded
being provided (False
or True
) or it being absence (== null) in which case we don't modify the expanded state in the frontend. Therefore, I think we need to use optional
in this case. I also came to a similar conclusion on backwards-compatibility; not 100% sure, but I couldn't find a reason why it could be problematic.
* Add icon to expander * Add implementation for st.status * Fix * Add top comment * Add docstring * Fixes * Improve implementation * Some refactoring * Minor fixes * Add auto collapse mode * Add auto collapse mode * Various fixes and improvements * Add empty expander test * Add empty expander test * Disallow empty for normal expander * Apply various updates * Some refactoring * Update status container * Update callback handler * Change empty state for expander * Move icon implementation to expander * Add e2e tests * Add unit tests * Add empty expander e2e test * Update comment * Cleanups * Cleanup * Add metrics * Update docstring * Update snapshot * Add test for empty status * Use smaller block * Update docstrings * Don't change color on hover if empty * Update docstrings based on feedback * Minor change * Update playback tests * Integrated PR feedback * Fix test * Use descriptive names for screenshot tests * Update status snapshots * Update st.status docstring --------- Co-authored-by: Debbie Matthews <debbie.matthews@snowflake.com>
* Add icon to expander * Add implementation for st.status * Fix * Add top comment * Add docstring * Fixes * Improve implementation * Some refactoring * Minor fixes * Add auto collapse mode * Add auto collapse mode * Various fixes and improvements * Add empty expander test * Add empty expander test * Disallow empty for normal expander * Apply various updates * Some refactoring * Update status container * Update callback handler * Change empty state for expander * Move icon implementation to expander * Add e2e tests * Add unit tests * Add empty expander e2e test * Update comment * Cleanups * Cleanup * Add metrics * Update docstring * Update snapshot * Add test for empty status * Use smaller block * Update docstrings * Don't change color on hover if empty * Update docstrings based on feedback * Minor change * Update playback tests * Integrated PR feedback * Fix test * Use descriptive names for screenshot tests * Update status snapshots * Update st.status docstring --------- Co-authored-by: Debbie Matthews <debbie.matthews@snowflake.com>
* Add icon to expander * Add implementation for st.status * Fix * Add top comment * Add docstring * Fixes * Improve implementation * Some refactoring * Minor fixes * Add auto collapse mode * Add auto collapse mode * Various fixes and improvements * Add empty expander test * Add empty expander test * Disallow empty for normal expander * Apply various updates * Some refactoring * Update status container * Update callback handler * Change empty state for expander * Move icon implementation to expander * Add e2e tests * Add unit tests * Add empty expander e2e test * Update comment * Cleanups * Cleanup * Add metrics * Update docstring * Update snapshot * Add test for empty status * Use smaller block * Update docstrings * Don't change color on hover if empty * Update docstrings based on feedback * Minor change * Update playback tests * Integrated PR feedback * Fix test * Use descriptive names for screenshot tests * Update status snapshots * Update st.status docstring --------- Co-authored-by: Debbie Matthews <debbie.matthews@snowflake.com>
Describe your changes
This PR adds
st.status
, a new layout container focused on displaying output from long-running tasks and processes. This PR will also update the old implementation used for the langchain callback handler.Testing Plan
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.