[data grid] Add data visualization / charts

[oliviertassinari]

Summary

This issue is a continuation of #214, pivots are meant to aggregate data on the fly; it's a low-code SQL query writer.

With this released, we can expect people to want chart integration. The general trend is well explained in https://www.producthunt.com/products/metabase#metabase-embedded-analytics:

Once users get a taste of insights, their expectations escalate fast.

Adding charts on top of it could make for the most logical next step. Turning the data grid into a mini Superset, Metabase, Excel, PowerBI: defined as "other tools".

Motivation

Once you filter, group, pivot, the data to reach the point that you like, you are likely to start to want to plot the data. To do such, you need to:

• export the data to excel or CSV
• open an "other tools"
• find the file
• import the data
• create the chart

The problems with this:

1. This takes a couple of steps. Steps that could be saved if the UI allowed plotting to plot the chart directly Now, this can only be solved to a level; advanced plotting will always require another tool, but how frequent is this need? 10% of the time?

2. Once you plot the data, you are likely to realize that you forgot a column, that you want to drill down in another direction, etc. So you go back to the grid, re-export the data, and replot again. This back and forth is painful.

3. Does your end-user even have a plotting tool? I have tried with ChatGPT and DeepSeek, they fail at it. Excel and Google Sheets seem to be the most likely tools used.

As for using "other tools", this is not an option for end-users because it is usually impossible to embed. For internal tool users, it can be a challenge to manage permissions, so it's not always the right solution.

User requests

https://www.notion.so/mui-org/mui-x-Data-Grid-Charts-integration-1dfcbfe7b6608035b4e8cfaec65180c1?pvs=4#1eecbfe7b6608084a0d2f08ecfb714b5

Solution

Worked on https://www.notion.so/mui-org/mui-x-Data-Grid-Charts-integration-1dfcbfe7b6608035b4e8cfaec65180c1.

Benchmarks

• Public: https://mui-org.notion.site/mui-x-Data-Grid-Pivot-1e4cbfe7b660806dbe71fa96c8a0295e
• Editable: https://www.notion.so/mui-org/mui-x-Data-Grid-Pivot-1e4cbfe7b660806dbe71fa96c8a0295e

Context

• This feature is needed to fully take advantage of [ai-assistant] Improve Data Grid #17292. This flow isn't optimal: https://www.zdnet.com/article/how-to-use-chatgpt-to-make-charts-and-tables-with-advanced-data-analysis/. But this https://x.com/openbb_finance/status/1866966784747684309 is more coherent.
• The problem on the opposite side: [charts] Drill down in series with data grid #16286

Search keywords: data grid charts

[flaviendelangle]

Should this feature be linked in the doc like we did for other major feature with "waiting for 👍 "?

[oliviertassinari]

@flaviendelangle As I understand it when we link a feature in the docs we commit to building it in the mid-term (~18 months).

I don't know if we will eventually build this one. There is a huge opportunity cost that comes with it: focus. I think we should see a signal from users using the Pivot feature, so I think we should wait. What are we not building if we build this? I would be as excited to go after other initiatives touching on data source integration, AI help, backend services.

cc @joserodolfofreitas

[flaviendelangle]

@flaviendelangle As I understand it when we link a feature in the docs we commit to building it in the mid-term (~18 months).

Do we?
For the grid, we still have several major features with issues created in 2020 (#207, #214 for instance) that are linked in the doc

[oliviertassinari]

@flaviendelangle Right, maybe not 18 months, but our initiative roadmap to build those was more aggressive 😁. In that case, we can reframe my point to we link was we commit to eventually build. For things we are unclear, it's probably best to not link so we can compare the upvotes on the same baseline with the other features that we might not want to build.

[flaviendelangle]

I do agree that we have to be consistent because we cannot compare the up-votes of an issue with a link in the doc and an issue without any.

For me the main interest of the link in the doc is to multiply the amount of people seeing it and to have a more representative dataset on our up-votes, not only from people that go to the Github issues.
I think it worked very well with the grid where we reached hundreds of up-votes and we were pretty confident that an issue with 800 up-votes is more requested that one with 150.

I would be in favor of linking in the doc the big features that will shape the future of our components (the only one you listed like AI help or backend services are clearly good candidates too).

But consistency is the most important part of course 👌