search

mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.55k stars 1.33k forks source link

[data grid] Support data visualization with charts #12021

Open oliviertassinari opened 9 months ago

oliviertassinari commented 9 months ago

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

Benchmark

Search keywords: data grid charts

flaviendelangle commented 9 months ago

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

oliviertassinari commented 9 months ago

@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 commented 9 months ago

@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 commented 9 months ago

@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 commented 9 months ago

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 :ok_hand: