|
|
Post by danielbeeke on Jan 2, 2021 14:17:37 GMT
I have read about the following comment:
If I would hit this issue, am I correct that it would manifest on here:
Where I have all kinds of small micro templates that are attached to a class. The child class may overwrite the template methods. All in all, templates can come from a lot of places and I think it might be that the caches mess it up.
But I am not too sure.
I have been reading the code but must admit some of it is complex for me and I should invest more time to understand.
Kind regards, Have a happy 2021 all  Daniel
|
|
|
|
Post by webreflection on Jan 2, 2021 15:24:46 GMT
u/domdiff owns nodes it's handling, 3rd party trashing content/nodes is a side-effect of 3rd party not being good scripts, as they shouldn't trash nodes they don't own ... but unfortunately, there are still a lot of cowboys out there using `innerHTML` (or even `outerHTML` for what it matters) believing their scripts are the only one working on the same page.
little rant a part, the issue is in every part of diffing, because the node is expected to be there in `insertBefore`, `replaceChild`, or `removeChild`, meaning if obtrusive scripts change handled nodes, the initial parent has no meaning anymore whatsoever.
This is the same with every template literal based diffing, but dare I say virtual DOM likely suffers the same, because the issue is 3rd party taking ownership, or trashing, nodes they are not supposed to touch.
That being said, I don't have time to read "fairly big and complex systems" so it'd be great if you could at least give me an example of what, where, and how, is failing, but the gist is: get rid of scripts that change the DOM without being authorized, or put render within a try catch and see how that goes.
|
|
|
|
Post by danielbeeke on Jan 2, 2021 15:52:38 GMT
Thanks for the information, I am grateful for the time you spend answering my questions, never meant to share the link for you to went through all the code. Maybe sharing the link was a bit unfortunate. I wanted to provide some context.
Anyway.. I think I only use uHtml there. What I meant with "I think it might be that the caches mess it up." is that it could be that I have multiple instances of a specific FieldType (class) that are somehow cached as the same object and for that reason I think I may hit the bug.
I will investigate it more.
|
|
|
|
Post by webreflection on Jan 2, 2021 18:10:22 GMT
as I don't have an example to judge, the caching issue can be caused only if you use the same reference for a specific node ... that means, if you use `html.for(ref, id)` in more than a place and that ends up being the same reference and id per different parent node, the node will be moved instead, as referenced nodes are meant to be unique, but once you expect a reference in one place, it cannot possibly be in another.
if you are not using `html.for(ref, id)` then there is no caching issue ever, unless you create content, and then move any created node around without using `render(where, what)` which is mandatory to render uhtml content, so we're back to the initial quest: is there any reduced example of your issue?
from the library perspective, non keyed renders never clashes with anything (unless you move their nodes after rendering these ... don't, and clone nodes instead) but keyed elements are unique by design, so be sure the reference key, or its id, is unique enough per container.
hope this helps a bit
|
|
|
|
Post by webreflection on Jan 2, 2021 18:16:00 GMT
P.S. we've been using (where I work) the core of this library for 2+ years, handling hundred thousand stream of data without any issue ever, meaning I'm confident there's something else your logic/app does that moves nodes around instead of cloning ... as example, dragging one item from list A to list B should clone the initial node and update both lists rendering once the move happens, after updating the list of nodes per each list.
that would render/update list A with the moved node out of its nested array, and list B with the moved node added to its nested array ... if the drag-n-drop utility moves the list A node instead, without updating the array related to such list, and without updating the array related to the other list, mess happens.
this gives me a good reason to actually showcase how to drag and drop items from one list to another within two distinct render that digest two distinct list of items, so it's a good showcase for people struggling, or wondering, how to solve that, but I'm not fully sure it'll solve *your* specific issue.
|
|
|
|
Post by danielbeeke on Jan 3, 2021 19:29:41 GMT
|
|
|
|
Post by danielbeeke on Jan 3, 2021 19:30:39 GMT
Also this is great, it means the library is probably more simple in use than I thought.
I have added .for() a lot of times.
|
|
