-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Closed
Labels
performancescope: data gridChanges related to the data grid.Changes related to the data grid.umbrellaFor grouping multiple issues to provide a holistic viewFor grouping multiple issues to provide a holistic view
Description
The current bundle size and bundling strategy is not great. It's not living up to the quality level the audience expects from the core components. https://bundlephobia.com/result?p=@material-ui/data-grid
Tree-shaking ✅
First, tree-shaking is not working. (tested with CRA). This means that, for instance, developers bundle all the locales. I think that the solution is to drop the current bundling strategy and copy what the core is doing. I think that this bundling problem is hard enough, we don't have the resources to solve the problems twice because we use two different solutions between different packages.
in
import * as React from 'react';
import { GridToolbar } from '@material-ui/data-grid';
export default function DataGridDemo() {
console.log('GridToolbar', GridToolbar)
return null;
}out, in the production bundle
Inefficiencies
Second, here is a couple of bundle size-reduction opportunities:
- Babel (win ~0.6 kB gzipped) Remove propTypes in production with this Babel plugin.
- clsx. (win ~0.3 kB gzipped) Replace classnames with clsx.
- lodash. The dependency was inlined in the repository (I guess to hide, on the surface, the dependency on this library), I don't think that it removes the fact that we depend on it. I would be in favor of completely removing its modules from the codebase.
Recommended migration plan: - denounce. (win ~ (0.5 kB) Instead of the 938 B version of lodash we could rely on the 305 B
import { denounce } from @material-ui/coremodule. We could also move the module to@material-ui/utilsinstead of the core if that makes more sense. This module also has the advantage of being deduplicated with the core components, sharing the simple source. - deep equal. (win ~3.5 kB gzipped) Instead of the 3.8 Kb version of lodash, we could replace it with fast-deep-equal, a 414 B alternative. I have only seen one use case in the codebase, I even wonder if we couldn't use JSON.stringify directly (see [core] Remove lodash
isDeepEqualusages #3954) - Select. (win ~0.5 kB gzipped) Replace Select import with NativeSelect).
- TextField (win ~5 kB gzipped). Replace TextField with individual imports, allow dropping
OutlinedInputandFilledInputfrom the bundle.. - license. (win ~0.7 kB) I believe we can remove the need from including
packages/license/src/encoding/base64.tsin the bundle of the users. The possible solution would work as follow:- client-side, use the built-in
window.atobandwindow.btoa, only run the license check if the window is defined (ignore server-side, and CI) - server-side, us the built-in
Buffer.from('Hello World!').toString('base64');andBuffer.from(b64Encoded, 'base64').toString()utils.
- client-side, use the built-in
oliviertassinari, warmbowski, Tittoh and Leafgard
Metadata
Metadata
Assignees
Labels
performancescope: data gridChanges related to the data grid.Changes related to the data grid.umbrellaFor grouping multiple issues to provide a holistic viewFor grouping multiple issues to provide a holistic view

