State Management Guide
Mantine React Table does not try to hide any of its internal state from you. You can initialize state with custom initial values, manage individual states yourself as you discover the need to have access to them, or store your own reference to the entire table instance wherever you need to.
This is all optional, of course. If you do not need access to any of the state, you do not need to do anything and it will just automatically be managed internally.
See the State Options API Docs for more information on which states are available for you to manage.
Relevant Table Options
Populate Initial State
If all you care about is setting parts of the initial or default state when the table mounts, then you may be able to specify that state in the
initialStateprop and not have to worry about managing the state yourself.
For example, let's say you do not need access to the
showColumnFiltersstate, but you want to set the default value to
truewhen the table mounts. You can do that with the
Note: If you use both
state, the state initializer in
stateprop will take precedence and overwrite the same state values in
initialState. So just use either
state, not both for the same states.
Manage Individual States as Needed
It is pretty common to need to manage certain state yourself, so that you can react to changes in that state, or have easy access to it when sending it to an API.
You can pass in any state that you are managing yourself to the
stateprop, and it will be used instead of the internal state. Each state property option also has a corresponding
on[StateName]Changecallback that you can use set/update your managed state as it changes internally in the table.
For example, let's say you need to store the pagination, sorting, and row selection states in a place where you can easily access it in order to use it in parameters for an API call.
Add Side Effects in Set State Callbacks
In React 18 and beyond, it is becoming more discouraged to use
useEffectto react to state changes, because in React Strict Mode (and maybe future versions of React), the useEffect hook may run twice per render. Instead, more event driven functions are recommended to be used. Here is an example for how that looks here. The callback signature for the
on[StateName]Changeworks just like a React setState callback from the
useStatehook. This means that you have to check if the updater is a function or not, and then call the setState function with the updater callback if it is a function.
Read From the Table Instance
Note: Previously, in early MRT v1 betas, you could use the
tableInstanceRefprop to get access to the table instance. This is no longer necessary as the
useMantineReactTablehook now just returns the table instance directly.
useMantineReactTablehook returns the table instance. The
<MantineReactTable />needs the table instance for all of its internal logic, but you can also use it for your own purposes.
The table instance is the same object that you will also see as a provided parameter in many of the other callback functions throughout Mantine React Table, such as all the
render...props or the
Headerrender overrides in the column definition options.
Persistent state is not a built-in feature of Mantine React Table, but it is an easy feature to implement yourself using the above patterns with the
stateprop and the
on[StateName]Changecallbacks. Here is an example of how you might implement persistent state using
1-9 of 9