Architectural Ideation: Elevate Grid Selection Model to GridContainer

The Concept

Migrate the selectionModel upwards from the Neo.grid.Body components to the Neo.grid.Container. Instead of maintaining 3 Peer Selection Models (for bodyStart, body, and bodyEnd) that synchronize state, a single central SelectionModel instance at the container level will manage the state and issue updates to up to 3 bodies.

The Rationale

• Simplicity: Eliminates the fragile "Peer State Adoption" logic (e.g., sharing the selectedRows arrays across 3 distinct class instances).
• Parallel Updates: A single SM mutation can batch VDOM updates across all 3 bodies simultaneously, preventing split-second UI disconnects between frozen and center columns.
• Event Delegation: Currently, DOM events like rowClick delegate up to GridContainer. Having the SM on the Container naturally matches the event delegation phase, avoiding the current if (event.body && event.body !== view) return check in RowModel.onRowClick.

Challenges & Open Questions (The Counter-Argument)

While moving the SM to the container solves state propagation, it creates a severe violation of component abstraction regarding VDOM mutation.

1. The O(1) VDOM Mutation Problem (updateRows()): Currently, Neo.selection.grid.BaseModel.updateRows() achieves O(1) performance by directly asking its view (the GridBody) for the specific row component: row = view.getRow(record);. It then mutates the VDOM class directly. If the view becomes the GridContainer, the container does not hold row instances. The SM would be forced to hardcode multi-body layout awareness:

      [view.bodyStart, view.body, view.bodyEnd].filter(Boolean).forEach(body => {
       let row = body.getRow(record);
       if (row) { /* mutate VDOM */ }
   });

   This tightly couples the abstract Selection Model to the physical layout of a Multi-Body Grid implementation.

2. Standalone Grid Bodies: If Neo.grid.Body is intended to be used autonomously without a GridContainer, moving the SM config to the container completely disables selection capabilities for lightweight, standalone lists.

3. CellModel Logical IDs: The CellModel uses logical IDs. If the view is the GridContainer, resolving a cell's coordinates requires querying downwards through all distinct bodies to find which actual DOM node matches the dataField, introducing runtime overhead during high-frequency cell mutations.