[data grid] Skeleton for loading (replace circular progress?)

[oliviertassinari]

Summary 💡

The central spinner when the data load and refreshes is not very nice.

Motivation 🔦

Instead of a loader, we could render a skeleton. To check with the designer.

Developers can customize it based on this demo: https://material-ui.com/components/data-grid/components/#loading-overlay.

Benchmarks

1. https://react.carbondesignsystem.com/?path=/story/components-datatable--skeleton

2. Toolpad. skeleton for the data grid. It adds some randomness to the length of the bars, and it respects cell alignment. It falls back to LinearProgress when there already are rows. (codesandbox)

One way that this concept could be taken even further is to also consider the data type of the columns and vary the randomness. e.g. for dates or numbers, the length of the content may be more uniform across rows than for text.

3. GitHub

4. https://twitter.com/nots_dney/status/1540318871923486720

5. AG Grid https://www.ag-grid.com/react-data-grid/component-loading-cell-renderer/#skeleton-loading. Missing randomness in the length of the skeleton. Not great. See 2. on how to improve it.

[oliviertassinari]

At this point, it's an RFC, It's not clear what could yield the best UX. I could only find one benchmark.

[dtassone]

We should also consider when we already loaded rows and for some reason, the loading state comes up? New server call.
Should we see the skeleton?

[DanailH]

I'm looking into having such special rows for the second part of the infinite loading feature #1247 because I need to have those skeleton rows in between loaded rows.

I was thinking that we probably need to create a special kind of row?

[Janpot]

Just to add to the benchmark, we created a skeleton for the data grid in Toolpad. It adds some randomness to the length of the bars, and it respects cell alignment. It falls back to LinearProgress when there already are rows. (codesandbox)

Edit: One way that this concept could be taken even further is to also consider the datatype of the columns and vary the randomness. e.g. for dates or numbers the length of the content may be more uniform across rows than for text

[DanailH]

Just to add to the benchmark, we created a skeleton for the data grid in Toolpad. It adds some randomness to the length of the bars, and it respects cell alignment. (codesandbox)

Nice. I wonder do we need a skeleton per cell. We can use the new colspan feature and have it on the skeleton for the entire row.

[Janpot]

Nice. I wonder do we need a skeleton per cell.

The way I understand it is that you'd use a skeleton instead of a spinner to minimize the visual interruption and layout shift when data is loaded. You try to resemble the expected final state as close as possible with the limited information available. That's what I aimed for with the Toolpad implementation and why I went for a skeleton per cell. I think looks better, but I wouldn't argue that it's an absolute requirement.

[oliviertassinari]

I wonder do we need a skeleton per cell.

Design-wise, on my end, it feels much better with one skeleton per cell than one per row.

we created a skeleton for the data grid in Toolpad

Beautiful 😍

[jarb99]

This would be a great feature!! Its already implemented via the Lazy loading https://mui.com/x/react-data-grid/row-updates/#lazy-loading, is it possible to turn this on as a loading overlay for a certain number of rows? This would mean UI consistency in datagrid loading skeletons.

[githorse]

I would think it'd be useful to allow the user to pick between built-in loading screens as well as specify a custom one. Not sure on the details of course but something like

<Datagrid
   loadingOverlay={'spinner' | 'opacity' | 'spinner-opacity' | 'skeleton' | ReactNode}
/>

There's another level of complication here: I find I usually need to distinguish between two types of "loading" states: 1) initial load, where there's no data in the grid at all to display; and 2) refreshes/reloads, where the data is there but is briefly stale. (@dtassone I believe this is your ask as well.) I would love to turn on a grid skeleton for the first case (initial load). For the second case, I usually implement my own "reloading" state that just dials down the opacity. (Reloading is usually fairly quick and I just want a subtle indication that something is going on, but nothing visually jarring.)

It would be cool if the DataGrid could distinguish between those two types of loading.

[coot3]

Just to add to the benchmark, we created a skeleton for the data grid in Toolpad. It adds some randomness to the length of the bars, and it respects cell alignment. It falls back to LinearProgress when there already are rows. (codesandbox)

In case it helps anyone, with the MUI X v6 update, there is now a "scrollPositionChange" GridEvent. You can make Janpots great answer look more natural by using the event to programatically scroll the loading skeleton overlay when the user scrolls the datagrid. The skeleton cells will stay inline with the header row. Updated example of x scrolling:

https://codesandbox.io/s/customloadingoverlaygrid-material-demo-forked-c8xt5x?file=/demo.tsx

[githorse]

Material React Table does a nice job with loading IMO. Looks pretty much like @coot3's version. (I prefer just the skeletons and not the spinner, but that's customizable.)

[joserodolfofreitas]

We already have skeleton rows with lazy loading:
https://mui.com/x/react-data-grid/row-updates/#lazy-loading

Should we have a different API to use it?

[oliviertassinari]

We already have skeleton rows with lazy loading: https://mui.com/x/react-data-grid/row-updates/#lazy-loading

@joserodolfofreitas It's not what <DataGrid loading={true}> does. #1685 (comment)

Also, we are missing the default value documentation in https://mui.com/x/api/data-grid/data-grid/#data-grid-prop-loading for this prop. Fixed in #13604.

[MBilalShafi]

Implemented in #13293

[github-actions]

⚠️ This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

@oliviertassinari: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.