Work with large data sets
Large-data performance starts with a simple rule: do not load data the UI does not need.
FDC supports the same dataset API for local and adapter-backed data, but scalable screens should push filtering, sorting, search, paging, and aggregates to adapters that advertise those capabilities.
Use paging
final orders = FdcDataSet(
fields: fields,
adapter: adapter,
paging: const FdcDataPagingOptions(
enabled: true,
mode: FdcDataPagingMode.standard,
pageSize: 100,
),
);
Open only the first page:
await orders.open();
Use the dataset paging API or paging controls to move through the result set. See Paging.
Push query operations to the adapter
A capable adapter should execute:
- filters over the full source;
- sort order before paging;
- global search before paging;
- aggregates over the complete filtered result set.
Project only useful fields
Avoid selecting large blobs or unused columns for a grid screen. A narrow row shape reduces database work, transport payloads, JSON parsing, and widget update pressure.
For SQL query datasets, expose stable aliases that match dataset field names.
Use server-side aggregates
Do not calculate a total from the current page when the UI is meant to show a total for the complete filtered result.
Use adapter aggregate capabilities so the backend calculates against the same effective filter and search state. See Aggregates.
Choose the right paging mode
Use standard paging when users need explicit page boundaries and stable page navigation.
Use infinite paging when the preferred interaction is continuous scrolling and the adapter can efficiently fetch sequential pages.
Measure the complete path
When optimizing, separate:
- backend query time;
- transport and serialization time;
- adapter materialization time;
- dataset query coordination;
- grid rendering and scrolling.
Do not assume a slow screen is automatically a grid rendering problem. Large-data systems are pipelines, and the dominant cost can sit at any layer.