|
| 1 | +# Neo.mjs v10.5.0 Release Notes |
| 2 | + |
| 3 | +## Major Performance Enhancements for Grids and Data Handling |
| 4 | + |
| 5 | +This release introduces a groundbreaking set of performance optimizations for `Neo.data.Store` and `Neo.grid.Container`, fundamentally transforming how large datasets are handled within Neo.mjs applications. These enhancements dramatically reduce initial load times, improve UI responsiveness, and resolve critical VDom reconciliation issues, making it feasible to work with millions of data points with unprecedented fluidity. |
| 6 | + |
| 7 | +### Key Highlights: |
| 8 | + |
| 9 | +* **Lazy Record Instantiation (GET-driven approach):** |
| 10 | + * `Neo.data.Store` now defers the creation of `Neo.data.Record` instances. Raw data objects are stored directly, and `Record` instances are only created on-demand when an item is explicitly accessed (e.g., via `store.get()`, `store.getAt()`, or during VDom rendering of visible rows). |
| 11 | + * **Impact:** This eliminates the massive upfront cost of instantiating millions of `Record` objects, leading to **up to 97% reduction in initial data processing time** for large datasets. |
| 12 | + |
| 13 | +* **Configurable Data Chunking for UI Responsiveness:** |
| 14 | + * Introduced an `initialChunkSize` config in `Neo.data.Store` (default `0`). When enabled, `Store.add()` processes data in chunks, significantly mitigating UI freezes during synchronous loading of extremely large datasets (e.g., 1,000,000+ rows). |
| 15 | + * **Impact:** Provides a smoother perceived user experience during initial data loads, even for datasets that would otherwise cause multi-second UI blocks. |
| 16 | + |
| 17 | +* **Robust Component ID Management for VDom Stability:** |
| 18 | + * Resolved critical VDom reconciliation errors (e.g., `RangeError`, infinite loops) that could occur with component columns when chunking was active. `Neo.grid.column.Component` now intelligently generates unique IDs based on the store's chunking state, ensuring VDom stability. |
| 19 | + * **Impact:** Eliminates a major source of instability and crashes when using component columns with large, dynamically loaded datasets. |
| 20 | + |
| 21 | +* **Automated Component Instance Cleanup:** |
| 22 | + * Enhanced `Neo.grid.Body` with sophisticated component instance management. Components are now automatically destroyed when the grid body is destroyed, the store is cleared, the store changes, or when they scroll out of view after a chunked load. |
| 23 | + * **Impact:** Reduces memory overhead and improves long-term performance by preventing the accumulation of unused component instances. |
| 24 | + |
| 25 | +* **GPU-Accelerated Vertical Scrolling (`translate3d`):** |
| 26 | + * Grid rows now utilize `transform: translate3d(0px, Ypx, 0px)` for vertical positioning. This hints to the browser to promote rows to their own composite layers, offloading rendering to the GPU. |
| 27 | + * **Impact:** Leads to noticeably smoother and more fluid vertical scrolling, especially during rapid movements through large grids. |
| 28 | + |
| 29 | +### Other Enhancements: |
| 30 | + |
| 31 | +* **ComboBox Initial Display Fix:** Resolved an issue where `Neo.form.field.ComboBox` instances would appear blank on initial load when backed by lazily instantiated stores. The `updateInputValueFromValue` method now correctly displays values from raw data or `Record` instances. |
| 32 | +* **Enhanced BigData Grid Example:** The `examples/grid/bigData` demo has been updated to include control options for up to 200 columns, allowing for testing with up to 20,000,000 cells. This provides a more extreme and comprehensive benchmark for grid performance. |
| 33 | + |
| 34 | +These collective improvements mark a significant leap forward in Neo.mjs's capability to handle and display massive amounts of data with high performance and a superior user experience. |
| 35 | + |
| 36 | +--- |
| 37 | + |
| 38 | +### Performance Benchmarks (from `examples/grid/bigData`): |
| 39 | + |
| 40 | +| Scenario | Before (Eager Instantiation) | After (Lazy Instantiation, with chunking) | After (Lazy Instantiation, no chunking) | |
| 41 | +| :------------------------------------- | :--------------------------- | :---------------------------------------- | :-------------------------------------- | |
| 42 | +| 1,000 rows, 50 columns | 49ms (Record creation) | 2ms (Data gen + add) | 2ms (Data gen + add) | |
| 43 | +| 50,000 rows, 50 columns | 2391ms (Record creation) | 1252ms (Data gen + add) | 93ms (Data gen + add) | |
| 44 | +| 50,000 rows, 100 columns | 4377ms (Record creation) | 1289ms (Data gen + add) | 95ms (Data gen + add) | |
| 45 | +| 100,000 rows, 50 columns | N/A (too slow) | 1299ms (Data gen + add) | 156ms (Data gen + add) | |
| 46 | +| 100,000 rows, 200 columns | N/A (too slow) | 1427ms (Data gen + add) | 174ms (Data gen + add) | |
| 47 | + |
| 48 | +*Note: "Record creation" refers to the time taken for `Neo.data.Record` instantiation. "Data gen + add" refers to the time taken to generate raw data and add it to the store's collection.* |
| 49 | + |
| 50 | +**Important Note on Chunking:** |
| 51 | +The introduction of lazy record instantiation significantly reduces the need for chunking in most common use cases, as the initial data loading is now extremely fast even for large datasets. However, Neo.mjs still optionally supports data chunking via the `initialChunkSize` config for scenarios involving truly massive synchronous data additions where mitigating UI freezes is paramount. |
0 commit comments