Work with server-side data

Choose this guide when your server owns filtering, sorting or paging. There are two separate requests: the interpreter turns words into criteria, and your data loader fetches matching rows. The assistant does not automatically give the model access to your database.

The example extends the quick start. interpret, currentView and loadOrders belong to your application.

Remote datasets

Use createRemoteAiViewExecutor when your server owns filtering and sorting. It reuses the shared query engine for row loading, independently of model interpretation:

import { createRemoteAiViewExecutor } from '@revolist/revogrid-pro';

const executor = createRemoteAiViewExecutor({
  read: () => currentView,
  async load(view, { signal }) {
    return loadOrders({ filterAst: view.filter, sort: view.sort, signal });
  },
  commit(view, result) {
    currentView = view;
    grid.source = result.rows;
    // Publish the matching criteria and server total to your application UI.
  },
});
grid.aiAssistant = { interpret, executor };

The host must reset paging and enforce tenant authorization, mandatory predicates and date semantics. Commit matching rows and criteria together after success. A loaded page is not the complete dataset: local reads/search/grouping/data/schema actions are omitted or restricted for remote ownership; supply service-owned actions for complete-dataset operations.

The optional query accepts the existing ProviderQueryOptions (source, resource, freshness/retry settings, onStatus). Reuse an application createDataQueryContext() scope with tenant and authorization identity when available. Set query: false if your loader already owns caching. Query retries can repeat row reads, never interpretation. The helper checks cancellation and manual view changes before commit. Server totals remain optional; page length is not a full result count.

Next: Customize chat, history and language.