RFC: Component-Based Grid Rows (Neo.grid.Row) for Granular Updates

Input from Gemini 3 Pro:

✦ Critical Architecture Note: Dynamic Column Handling & Performance

It is vital to clarify that Neo.grid.Row cannot effectively manage its own structure in isolation. A row's structure (cell order, visibility, renderers) is strictly dependent on the Grid.Container's column configuration, which is mutable at runtime.

Responsibility: The Grid.Body (or Container) MUST remain the authority on defining the Row VDOM structure.

Implementation Constraint: We must avoid a design where every Neo.grid.Row instance independently listens to Grid events to rebuild itself. Instead, the Grid.Body should efficiently orchestrate structural updates.

Performance Optimization (Batching): When columns change (or during scrolling), updating 50+ row components individually could trigger significant traffic. Recommended pattern:

1. Grid.Body iterates over the Row pool.
2. Applies updates using silentVdomUpdate: true on each row to prevent immediate worker messages.
3. Triggers a single, consolidated update from the Grid.Body (or utilizes the VdomUpdate manager's batching capabilities explicitly) to flush all changes in one go. This ensures the Grid updates atomically, preventing "tearing" artifacts and minimizing IPC overhead.

Input from Gemini 3 Pro:

✦ I have analyzed the RFC and the codebase. This is a transformative refactor.

Here is the proposed breakdown of sub-tickets to tackle Epic #8964.

Phase 1: Foundation

1. Scaffold Neo.grid.Row Component

• Goal: Create the Neo.grid.Row class.
• Scope:
  • Create src/grid/Row.mjs extending Neo.component.Base.
  • Migrate the cell rendering logic (HTML/Text cells) from Body.createRow to Row.mjs.
  • Define configs: record, rowIndex, columns (passed from Body).
  • Deliverable: A Row component that can generate its own VDOM for standard cells.

2. Refactor Neo.grid.Body to use Row Pooling

• Goal: Replace monolithic VDOM generation with a pool of Row components.
• Scope:
  • Architectural Decision: Should Neo.grid.Body be upgraded to extend Neo.container.Base to natively handle items? Or should we manually manage the lifecycle of Row components within Component to avoid Layout overhead? (RFC implies "standard items", suggesting Container).
  • Implement createRowPool(size) to instantiate Neo.grid.Row instances.
  • Update createViewData and updateMountedAndVisibleRows to recycle these instances (row.set({record, rowIndex})) instead of creating raw VDOM.
  • Deliverable: The Grid renders using Neo.grid.Row instances.

Phase 2: Reactivity & Features

3. Implement Granular Updates (Data Binding)

• Goal: Enable O(1) updates for single record changes.
• Scope:
  • Refactor Body.onStoreRecordChange.
  • Remove manual VDOM manipulation (updateCellNode).
  • Logic: Find the matching Row instance $\rightarrow$ call row.set({record}) $\rightarrow$ Row updates its own VDOM.
  • Deliverable: Editing a record updates only that Row's VDOM.

4. Migrate Component Columns (The "Zombie Canvas" Fix)

• Goal: Move component cell management to the Row.
• Scope:
  • Refactor Neo.grid.column.Component.
  • Move cleanupComponentInstances logic from Body to Row.
  • Row automatically instantiates/destroys cell components (like Sparklines) based on its state.
  • Deliverable: Sparklines/Widgets work inside the new Row architecture.

Phase 3: Optimization

5. Performance: Batching & Silent Updates

• Goal: Ensure scrolling performance matches or exceeds the current implementation.
• Scope:
  • Implement silentVdomUpdate: true for Row updates during scroll.
  • Implement the batch flush in Grid.Body (as noted in the RFC).
  • Benchmarking.

resolved.