Frontmatter
| id | 6327 |
| title | grid.Row: Create a PoC |
| state | Open |
| labels | enhancementno auto close |
| assignees | tobiu |
| createdAt | Jan 28, 2025, 7:24 PM |
| updatedAt | May 14, 2025, 11:28 AM |
| githubUrl | https://github.com/neomjs/neo/issues/6327 |
| author | tobiu |
| commentsCount | 3 |
| parentIssue | null |
| subIssues | [] |
| subIssuesCompleted | 0 |
| subIssuesTotal | 0 |
| blockedBy | [] |
| blocking | [] |
grid.Row: Create a PoC
Openenhancementno auto close
tobiu assigned to @tobiu on Jan 28, 2025, 7:24 PM

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 reopened this issue on May 14, 2025, 11:28 AM
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.Viewmight need to extendcontainer.Basein 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?