Data Updates
To handle live data updates and display real-time views, the server data source requests update ticks at a configurable interval.
Processing Updates
By default, the server data source doesn’t poll for row updates and requests new data
only when the view changes. To request data for the current view on demand, call the
data source refresh method. You can build a real-time grid in two steps:
- Set up the data grid view using the standard non-updating configuration with the
useServerDataSourcehook. - Call the
refreshmethod whenever the grid should update its rows.
The demo below uses setInterval to poll the server every second, then calls
refresh on each interval to fetch updated rows. It uses a grouped
view to show that update ticks work for both flat and grouped data.
Manually Refreshing the Grid
The refresh method is a convenience wrapper around two underlying server data source methods:
requestsForView: Returns data request objects for the current view.pushRequests: Sends data request objects to the server to force an update for the specified slices.
The following code blocks are equivalent:
const ds = useServerDataSource({ ... })
ds.refresh()// Is equivalent tods.pushRequests(ds.requestsForView.get())Data Updating Considerations
Live ticking data grids introduce several subtle and complex synchronization challenges. The LyteNyte Grid server data source handles these complexities automatically.
High-Frequency Updates
Some views can display hundreds or thousands of visible cells that can update simultaneously and at high frequency.
LyteNyte Grid renders these visual updates efficiently, but server-driven updates can bottleneck in your application’s data-processing layer:
- Serialization: Browser serialization and deserialization of server payloads can add overhead.
- Network limits: You’ll often hit network update limits before LyteNyte Grid hits cell-rendering limits.
To optimize performance, batch updates when the update rate is high. For example, call
refresh every 5 seconds to apply updates in 5-second intervals. The exact timing depends on
your specific use case. If you notice performance dips, they are likely in
your application’s data-processing layer.
Consistent Group Updates
When row groups are present, data requests occur per group row and its children. For example, if a single expanded row group is in view, the view consists of:
- The root data slice containing the group rows
- The child rows of the expanded group
These represent two separate data requests. LyteNyte Grid’s queryFn
provides both slices simultaneously, but if your implementation splits them into
multiple server requests, the returned data may become out of sync. This can occur if the server
data ticks between requests. To prevent this, handle refresh requests together to ensure data consistency.
Next Steps
- Unbalanced Rows (Tree Data): Handle asymmetric row groups of varying depths.
- Optimistic Loading: Pre-fetch data using optimistic loading to reduce perceived latency.
- Server Row Grouping: Use the server data source to load and manage group slices.
- Handling Load Failures: Recover from failed data requests and retry loads.
