[DataGrid] Add a recipe to persist column width and order

[MBilalShafi]

Resolves #14452

Approach: Using the computedWidth value from the previous state reference at column width hydration.

A similar approach could technically be applied for column reordering by computing the order of columnsState.orderedFields based on the previous state reference.

https://deploy-preview-14560--material-ui-x.netlify.app/x/react-data-grid/column-dimensions/#persisting-column-width

New approach: #14560 (comment)

Preview: https://deploy-preview-14560--material-ui-x.netlify.app/x/react-data-grid/column-recipes/#persisting-column-width-and-order

[mui-bot]

Deploy preview: https://deploy-preview-14560--material-ui-x.netlify.app/

Updated pages:

• docs/data/data-grid/column-recipes/index.md

Generated by 🚫 dangerJS against 3afe7b4

[romgrk]

I don't love how this approach works. I feel like we're complexifying the inner state of the grid even more, and it's already too complex and in need of a refactor. I wonder if there wouldn't be a way to provide a recipe/export hook that would handle this logic outside the grid?

[cherniavskii]

I'm not sure exporting a hook would make things less complex.
IMO this solution is OK given the number of issues we get regarding this.
I'm in favor of merging it, unless we have a better short-term solution.

[MBilalShafi]

It seems a quick win to me with the least amount of learning curve on the user side, once we get a chance to refactor the state, we might approach that in a better way. We could add a follow-up issue so we don't forget about it. Wdyt?

---

Tbh, this specific issue is related to our design choice with the column definitions. i.e. treating the columns prop update as a new set of columns, and this solution is just an escape-hatch tailored per users' requirement.

One way to work that around in the long term could be to treat the columns prop as initalState.something (no more need to stabilize its reference).
The users would then use an imperative API if an update to some colDef is needed.

[arminmeh]

One way to work that around in the long term could be to treat the columns prop as initalState.something (no more need to stabilize its reference).
The users would then use an imperative API if an update to some colDef is needed.

Should we immediately deprecate this flag and in the upcoming major set the new behavior as default?

From my perspective, we should keep all user interactions intact between re-renders. Same is now done with sorting, filtering, pagination, etc. So I don't see why the column resize should be treated differently (setting aside the technical implementation)

Technically, we could rely on the column id and restore the updates even when they are reordered or if some other unrelated props are updated

[romgrk]

From my perspective, we should keep all user interactions intact between re-renders. Same is now done with sorting, filtering, pagination, etc

Not really the same, those models are either controlled or uncontrolled. Columns are the only model that is semi-controlled.

[cherniavskii]

@romgrk This looks promising!
columnState.update would track the column width and order states and apply them to the provided column definitions, correct?
Also, how about passing column definitions to the useColumnState hook directly?

[romgrk]

Yes, the hook could track width & order. And yes, we can also refactor it further to make it more ergonomic, I just wanted to illustrate how it can work:

const columnState = useColumnState(useMemo(() => [
  { field: 'id', width: 100 },
  { field: 'username' },
  { field: 'email' },
], []))

<DataGrid
  columns={columnState.columns}
  onColumnWidthChange={columnState.onWidthChange}
  onColumnOrderChange={columnState.onOrderChange}
/>

[MBilalShafi]

Thanks for sharing the interface @romgrk. I'll try to POC it.

On first impression, it seems we might also have to replicate some internal logic or do some refactoring to it because on the first render when it does internal computations like for the flex columns, it doesn't call onColumnWidthChange. We don't have a reactive state binding option for the export hook too.

[romgrk]

Is it really necessary to have the flex width? The goal is only to persist resize/reorder, so I think using the events as they are should be enough. The first resize event will contain the correct width to persist, and before that there is no need to persist it, the grid will do its thing as it does now.

[MBilalShafi]

Is it really necessary to have the flex width?

I think we can start without it and wait for the users to request a specific need for it. The idea seems to work great: https://stackblitz.com/edit/react-l6w6ni?file=Demo.tsx 👍

I'll update this PR with this recipe instead of the internal implementation.

Updated: https://deploy-preview-14560--material-ui-x.netlify.app/x/react-data-grid/column-recipes/#persisting-column-width-and-order