[RFC] Use `import * as Mui from 'material-ui'` in the demos

• I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

Instead of recommending to use named exports, how about recommending importing all modules?

• it won’t increase the bundles and is not worse in terms of initial parsing for development workflow than named imports

Examples 🌈

Before:

import { Button, Table, ... } from "@material-ui/core"

After:

import * as Mui from "@material-ui/core"

Motivation 🔦

Pros:

• improves consistency
  • because a similar decision was made here
    • material-ui doesn’t import named exports from react, why should imports from material-ui be different?
• improves DX
  • as it removes the need to manually clean up unused imports (when there is a linter rule in development workflow).
  • as it removes the need to manually add new imports from Mui
    • as IDEs most of the time fail to auto import from libraries already present in the module
  • as it is cleaner, since less individual imports are in the module
    • it is easier to understand where the variable is coming from while looking at the code, as you know the variable in question belongs to Mui
      • for example: Mui.Button is a pure Mui button, whereas Button is part of your project’s modifications that fell outside of what you can do with theme’s customizations
• it’s better marketing for material-ui and useful for beginners, as developers are reminded on what they use as they use values from Mui.

Cons:

• the amount of code writing (less lines, but a bit more actual text) is more as there’d be a prefix everywhere: Mui.
  • but the clear indication where these variables are coming from is far more important

Example project

For your convenience I created a simple example that showcases:

• tree-shaking of material-ui works when importing all

Basically I put @oliviertassinari example function into a new CRA project. Please follow commits as it’s easier to understand what has been changed in a pure CRA project.

And here is a screenshot of the webpack-bundle-analyzer. We can clearly see that only the button and what’s necessary for it is imported (to see it for yourself, run yarn build):

[oliviertassinari]

Another pros I didn’t thought about before. The mui.* pattern makes it easier to identify what’s used in the codebase. Say you have multiple custom buttons, searching for mui.Button will give you more accurate results.

We never destruture the theme object in the codebase for this very reason. We always do theme.palette.divider, not const { divider } = theme.palette.

It’s important for refactoring.

[troglotit]

My experience report as per https://twitter.com/troglotit/status/1356496801067589633 is that it’s a bit different paradigm, bit it shines when you structure your app using namespaces/modules

import * as MUI from '@material-ui/core'
import * as C from '../components'
// components/index.js
export * from 'Button.js'

compared to

import { Button as MuiButton } from '@material-ui/core'
import { Button as MyButton } from '../components/Button.js' // or import Button from '../components/Button.js'

Some can say that one-letter variables are bad, but when for the whole app only components-module is named “C” it’s like using “i” in for-loops. And IntelliSense with namespaces/modules is so satisfying

Then I free myself from problem of either a) name-clashes of auto-import (it just seems bizarre that only yesterday we stopped using global scoping, but somehow it’s ok for auto-imports) b) coming up with “MyButton” name when it’s just a regular button in my app code.