Server-side data with Supabase

This tutorial shows how to wire Handsontable’s dataProvider plugin to a live Supabase Postgres table. Every page load, sort, filter, and cell edit goes through the database, so the browser never holds the full dataset.

Overview

Difficulty: Intermediate
Time: ~30 minutes
Stack: React, Vite, Handsontable dataProvider, @handsontable/react-wrapper, @supabase/supabase-js v2

The dataProvider plugin turns Handsontable into a server-backed grid. You supply four async functions — one to fetch a page of rows, and three to create, update, and delete them — and the plugin drives pagination, sorting, and filtering against the server. This recipe connects those functions to a Supabase Postgres table through PostgREST, the REST API that every Supabase project exposes automatically.

What You’ll Build

An inventory grid backed by a live Supabase table:

Page-by-page loading with server-side pagination.
Server-side sorting through PostgREST’s .order() method.
Server-side filtering, with each Handsontable filter condition mapped to its PostgREST equivalent.
Full CRUD: cell edits, new rows, and deletions are written to the database and confirmed by the server.
Error toasts through the Notification plugin.

Before you begin

Requirement	Version
`handsontable`	17.1 or later
`@handsontable/react-wrapper`	17.1 or later
`@supabase/supabase-js`	2
React + Vite	any current version
Supabase project	the free plan is enough

This recipe adds to an existing Vite + React + TypeScript app. If you do not have one, scaffold it first, then add the Handsontable and Supabase packages:

1
npm create vite@latest my-inventory-app -- --template react-ts
2
cd my-inventory-app
3
npm install handsontable @handsontable/react-wrapper @supabase/supabase-js

The grid uses an inventory dataset with seven columns: id, SKU, name, quantity, unit price, warehouse, and an updated-at timestamp. With enough rows the grid pages through the data, so server-side pagination is meaningful from the first load.

Create the database table

Run this SQL in the Supabase SQL Editor to create the inventory table, enable Row Level Security, and seed a few rows:

1
create table inventory (
2
  id          uuid          primary key default gen_random_uuid(),
3
  sku         text          not null,
4
  name        text          not null,
5
  quantity    integer       not null default 0,
6
  unit_price  numeric(10,2) not null default 0,
7
  warehouse   text          not null,
8
  updated_at  timestamptz   not null default now()
9
);
10

11
-- Keep updated_at current on every update; the client never sends this field.
12
create or replace function set_updated_at()
13
returns trigger language plpgsql as $$
14
begin
15
  new.updated_at = now();
16
  return new;
17
end;
18
$$;
19

20
create trigger inventory_set_updated_at
21
  before update on inventory
22
  for each row execute function set_updated_at();
23

24
-- Enable Row Level Security. The table is private until you add a policy.
25
alter table inventory enable row level security;
26

27
-- Grant the Data API roles access to the table. This is required as of
28
-- April 2026, when Supabase stopped exposing new tables automatically.
29
grant select, insert, update, delete on table inventory to anon, authenticated;
30

31
-- A permissive starter policy. Replace it with the per-user rules in Step 7.
32
create policy "anon full access"
33
  on inventory for all
34
  to anon
35
  using (true)
36
  with check (true);
37

38
insert into inventory (sku, name, quantity, unit_price, warehouse) values
39
  ('SKU-001', 'Widget A',        120,   5.99, 'East'),
40
  ('SKU-002', 'Widget B',         45,   7.49, 'West'),
41
  ('SKU-003', 'Gadget Pro',      200,  24.99, 'East'),
42
  ('SKU-004', 'Gadget Lite',      30,  14.99, 'Central'),
43
  ('SKU-005', 'Connector Cable',  88,   9.99, 'West'),
44
  ('SKU-006', 'Power Adapter',   150,  19.99, 'East'),
45
  ('SKU-007', 'USB Hub 4-port',   60,  29.99, 'Central'),
46
  ('SKU-008', 'Monitor 27"',      12, 349.99, 'West');

What’s happening:

The set_updated_at trigger fires on every UPDATE and writes the current time to updated_at, so the client never needs to send that field. Enabling Row Level Security blocks all access by default; the anon role reaches the table through the Data API only because of the explicit grant. Row-level rules come from the policies you add on top, starting with the permissive anon full access policy here.

Configure environment variables

Add your Supabase project URL and anon key to .env.local:
```
1
VITE_SUPABASE_URL=https://<your-project-ref>.supabase.co
2
VITE_SUPABASE_ANON_KEY=<your-anon-key>
```
Find these values in the Supabase dashboard under Project Settings -> API.

What’s happening:

Vite exposes any variable prefixed with VITE_ to the browser bundle. The anon key is meant to be public: it identifies your project but grants no permissions on its own. Access is controlled by the RLS policies in the database, not by keeping the key secret.
Create the Supabase client

Create src/supabase.ts, a single client instance shared across the app:
TypeScript
```
1
import { createClient } from '@supabase/supabase-js';
2

3
// Created once at module load and shared across the app. PostgREST manages
4
// connection pooling on the server, so there is nothing to configure here.
5
export const supabase = createClient(
6
  import.meta.env.VITE_SUPABASE_URL,
7
  import.meta.env.VITE_SUPABASE_ANON_KEY,
8
);
```
What’s happening:

createClient runs once at module load and is exported as a singleton. PostgREST manages connection pooling on the server, so there is nothing to configure on the client. Every function that queries Supabase imports this one instance.

Map filter conditions to PostgREST

When the Filters plugin runs with dataProvider, Handsontable passes the current filter state as filters on every fetch. Each entry describes one column: a prop (the column data key), an array of conditions (each with a name and args), and an operation.

Map each condition name to its PostgREST equivalent:

Handsontable condition	`args`	Supabase call
`eq`	`[value]`	`.eq(col, value)`
`neq`	`[value]`	`.neq(col, value)`
`contains`	`[value]`	`.ilike(col, '%value%')`
`not_contains`	`[value]`	`.not(col, 'ilike', '%value%')`
`begins_with`	`[value]`	`.ilike(col, 'value%')`
`ends_with`	`[value]`	`.ilike(col, '%value')`
`gt`	`[value]`	`.gt(col, value)`
`gte`	`[value]`	`.gte(col, value)`
`lt`	`[value]`	`.lt(col, value)`
`lte`	`[value]`	`.lte(col, value)`
`between`	`[from, to]`	`.gte(col, low).lte(col, high)`
`not_between`	`[from, to]`	`.or('col.lt.low,col.gt.high')`
`empty`	`[]`	`.or('col.is.null,col.eq.')`
`not_empty`	`[]`	`.not(col, 'is', null).neq(col, '')`

Put the mapping in src/filterAdapter.ts:

1
import type { SupabaseClient } from '@supabase/supabase-js';
2
import type { DataProviderQueryParameters } from 'handsontable/plugins/dataProvider';
3

4
// The query builder returned by supabase.from('inventory').select(...).
5
type QueryBuilder = ReturnType<ReturnType<SupabaseClient['from']>['select']>;
6

7
// One column's filter state, taken directly from the dataProvider query parameters.
8
type FilterColumn = NonNullable<DataProviderQueryParameters['filters']>[number];
9
type FilterCondition = FilterColumn['conditions'][number];
10

11
// `between` / `not_between` inputs can arrive in either order; Handsontable sorts
12
// them before comparing. Both are offered only on numeric columns (here: quantity,
13
// unit_price), so normalize to a numeric [low, high] range.
14
function numericRange(args: unknown[]): [number, number] {
15
  const a = Number(args[0]);
16
  const b = Number(args[1]);
17

18
  return [Math.min(a, b), Math.max(a, b)];
19
}
20

21
// Conjunction: chain each condition onto the builder. PostgREST ANDs chained calls.
22
function applyCondition(query: QueryBuilder, column: string, condition: FilterCondition): QueryBuilder {
23
  const { name, args } = condition;
24
  const value = args[0];
25

26
  switch (name) {
27
    case 'eq':
28
      return query.eq(column, value as string);
29
    case 'neq':
30
      return query.neq(column, value as string);
31
    case 'contains':
32
      return query.ilike(column, `%${value}%`);
33
    case 'not_contains':
34
      return query.not(column, 'ilike', `%${value}%`);
35
    case 'begins_with':
36
      return query.ilike(column, `${value}%`);
37
    case 'ends_with':
38
      return query.ilike(column, `%${value}`);
39
    case 'gt':
40
      return query.gt(column, value as number);
41
    case 'gte':
42
      return query.gte(column, value as number);
43
    case 'lt':
44
      return query.lt(column, value as number);
45
    case 'lte':
46
      return query.lte(column, value as number);
47
    case 'between': {
48
      const [low, high] = numericRange(args);
49

50
      return query.gte(column, low).lte(column, high);
51
    }
52
    case 'not_between': {
53
      const [low, high] = numericRange(args);
54

55
      return query.or(`${column}.lt.${low},${column}.gt.${high}`);
56
    }
57
    case 'empty':
58
      return query.or(`${column}.is.null,${column}.eq.`);
59
    case 'not_empty':
60
      return (query.not(column, 'is', null) as QueryBuilder).neq(column, '');
61
    default:
62
      console.warn(`[dataProvider] Unsupported filter condition: "${name}" - skipping`);
63
      return query;
64
  }
65
}
66

67
// Disjunction: each condition becomes a PostgREST `.or()` term. Inside `.or()`,
68
// wildcards use `*` (not `%`) and negation uses the `not.` prefix. Values that
69
// contain commas or parentheses would need quoting; the inventory data has none.
70
function conditionToOrTerm(column: string, condition: FilterCondition): string | null {
71
  const { name, args } = condition;
72
  const value = args[0];
73

74
  switch (name) {
75
    case 'eq':
76
      return `${column}.eq.${value}`;
77
    case 'neq':
78
      return `${column}.neq.${value}`;
79
    case 'contains':
80
      return `${column}.ilike.*${value}*`;
81
    case 'not_contains':
82
      return `${column}.not.ilike.*${value}*`;
83
    case 'begins_with':
84
      return `${column}.ilike.${value}*`;
85
    case 'ends_with':
86
      return `${column}.ilike.*${value}`;
87
    case 'gt':
88
      return `${column}.gt.${value}`;
89
    case 'gte':
90
      return `${column}.gte.${value}`;
91
    case 'lt':
92
      return `${column}.lt.${value}`;
93
    case 'lte':
94
      return `${column}.lte.${value}`;
95
    case 'between': {
96
      const [low, high] = numericRange(args);
97

98
      return `and(${column}.gte.${low},${column}.lte.${high})`;
99
    }
100
    case 'not_between': {
101
      const [low, high] = numericRange(args);
102

103
      return `${column}.lt.${low},${column}.gt.${high}`;
104
    }
105
    case 'empty':
106
      return `${column}.is.null,${column}.eq.`;
107
    case 'not_empty':
108
      return `and(${column}.not.is.null,${column}.neq.)`;
109
    default:
110
      console.warn(`[dataProvider] Unsupported filter condition: "${name}" - skipping`);
111
      return null;
112
  }
113
}
114

115
export function applyFilters(
116
  query: QueryBuilder,
117
  filters: DataProviderQueryParameters['filters'],
118
): QueryBuilder {
119
  if (!filters || filters.length === 0) {
120
    return query;
121
  }
122

123
  for (const column of filters) {
124
    if (column.operation === 'disjunction') {
125
      // OR within the column: combine the conditions into a single .or() call.
126
      const terms = column.conditions
127
        .map(condition => conditionToOrTerm(column.prop, condition))
128
        .filter((term): term is string => term !== null);
129

130
      if (terms.length > 0) {
131
        query = query.or(terms.join(','));
132
      }
133
    } else {
134
      // Conjunction (the default): chain the conditions so PostgREST ANDs them.
135
      for (const condition of column.conditions) {
136
        query = applyCondition(query, column.prop, condition);
137
      }
138
    }
139
  }
140

141
  return query;
142
}

What’s happening:

applyFilters reads each column’s operation. For the default conjunction, it chains the conditions with applyCondition — PostgREST ANDs chained calls, so the conditions are ANDed. For disjunction (the “Or” toggle in the column’s filter menu), it maps the conditions to PostgREST .or() terms and applies them in a single .or() call, so they are ORed. Inside .or() terms, wildcards use * instead of % and negation uses the not. prefix; values containing commas or parentheses would need quoting. An unrecognized condition is logged and skipped rather than throwing, so an unmapped filter never breaks a fetch.

Build the grid component

Create src/InventoryGrid.tsx. It imports the client and the filter adapter as siblings (./supabase, ./filterAdapter), supplies the four dataProvider functions, and configures the columns. The types come from handsontable/plugins/dataProvider, so the query parameters and mutation payloads are checked at compile time:

1
import { HotTable } from '@handsontable/react-wrapper';
2
import { registerAllModules } from 'handsontable/registry';
3
import type {
4
  DataProviderQueryParameters,
5
  DataProviderFetchOptions,
6
  DataProviderFetchResult,
7
  RowsCreatePayload,
8
  RowUpdatePayload,
9
} from 'handsontable/plugins/dataProvider';
10
import 'handsontable/styles/handsontable.min.css';
11
import 'handsontable/styles/ht-theme-main.min.css';
12

13
import { supabase } from './supabase';
14
import { applyFilters } from './filterAdapter';
15

16
registerAllModules();
17

18
async function fetchRows(
19
  { page, pageSize, sort, filters }: DataProviderQueryParameters,
20
  { signal }: DataProviderFetchOptions,
21
): Promise<DataProviderFetchResult> {
22
  const from = (page - 1) * pageSize;
23
  const to = from + pageSize - 1;
24

25
  let query = supabase
26
    .from('inventory')
27
    .select('*', { count: 'exact' })
28
    .range(from, to)
29
    .abortSignal(signal);
30

31
  if (sort) {
32
    query = query.order(sort.prop, { ascending: sort.order === 'asc' });
33
  }
34

35
  query = applyFilters(query, filters);
36

37
  const { data, count, error } = await query;
38

39
  if (signal.aborted) {
40
    return { rows: [], totalRows: 0 };
41
  }
42

43
  if (error) {
44
    throw error;
45
  }
46

47
  return { rows: data ?? [], totalRows: count ?? 0 };
48
}
49

50
async function onRowsCreate({ rowsAmount }: RowsCreatePayload): Promise<unknown[]> {
51
  const newRows = Array.from({ length: rowsAmount }, () => ({
52
    sku: 'NEW-000',
53
    name: 'New item',
54
    quantity: 0,
55
    warehouse: 'East',
56
  }));
57

58
  const { data, error } = await supabase.from('inventory').insert(newRows).select();
59

60
  if (error) {
61
    throw error;
62
  }
63

64
  return data;
65
}
66

67
async function onRowsUpdate(rows: RowUpdatePayload[]): Promise<unknown[]> {
68
  const results = await Promise.all(
69
    rows.map(({ id, changes }) =>
70
      supabase.from('inventory').update(changes).eq('id', id).select().single(),
71
    ),
72
  );
73

74
  const failed = results.find((result) => result.error);
75

76
  if (failed) {
77
    throw failed.error;
78
  }
79

80
  return results.map((result) => result.data);
81
}
82

83
async function onRowsRemove(rowIds: string[]): Promise<void> {
84
  const { error } = await supabase.from('inventory').delete().in('id', rowIds);
85

86
  if (error) {
87
    throw error;
88
  }
89
}
90

91
const ExampleComponent = () => {
92
  return (
93
    <HotTable
94
      themeName="ht-theme-main"
95
      dataProvider={{
96
        rowId: 'id',
97
        fetchRows,
98
        onRowsCreate,
99
        onRowsUpdate,
100
        onRowsRemove,
101
      }}
102
      colHeaders={['ID', 'SKU', 'Name', 'Quantity', 'Unit price', 'Warehouse', 'Updated at']}
103
      columns={[
104
        { data: 'id', type: 'text', readOnly: true, width: 260 },
105
        { data: 'sku', type: 'text', width: 100 },
106
        { data: 'name', type: 'text', width: 180 },
107
        { data: 'quantity', type: 'numeric', width: 90 },
108
        { data: 'unit_price', type: 'numeric', numericFormat: { pattern: '$0,0.00' }, width: 110 },
109
        { data: 'warehouse', type: 'text', width: 110 },
110
        { data: 'updated_at', type: 'text', readOnly: true, width: 200 },
111
      ]}
112
      hiddenColumns={{ columns: [0] }}
113
      fixedColumnsStart={2}
114
      pagination={{ pageSize: 10 }}
115
      columnSorting={true}
116
      filters={true}
117
      dropdownMenu={['filter_by_condition', 'filter_action_bar']}
118
      notification={true}
119
      emptyDataState={true}
120
      contextMenu={true}
121
      rowHeaders={true}
122
      height={500}
123
      stretchH="all"
124
      licenseKey="non-commercial-and-evaluation"
125
    />
126
  );
127
};
128

129
export default ExampleComponent;

What’s happening:

fetchRows converts the page number to a PostgREST range and passes count: 'exact', so a single HTTP call returns both the page of rows and the total count. The AbortSignal from Handsontable is passed straight to Supabase: when the user pages or sorts before a response arrives, the in-flight request is canceled and the stale result is discarded.
onRowsCreate chains .select() after .insert() so PostgREST returns the inserted rows, including the server-assigned id and updated_at. Returning those values is required: Handsontable uses the id to track new rows for later updates and deletes.
onRowsUpdate receives all changes from one user action as a single array and dispatches them in parallel with Promise.all. This is safe because Handsontable serializes mutation calls, so there is never more than one onRowsUpdate in flight at once.
hiddenColumns and fixedColumnsStart work together. The id column is hidden (physical index 0), so fixedColumnsStart={2} freezes the two visible columns sku and name rather than id and sku.
dropdownMenu omits filter_by_value (the checkbox list of distinct values). In server mode the list could only be built from the loaded page, so dataProvider drops the menu item and ignores any by_value condition added in code. See Filtering by a Set of Values for the server-side alternative.

Render the grid from your app’s entry point — for example, in src/App.tsx, import the component (import InventoryGrid from './InventoryGrid') and return <InventoryGrid />.

Add error handling

notification: true wires up Handsontable’s built-in toast layer, so errors surface in the UI with no extra setup. The two error hooks let you add behavior on top, such as logging to an error tracker:
```
1
afterDataProviderFetchError={(error, queryParameters) => {
2
  // error           - the rejection reason from fetchRows
3
  // queryParameters - page, pageSize, sort, filters at the time of failure
4
  reportToErrorTracker(error, { context: queryParameters });
5
}}
6

7
afterRowsMutationError={(error) => {
8
  // Handsontable has already rolled back the optimistic UI update here.
9
  reportToErrorTracker(error);
10
}}
```
What’s happening:

The Notification plugin listens for afterDataProviderFetchError and afterRowsMutationError internally and fires the toast whether or not you attach a hook. The plugin reads a human-readable message from the message, error, or detail property of the rejection. Supabase’s PostgrestError has a message property, so the toast text is meaningful by default.

Lock down access with Row Level Security

The VITE_SUPABASE_ANON_KEY you embed in the frontend is public by design. The key identifies your project but grants no permissions on its own; access is controlled entirely by RLS policies. Replace the permissive starter policy from Step 1 with rules that match your app.

A per-user ownership pattern:

1
alter table inventory add column owner_id uuid references auth.users;
2

3
create policy "select own rows"
4
  on inventory for select
5
  using ((select auth.uid()) = owner_id);
6

7
create policy "insert own rows"
8
  on inventory for insert to authenticated
9
  with check ((select auth.uid()) = owner_id);
10

11
create policy "update own rows"
12
  on inventory for update
13
  using  ((select auth.uid()) = owner_id)
14
  with check ((select auth.uid()) = owner_id);
15

16
create policy "delete own rows"
17
  on inventory for delete
18
  using ((select auth.uid()) = owner_id);

A public-read, authenticated-write pattern:

1
create policy "public read"
2
  on inventory for select to anon, authenticated
3
  using (true);
4

5
create policy "authenticated write"
6
  on inventory for all to authenticated
7
  using (true) with check (true);

What’s happening:

RLS policies are the real access-control layer. An empty policy list blocks all rows, so enabling RLS without adding policies locks the table completely. Write (select auth.uid()) rather than auth.uid() in USING and WITH CHECK clauses: the scalar subquery form is evaluated once per query instead of once per row, which matters on large tables.

How It Works - Complete Flow

ExampleComponent mounts and Handsontable calls fetchRows with { page: 1, pageSize: 10 }.
fetchRows requests range(0, 9) with count: 'exact'. PostgREST returns the first ten rows and the total count in one HTTP call. Handsontable renders the page and sets up the pagination control.
The user clicks a column header. Handsontable calls fetchRows again with a sort parameter, and the in-flight request from step 2 is canceled through the AbortSignal.
The user opens the filter dropdown and sets a condition. Handsontable calls fetchRows with a filters array. The adapter maps each condition name to a PostgREST method and chains it onto the query.
The user edits a cell and moves away. Handsontable calls onRowsUpdate with [{ id, changes }]. The update is sent to Supabase, the set_updated_at trigger fires, and the returned row, with its refreshed timestamp, is written back into the grid.
The user right-clicks and inserts a row. Handsontable calls onRowsCreate with { rowsAmount: 1 }. The new row is inserted, and the server-assigned id and updated_at come back in the response. Handsontable stores the id so it can update or delete that row later.
The user selects rows and deletes them. Handsontable calls onRowsRemove with the array of id values, which are passed to a single DELETE ... IN (...) statement.

Performance and Production Considerations

The steps above cover the happy path. For production workloads, add the following:

Index the columns you sort and filter on. PostgREST runs every sort and filter as SQL, so an unindexed table does a full scan on each request. Add B-tree indexes on the exposed columns, for example create index on inventory (sku); and create index on inventory (warehouse);. A composite index helps when users combine conditions on the same columns.
Batch large edits. onRowsUpdate sends one request per changed row. A single cell edit is one request, but pasting a block produces many. For bulk writes, send the changes to a Postgres function through supabase.rpc(), or use one .upsert() call, so the round trip is a single request instead of N.
Index the RLS ownership column. The per-user policy in Step 7 filters every query by owner_id. Add create index on inventory (owner_id); and keep the (select auth.uid()) form so the check runs once per query, not once per row. Set owner_id on insert with a column default of auth.uid() or a before insert trigger, so the client never sends it.
Tune the count on large tables. count: 'exact' runs a full COUNT(*) on every fetch, which grows costly past a few hundred thousand rows. Switch the pagination total to count: 'estimated' (or 'planned') on large tables, and keep pageSize modest so each page stays a small range scan.

Filtering by a Set of Values

The built-in Filter by value checkbox list is unavailable in server mode: the list could only be built from the loaded page, so dataProvider omits the menu item and ignores by_value conditions. The condition-based filters from Step 4 cover most cases, but you can rebuild value-style filtering with your own control.

Populate a multi-select with the column’s distinct values from the server, for example select distinct warehouse from inventory order by warehouse. Put this behind a cached view or an RPC so it stays cheap on large tables.
Hold the selection in your own state and apply it as an .in() filter inside fetchRows:

1
// Set by your multi-select control.
2
let selectedWarehouses: string[] = [];
3

4
// Inside fetchRows, after building the base query:
5
if (selectedWarehouses.length > 0) {
6
  query = query.in('warehouse', selectedWarehouses);
7
}

When the selection changes, refetch from the first page with the plugin’s fetchData({ page: 1 }) (reach it through the wrapper ref’s hotInstance). Because the filter lives in your own state, pagination and sorting preserve it, and the server returns only matching rows.

What you learned

How dataProvider replaces manual afterChange wiring: pagination, sorting, filtering, and CRUD are handled by the plugin once the four async functions are in place.
Why onRowsCreate must return the inserted rows, since Handsontable needs the server-assigned primary key to track new rows for later updates and deletes.
How to pass an AbortSignal to Supabase so stale in-flight requests are canceled when the user changes page, sort, or filter before the response arrives.
How to map Handsontable’s filter conditions to PostgREST methods with a switch statement.
Why the built-in filter_by_value checkbox is unavailable server-side: the plugin omits the menu item and ignores by_value conditions, because the list could only reflect the loaded page. A custom multi-select backed by a select distinct query replaces it.
How Supabase RLS policies are the real access-control layer even though the anon key is public.

Next steps

Server-side data overview — the full dataProvider API, lifecycle hooks, and options incompatible with server-side mode.
Fetching data — query-parameter structure, beforeDataProviderFetch, and abort behavior.
CRUD operations — mutation lifecycle, optimistic updates, and programmatic CRUD.
Supabase Row Level Security — the complete guide to writing RLS policies.
Supabase PostgREST filters — the full list of .eq(), .or(), .textSearch(), and other filter methods.

Server-side data with Supabase

Overview

What You’ll Build

Before you begin

Create the database table

Configure environment variables

Create the Supabase client

Map filter conditions to PostgREST

Build the grid component

Add error handling

Lock down access with Row Level Security

How It Works - Complete Flow

Performance and Production Considerations

Filtering by a Set of Values

What you learned

Next steps