Tree shaking doesnt work properly for mui-x datagrid and datepicker

[andriijas]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example:
Two examples
https://github.com/andriijas/mui-x-bundle-size/tree/splitChunks
or
https://github.com/andriijas/mui-x-bundle-size/tree/suspense

Steps:

1. git clone
2. npm install
3. npm run build

Current behavior 😯

Current behavior adds excessive amount of script, it also increases build speed a lot.
Also look how it adds ALL of date-fns via the adapter, is everything actually used?

Similar issue #18

Expected behavior 🤔

mui-x should be tree shakeable like mui,

Could import like this like in mui help?

import Datagrid  from "@mui/x-data-grid/DataGrid";
import GridColDef  from "@mui/x-data-grid/GridColDef";

instead of

import {DataGrid,GridColDef}  from "@mui/x-data-grid";

Context 🔦

Without the Datepicker and datagrid demo in Album.tsx:

With the Datepicker and datagrid demo in Album.tsx, the app grows from 245kb to 920kb, and the build speed increases significantly.

Your environment 🌎

npx @mui/envinfo

~/C/mui-x-bundle-size ❯❯❯ npx @mui/envinfo
Need to install the following packages:
  @mui/[email protected]
Ok to proceed? (y) y

  System:
    OS: macOS 13.1
  Binaries:
    Node: 18.12.1 - /opt/homebrew/opt/node@18/bin/node
    Yarn: Not Found
    npm: 8.19.2 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: Not Found
    Edge: Not Found
    Firefox: Not Found
    Safari: 16.2
  npmPackages:
    @emotion/react: 11.10.5 => 11.10.5 
    @emotion/styled: 11.10.5 => 11.10.5 
    @mui/base:  5.0.0-alpha.112 
    @mui/core-downloads-tracker:  5.11.2 
    @mui/icons-material: 5.11.0 => 5.11.0 
    @mui/material: 5.11.2 => 5.11.2 
    @mui/private-theming:  5.11.2 
    @mui/styled-engine:  5.11.0 
    @mui/system:  5.11.2 
    @mui/types:  7.2.3 
    @mui/utils:  5.11.2 
    @mui/x-data-grid: 5.17.17 => 5.17.17 
    @mui/x-date-pickers: 5.0.12 => 5.0.12 
    @types/react:  18.0.26 
    react: 18.2.0 => 18.2.0 
    react-dom: 18.2.0 => 18.2.0 
    typescript: 4.9.4 => 4.9.4 

Order ID 💳 (optional)

No response

[andriijas]

Related #5076

In the example repo provided above, switching to dayjs adapter - builds faster than with the datefns adapter.
But thats just looking at the adapter part

[LukasTy]

Hello @andriijas

I've looked at the examples a bit.
Let's firstly start with a preface that Data Grid as well as Date and Time Pickers are complex components combining a lot of small components and huge amount of features. Although, I'm not saying that there are no space for improvement. 🤔

Ideally, such big ui libraries "must" be separated into their own bundle and lazy loaded in order to improve end user experience (responsiveness), but I'd think that it is the main thing that everyone would reach for when improving app performance.

As for date-fns, you can also refer to our next (v6) doc comparing the resulting bundle size using each of the adapters. It clearly shows that if you want the smallest bundle size, using dayjs is recommended. date-fns is simply built like that (utilities have to be imported rather than ran on the date object), that's why the adapter is quite large regardless if you are actually using the underlying code or not.

[cherniavskii]

I agree with @LukasTy

Regarding this:

mui-x should be tree shakeable like mui,
Could import like this like in mui help?

import Datagrid  from "@mui/x-data-grid/DataGrid";
import GridColDef  from "@mui/x-data-grid/GridColDef";

MUI X packages are tree shakeable out of the box.
Using path imports instead of named top-level imports would not impact the production bundle - tree shaking will work in both cases.
The only difference it could make is a slightly faster startup time in development mode - see https://mui.com/material-ui/guides/minimizing-bundle-size/#development-environment
But in the case of @mui/x-data-grid specifically, there won't be much difference since the package only exposes a single component and almost all the code is imported anyway.

[andriijas]

I've looked at the examples a bit. Let's firstly start with a preface that Data Grid as well as Date and Time Pickers are complex components combining a lot of small components and huge amount of features. Although, I'm not saying that there are no space for improvement. 🤔

I absolutely agree on this, in my teams we did prioritise shipping product over optimal bundle size by opting in to these packages rather than writing our own.

But I think we all can agree that in best of worlds you want the benefits of both ways.

As seen in the examples we do use similar pattern in real project to have these packages in their own chunks and only loaded by the views that actually provides a datagrid or a datepicker but It would be cool if its possible to make the packages lighter if not using all features of them. / thanks🙏

We will probably look into switching to dayjs as we dont use date-fns a lot. That would save some bandwidth at least :)

Thanks everyone.

[oliviertassinari]

So, we can close? It's more a problem with having too much logic, than tree-shaking.

I think that one of the most impactful thing we could do is solve #5550 so we can accurately measure progress.

[andriijas]

@oliviertassinari @cherniavskii @LukasTy is it recommended to wrap the whole app with @mui/x-date-pickers/LocalizationProvider or it should only wrap actual DatePicker instances?

[flaviendelangle]

I would recommend to wrap the whole app with a LocalizationProvider and to wrap DatePicker instances only when needed.
That way you never risk to have a picker without any adapter accessible.

If can be needed if you need to pass some localeText so a specific picker.
But in v6 we are putting a localeText prop on every component to avoid having to use LocalizationProvider for this use case.