feat(ui): remember mantine-react-table preferences per table#4811
feat(ui): remember mantine-react-table preferences per table#4811
Conversation
Add a translated MRT hook that accepts a stable table id and persists user preferences (column visibility/order/sizing/pinning, density, pagination, sorting, filters) to localStorage. Notes: - Uses an isomorphic layout effect to hydrate on first mount (avoids SSR hydration mismatch). - Uses a reducer to manage preference state as a single object. - Loads MRT localization via non-suspense query so preference hydration is not blocked.
Pass a stable `id` into `useTranslatedMantineReactTable` across management tables, widgets, and modals so column/layout preferences are stored independently per table.
|
Here's the code health analysis summary for commits Analysis Summary
|
This comment was marked as outdated.
This comment was marked as outdated.
|
Okay I discarded my code, it causes an infinity loop. Do you think the benefit of adding this outweights the problems it has with flickering and changing of UI between server & client? Because for example if I choose to have 5 per page and open the user management page it shows me 10 until it has completed loading where it now shows me 5 |
I am not 100% sure about this, personally I don't mind a small refresh if it gets me to see the info I care about. I think we should consider this looking at all the tables used throughout the app and decide. We could make it some kind of toggle to "save layout to localstorage" as a good compromise (false by default) |
|
Yeah I like the idea of having it an option to the user, then by default nobody will complain and if they use the feature they "know" why it looks like it does |
|
Waiting for #4915 to be merged before adding a new preference |
Summary
Adds per-table preference persistence for Mantine React Table (MRT) when using
useTranslatedMantineReactTable.How it works (and why it looks a bit “weird”)
There can be a small layout shift on first load: on a full page load, Next.js server-rendered HTML cannot include
localStoragepreferences.Client-side navigation feels instant: when navigating within the app, the table is rendered client-side and the preference hydration runs immediately (before paint) via an isomorphic layout effect, so the saved preferences apply almost instantly.
Why
useIsomorphicLayoutEffectexists: it usesuseLayoutEffectonly in the browser (to apply preferences before paint), but falls back touseEffecton the server to avoid React warnings.Why localization uses
useQuery(non-suspense): using suspense here could delay preference hydration; we load localization asynchronously and attach it when ready.Why a reducer: preferences are stored as one state object to reduce multiple
useStatecalls and keep updates consistent.