Skip to content
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

Fix widget id stability #7003

Merged
merged 47 commits into from Jul 27, 2023
Merged

Conversation

AnOctopus
Copy link
Collaborator

Describe your changes

Fix existing widget id instability in slider, document how to safely access session state in widgets, and have register_widget check some common fields that shouldn't be used for a widget's identity.

GitHub Issue Link (if applicable)

Testing Plan

  • Unit Tests (JS and/or Python)
    Some additional python unit tests should be added

Contribution License Agreement

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

lib/streamlit/runtime/state/widgets.py Fixed Show fixed Hide fixed
lib/streamlit/runtime/state/widgets.py Fixed Show fixed Hide fixed
lib/streamlit/runtime/state/widgets.py Fixed Show fixed Hide fixed
lib/streamlit/runtime/state/widgets.py Fixed Show fixed Hide fixed
@AnOctopus AnOctopus marked this pull request as ready for review July 17, 2023 22:37
`parsed_value` is always set in the function if `v` has the required
type, but codeql doesn't understand that. Use direct returns so it sees
the impossible case as an implicit None return, which is valid.
It has a different meaning than for most widgets.
Copy link
Collaborator

@kmcgrady kmcgrady left a comment

Choose a reason for hiding this comment

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

Do you think it makes sense to write tests for each widget that does the following:

patch compute_widget_id

call widget function

assert that compute_widget_id includes all args minus the disallowed for the widget (eg. disabled.

My fear is worrying that a new field is added, but not added to the computer widget id. This test would at least fail here and cause a conversation to be had on whether it should be disallowed or just ensured it's added to the compute_widget_id

lib/streamlit/runtime/state/widgets.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@vdonato vdonato left a comment

Choose a reason for hiding this comment

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

LGTM

lib/streamlit/elements/widgets/button.py Outdated Show resolved Hide resolved
@AnOctopus
Copy link
Collaborator Author

Do you think it makes sense to write tests for each widget that does the following:

patch compute_widget_id

call widget function

assert that compute_widget_id includes all args minus the disallowed for the widget (eg. disabled.

My fear is worrying that a new field is added, but not added to the computer widget id. This test would at least fail here and cause a conversation to be had on whether it should be disallowed or just ensured it's added to the compute_widget_id

We could write those tests, but it seems annoying, and I'm not sure it adds that much value. I expect it to be easy to remember to update the call, and any e2e test that has multiple copies of a widget with just that argument differing will get a duplicate id error (though maybe that won't happen because they'll have different labels? unsure).

Even if we decide it would be worth having those tests, I don't want the PR to be blocked on them. I'd rather they be a quick followup.

@AnOctopus
Copy link
Collaborator Author

LGTM

Cool. I'll wait to merge it until tomorrow, to give Lukas a chance to do a closer check of the data editor id calculation, since I want his verification that we're using the arrow table.

@vdonato
Copy link
Collaborator

vdonato commented Jul 26, 2023

We could write those tests, but it seems annoying, and I'm not sure it adds that much value. I expect it to be easy to remember to update the call, and any e2e test that has multiple copies of a widget with just that argument differing will get a duplicate id error (though maybe that won't happen because they'll have different labels? unsure).

I think we won't get any e2e test coverage for this since most of our tests have widgets with different labels.

There's probably a clever way to write these tests without ridiculous amounts of code duplication using inspect.signature on the widget functions and asserting that the kwargs that compute_widget_id is called with match (with the exception of the few parameters that we don't expect to be included in the widget ID calc). I'd probably be okay with that being a quick followup PR after this one is checked in, though, unless the inspect.signature trick makes writing these tests not too difficult.

Copy link
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.

Overall LGTM 👍 I added some suggestions for the data editor implementation to make it a bit more similar to the data used for ID generation in the current version.

lib/streamlit/elements/widgets/data_editor.py Outdated Show resolved Hide resolved
lib/streamlit/elements/widgets/data_editor.py Outdated Show resolved Hide resolved
lib/streamlit/elements/widgets/chat.py Show resolved Hide resolved
@AnOctopus AnOctopus merged commit d7a1977 into streamlit:develop Jul 27, 2023
48 checks passed
@AnOctopus AnOctopus deleted the fix/widget-id-stability branch July 27, 2023 23:16
vdonato added a commit that referenced this pull request Aug 1, 2023
Now that we've merged #7003, some of the comments we have about when certain
fields are written to widget protos are now stale. While removing these comments, we also
move a few lines around so that lines where we're writing to widget protobufs are grouped.
eric-skydio pushed a commit to eric-skydio/streamlit that referenced this pull request Dec 20, 2023
eric-skydio pushed a commit to eric-skydio/streamlit that referenced this pull request Dec 20, 2023
…amlit#7093)

Now that we've merged streamlit#7003, some of the comments we have about when certain
fields are written to widget protos are now stale. While removing these comments, we also
move a few lines around so that lines where we're writing to widget protobufs are grouped.
zyxue pushed a commit to zyxue/streamlit that referenced this pull request Mar 22, 2024
zyxue pushed a commit to zyxue/streamlit that referenced this pull request Mar 22, 2024
…amlit#7093)

Now that we've merged streamlit#7003, some of the comments we have about when certain
fields are written to widget protos are now stale. While removing these comments, we also
move a few lines around so that lines where we're writing to widget protobufs are grouped.
zyxue pushed a commit to zyxue/streamlit that referenced this pull request Apr 16, 2024
zyxue pushed a commit to zyxue/streamlit that referenced this pull request Apr 16, 2024
…amlit#7093)

Now that we've merged streamlit#7003, some of the comments we have about when certain
fields are written to widget protos are now stale. While removing these comments, we also
move a few lines around so that lines where we're writing to widget protobufs are grouped.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants