MRT Best Practices
Here are some best practices to follow when using Mantine React Table. We'll cover Type-Safety (even if you are not using TypeScript) and how to best create re-usable MRT components.
Run this command in your terminal every few weeks to make sure you are using the latest version of Mantine React Table and other Mantine packages:
TanStack Table itself is written in TypeScript, and Mantine React Table builds on top of its great type definitions for a best-in-class TypeScript experience.
If, however, you cannot use TypeScript in your project for some reason, checkout down below for how to use JSDoc instead of TypeScript to get the same type hints.
Is TypeScript Required?
There are a couple of ways to still get type hints without TypeScript with the
createMRTColumnHelper utility function or by using JSDoc, so you can still get some of the benefits of type safety without TypeScript.
Defining TData Type
Mantine React Table makes use of generics to make working with your specific row data structures easier. You will see that most of the
MRT_* types that you can use accept a
Let's say that the data in your table is an array of users that looks like this:
TData type can be defined as:
You will often pass this
TData type as a generic to the
MRT_* types that you use so that you can get type hints for your specific data structure.
Define Your Columns With Type-Safety
Mantine React Table provides a couple of ways to define your columns with type safety. You can either simply use the
MRT_ColumnDef type or use the new
createMRTColumnHelper utility function.
The most straightforward way to define your columns with type-safety is to just type your columns as
New in V2 (After many requests)
Alternatively you can use the
createMRTColumnHelper utility function to define your columns. This works the same way as the TanStack
TValue type-safety is provided by using this utility. That means that when you call
cell.getValue() in either a custom
Cell render, or in any of the
mantine*Props, you will get the correct type for the data in that column instead of
Use JSDoc instead of TypeScript
Re-Usable MRT Components
If you are going to have multiple tables in your app, chances are that you will want to make a re-usable component built on top of Mantine React Table. This is a good idea and good practice, but here are a few suggestions to maintain type safety with some TypeScript generics.
Re-usable Components or Options?
In my opinion, instead of creating a re-usable component, it is instead actually best to define your default options and share them between all of your tables.
Re-usable Default Options
In this example, we are simply creating a factory function that creates all of the default options that you want all of your tables to start with.
Then you can use these options in every new table that you create:
Doing it this way, you maintain 100% control of your table instance and any state that you are managing in each table component.
I believe this is by far the best way to work with Mantine React Table in your application code, and how I personally use it in my own apps.
Re-usable MRT Component
If you still want to just create a re-usable MRT component instead, you can do that too, of course. Here is a type-safe way to do that:
By using the
TData generic correctly, you can maintain type-safety in your re-usable component that will adapt to different types of data you will have throughout your application.
Though, be aware that the weakness of this is approach is that it will be more annoying to get access to the
table instance or read table state where you need it.
When re-using your MRT table component, it will just look something like this:
Debugging Mantine React Table
Mantine React Table (though really TanStack Table) can be a lot easier to debug than other data grid libraries. This is because you are often in charge of the state that you care about, and the entire table instance is available to you in your own scope if you are using the
useMantineReactTable hook. There are also some advanced TanStack Table Dev Tools that you can optionally install.
Console Logging from the Table Instance
When in doubt, console log it! There are a lot of things you can easily console log. Here are some examples:
Console Log All Internal Table State
Console Log Current Rendering Rows