[docs] Fix typos #1447
[docs] Fix typos #1447
Conversation
| @@ -66,7 +66,7 @@ We provide three options: | |||
|
|
|||
| - Built with and exclusively for React ⚛️ | |||
| - High performance 🚀 | |||
| - Lightweight; less than [30 kB](https://bundlephobia.com/result?p=@material-ui/data-grid) gzipped with as few dependencies as possible. | |||
| - Lightweight; less than [55 kB](https://bundlephobia.com/result?p=@material-ui/data-grid) gzipped with as few dependencies as possible. | |||
There was a problem hiding this comment.
This is not lightweight, this is almost bloated. I couldn't spot any major bump. It seems to be simply related to the features. Maybe we write them in a way that is particularly bundled size intensive. No idea, a plugin system become more relevant now (#924). We have to be careful. Soon nobody will want to use the MIT version because the bundle size tradeoff won't worth it. Also a good reason to port back the bundle size tracker #37.
| - Lightweight; less than [55 kB](https://bundlephobia.com/result?p=@material-ui/data-grid) gzipped with as few dependencies as possible. | |
| - Weight [55 kB](https://bundlephobia.com/result?p=@material-ui/data-grid) gzipped with as few dependencies as possible. |
There was a problem hiding this comment.
Maybe we altogether remove this mentioning of 55kb bundle size from Features if it's risky to mention which may lead to less/no users. Better than mentioning false size (user doesn't know we forgot to update doc). When we act on #924 we can specify it as a good feature of isolation.
Also is data-grid tree-shakeable?
There was a problem hiding this comment.
Also is data-grid tree-shakeable
Yes, to some extent. For instance, because we didn't bundle the Toolbar, it's tree-shakeable. I think that ideally with #924, we would create a public hook API developers can use, with a plugin system.
Why not remove the weight 👍
| - Lightweight; less than [55 kB](https://bundlephobia.com/result?p=@material-ui/data-grid) gzipped with as few dependencies as possible. |
There was a problem hiding this comment.
#924 is part of the beta so we need to start looking at it. I'm interested in picking it up.
There was a problem hiding this comment.
Actually no, I was wrong. It looks like tree-shaking doesn't work with our packages:
This looks like a quick win. We have been careless about this aspect. https://github.com/mui-org/material-ui/blob/4d7fb7c197f6bc345e9705d45dfb5e03bef70075/packages/material-ui/package.json#L78
The previous investigation regarding bundle size opportunities: #954.
@DanailH It depends on what we want to optimize for. If bundle size is our biggest interest, I think that we should start with bundle size monitoring at each PR. Being able to continuously measure changes is paramount. We can only improve what you can measure. Same reason why writing tests is critical when solving complex problems.
The main value I see with #924 is that it makes us competitive with react-table. The great side nice effects being:
- more tree-shaking
- isolation of MIT vs. commercial
- allow community plugins
- force us to better architecture the state
There was a problem hiding this comment.
I spend half an hour diving into why this happens. There are more issues than I thought. I have updated #18 with the problems and solutions. For instance, all the developers bundle all the locales 😱.
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
|
@mui-org/x Anyone wants to merge this one? |
Few typos in the docs.