LearnNewsExamplesServices
Frontmatter
id6327
titlegrid.Row: Create a PoC
stateOpen
labels
enhancementno auto close
assigneestobiu
createdAtJan 28, 2025, 7:24 PM
updatedAtMay 14, 2025, 11:28 AM
githubUrlhttps://github.com/neomjs/neo/issues/6327
authortobiu
commentsCount3
parentIssuenull
subIssues[]
subIssuesCompleted0
subIssuesTotal0
blockedBy[]
blocking[]

grid.Row: Create a PoC

Openenhancementno auto close
tobiu
tobiu commented on Jan 28, 2025, 7:24 PM

I am just brainstorming about a new concept: should i create a component (class) for grid / table rows

In short: when we change a record, we send the vdom & vnode of the entire view (the mounted / painted part) to the vdom worker, which is quite the overhead.

We could just send the row fraction to the vdom worker, but then still the entire view would be locked for other updates so updating multiple records would get delayed a lot. component.Base / container.Base has all the logic we need => updating in parallel & parent locking depending on the depth.

However, there needs to be a smart row cycling logic. imagine a grid with 50k rows => we must not even think about creating 50k row component instances. so only instances for painted rows and re-using instances when cycling (scrolling).

I will create a new feature branch for this story. grid.View might need to extend container.Base in this case.

Inside the current version:

store.getAt(0).set({firstname: 'foo'});
store.getAt(1).set({firstname: 'bar'});

The first record change would send the view vdom to the vdom worker and lock the view for updates. The second change would wait until the first update cycle is finished. It would most likely still end up inside the same animation frame.

However, in case we update a LOT of records, the impact grows. And, after all, neo is meant for high performance use cases.

@rwaters Thoughts on this one?

tobiu added the enhancement label on Jan 28, 2025, 7:24 PM
tobiu assigned to @tobiu on Jan 28, 2025, 7:24 PM
tobiu
tobiu Jan 29, 2025, 10:08 AM

more thoughts on this one:

If i update 50 records in a row, the first record change would trigger a view update. probably all other 49 would end up combined inside the next update cycle. the more changes there are, the faster the current method might be. needs benchmarking though.

tobiu cross-referenced by #6658 on Apr 16, 2025, 2:09 PM
tobiu removed the stale label on May 14, 2025, 11:28 AM
tobiu added the no auto close label on May 14, 2025, 11:28 AM
tobiu reopened this issue on May 14, 2025, 11:28 AM