[data grid] Support data visualization with 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.

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".

The main reason people would want to use this and not eject their data to Excel, etc. It's about product manager providing the ability to their end-users to operate on a lot of data without having to give direct data access and delaying as much as possible the need to "eject" out of the app.

The "other tools" are almost exclusively limited to internal tool use cases in the ways they are designed. They make it possible to embed data with iframes, but not to have 10,000 people accessing to tool to create custom data viz.

Motivation

This also connects well with the direction we are taking for https://github.com/mui/mui-toolpad allowing developers to quickly create dashboards, part of the use case is to analyze data.

Other requests

• https://www.notion.so/mui-org/122cbfe7b660805ab11ff540655a0dd4?d=122cbfe7b6608073ba5b001cd100ae6e

Benchmark

• https://ag-grid.com/javascript-data-grid/integrated-charts/

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 👌