[Live] Fixing bug where inputs would not re-render if the value changed #250
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
norkunas
reviewed
Jan 28, 2022
| @@ -5,6 +5,8 @@ import { combineSpacedArray } from './string_utils'; | |||
| import { buildFormData, buildSearchParams } from './http_data_helper'; | |||
| import { setDeepData, doesDeepPropertyExist, normalizeModelName } from './set_deep_data'; | |||
| import { haveRenderedValuesChanged } from './have_rendered_values_changed'; | |||
| import { normalizeAttributesForComparison } from './normalize_attributes_for_comparison'; | |||
| import { cloneHTMLElement } from "./clone_html_element"; | |||
There was a problem hiding this comment.
Suggested change
| import { cloneHTMLElement } from "./clone_html_element"; | |
| import { cloneHTMLElement } from './clone_html_element'; |
for consistency? :)
|
Ran into a case today where I've defined a modal (with managed form) in a LiveComponent and after changing value in form everything was re-rendered and modal was closed, so |
Ideally, yes! That's exactly the case that we should test to make sure works :) |
weaverryan
force-pushed
the
live-fix-non-updating-value
branch
from
8ca3f8c to
a27fdd3
Compare
|
And I think this also fixed the #102 Bug H? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
NOTE to self: I'm considering reversing this PR as it has some side effects where we lose input values on re-render. That can be solved withdata-live-ignore, but it may be better to reverse this, and "fix" the original problem by telling the user to add adata-live-updateattribute (or something like that) where we opt INTO re-rendering. There is basically a situation where we don't know if the user will want a form element to re-render (and update the value) or not. And so, the user needs to choose. The question is, which way should the "default" be.For example, if an input rendered initially empty, then you typed
into it, and, on re-render, the value was set BACK to the original,
the input would not update on re-render, and it would be stuck
with the old value.
This was because the old input node and new input node were seen
as identical... and so morphdom didn't bother to update that node.
However, in reality, the value property of the "old" input had
been changed and would no longer match the value "attribute" of the
incoming input. Effectively, the 2 inputs had different values, but
this difference was not caught by the system.