[BUGFIX] Fix SimpleNodelist to replace instead of appending new nodes.#149
Merged
blocktrron merged 1 commit intofreifunk:mainfrom Apr 28, 2025
Merged
Conversation
The actual fix is saving the patched node. This effectively reverts (part of) freifunk@0051309 I am not really sure why thats relevant for patch, but I could not get it working without. However I also noticed that there is an edge case when on the first load the list shows no nodes and in subsequent reloads it gets nodes, it will append the node list always at the bottom, which may not be correct. To avoid this and to make it more robust, this component is now refactored, and uses an extra container div thats always in the dom. That way it already reserves a place in the dom, even when no nodes are there yet.
aligator
added a commit
to tecff/meshviewer
that referenced
this pull request
May 4, 2025
Similar problem as freifunk#149. However I think I understand it now better: the example on https://github.com/snabbdom/snabbdom describes that the first patch should be on the dom-element, but the second patch should be on the vnode from before. So it now saves the last vnode and patch it. Only on the first patch (if vnode is not set yet), it patches the element.
3 tasks
aligator
added a commit
to aligator/meshviewer
that referenced
this pull request
May 4, 2025
…ifunk#152) Also fixes the table to be loaded correctly when the filter is removed again. Similar problem as freifunk#149 , freifunk#137. Patches the dom element only the first time. after that it patches the previous vnode.
This was referenced May 4, 2025
aligator
added a commit
to aligator/meshviewer
that referenced
this pull request
May 4, 2025
…ifunk#152) Also fixes the table to be loaded correctly when the filter is removed again. Similar problem as freifunk#149 , freifunk#137. Patches the dom element only the first time. after that it patches the previous vnode.
skorpy2009
pushed a commit
that referenced
this pull request
May 4, 2025
Similar problem as #149. However I think I understand it now better: the example on https://github.com/snabbdom/snabbdom describes that the first patch should be on the dom-element, but the second patch should be on the vnode from before. So it now saves the last vnode and patch it. Only on the first patch (if vnode is not set yet), it patches the element.
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
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.
Description
The actual fix is saving the patched node.
This effectively reverts (part of)
0051309
So the simplest fix would be:
->
(however the typing is anyway wrong here, but that doesn't really matter here)
I am not really sure why thats relevant for patch, but I could not get it working without.
I thought that the patch always replaces the "diff", but maybe I don't understand Snabbdom correctly^^
Also I also noticed that there is an edge case when on the first load the list shows no nodes
and in subsequent reloads it gets nodes, it will append the node list always at the bottom, which may not be correct.
To avoid this and to make it more robust,
this component is now refactored, and uses an extra container div thats always in the dom.
That way it already reserves a place in the dom, even when no nodes are there yet.
If I should split this into a separate pull request, just tell me.
However as I anyway refactored most code, it did not make sense to me to split this up.
Motivation and Context
Closes: #138
And also makes the list more robust to changes (e.g. if the first dataset is empty and further updates contain nodes)
How Has This Been Tested?
Tested on ff and chrome.
To test the behavior on what happens when there are first no nodes, i temporarily decreased the refresh timer and I also mocked the data.
Screenshots/links:
Checklist: