[Fix] Being unable to determine the form a current element is in #10752
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #8761
Describe your changes
When an element is created with dg._block() the _form_data will be propagated from its parent, but when an element is created with a dg._enqueue it will not. This makes it so the current code to find a form will not be able to find the right form, so the easiest way is just making _enqueue propagate a form. ( current code to find the form: )
streamlit/lib/streamlit/elements/lib/form_utils.py
Lines 43 to 59 in 4d0013c
But this makes it so the element after being created has the proper _form_data, so the above code could just be
I have also an alternative suggestion that i think might be much cleaner but i wanted a second opinion since it would mean deleting 2 tests. But i find that these tests are highly problematic, let's look:
streamlit/lib/tests/streamlit/form_utils_test.py
Lines 62 to 75 in 4d0013c
They are expecting that, if when
_current_formis called there is a form in the context stack then it should mean there is a form in the element being created, it has the same assumption in the_current_formfunction which iterates the current context until it finds a _form_data (it does this when the dg is parentless, so st or st.sidebar etc). However this is wrong and i'll give an example:In here (run from origin/develop) the form_submit_button is erroneously thought to be in a form since the
_current_formfunction checks the closest context, sees no form, goes to the next and sees a form, but the context does not reflect the actual structure, it should iterate the parents!I know realistically no one writes an interface like this, but what happens when you run this piece of code is you get a submit button, outside of any form, and a form without a submit button inside it, instead of an exception.
So the cleaner alternative would be:
test_is_in_form_true_when_dg_stack_has_formandtest_is_in_form_false_when_dg_stack_has_no_formis deleted_current_formfunction actually iterates the parents of the active_dg until it hits the form dg which has a _form_dataSomething like
Which one works best?
GitHub Issue Link (if applicable)
Fixes #8761
@Asaurus1 @kmcgrady I'm tagging you two because i saw you were interested in the issue
Testing Plan
I have added 2 new unit tests that reflect the desired behavior in the mentioned issue (these tests fail on the current origin/develop branch)
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.