examples/grid/bigData: sometimes component based columns break

@gplanansky @camtnbikerrwc & others who are interested: How would you locate a bug as bizarre as this one?

It is obviously related to cycling component based columns. Switching to row based components: https://github.com/neomjs/neo/issues/6327 might already resolve it (since we would only cycle rows then), but still, it feels worth to explore what is happening.

We do have a DOM corruption. To narrow it down, the first thing I looked into is the related progress component itself, to figure out if we also have a corruption inside the vdom:

The vdom is looking fine. The progress wrapper (neo-vnode-199) is only containing one progress node (neo-base-12-component-48). The label contains removeDom: true, so it is not painted.

The next thing to look into is the vnode. The wrapper node has the same id (neo-vnode-199), but the child node got reduced to only contain a componentId. This already does give us a clue.

The next thing to look into is the initial working state before cycling:

vdom & vnode are in sync, no replacement.

As the next step, we need to investigate the logic which does replace components with componentId based references.

It has to be: component.Base: syncVnodeTree()

This one is using: manager.Component: addVnodeComponentReferences()

We obviously do not want to replace a component which is using a wrapper node inside its own wrapper.

I added a check to see if the direct parent node is a wrapper: isWrapper = childNodes.length > 0 && me.wrapperNodes.get(vnode.id) || false

and logged it into the console, in case a component to replace is found:

This looks like a good starting point.

Testing the new change:

While the vnode no longer gets replaced with a reference, this is not it.

We are still on symptoms level, and this is not the root cause.

We got another hint though: How is it possible, that a specific wrapper gets a child node with a different id?

Assuming that the vdom delta update logic works correctly, I need to take a deeper look into the grid column component based cycling.

@gplanansky @camtnbikerrwc In the end, adding this into grid.column.Component fixed it:

// We need to ensure that wrapped components always get the same index-based id.
if (!component.vdom.id) {
    component.vdom.id = id + '__wrapper'
}

The wrapper check inside manager.Component is no longer needed.

While the fix itself was easy (just ensuring that wrapped components always have the same index based id), finding it was non-trivial.

That fixed my grid issue I suspect GerSent from my iPhoneOn Apr 16, 2025, at 6:39 AM, Tobias Uhlig @.***> wrote: @gplanansky @camtnbikerrwc In the end, adding this into grid.column.Component fixed it: // We need to ensure that wrapped components always get the same index-based id. if (!component.vdom.id) { component.vdom.id = id + '__wrapper' }

The wrapper check inside manager.Component is no longer needed. While the fix itself was easy (just ensuring that wrapped components always have the same index based id), finding it was non-trivial.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

tobiu left a comment (neomjs/neo#6658) @gplanansky @camtnbikerrwc In the end, adding this into grid.column.Component fixed it: // We need to ensure that wrapped components always get the same index-based id. if (!component.vdom.id) { component.vdom.id = id + '__wrapper' }

The wrapper check inside manager.Component is no longer needed. While the fix itself was easy (just ensuring that wrapped components always have the same index based id), finding it was non-trivial.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>