模块导入和解构性能

Question

我最近阅读了 Material-UI 的文档：

请注意，在上面的示例中，我们使用了：

import RaisedButton from 'material-ui/RaisedButton'

而不是

import {RaisedButton} from 'material-ui'

这将使您的构建过程更快，您的构建输出更小。

我以前以为是一模一样的，但实际上，这意味着第二行就像：

import materialUI from 'material-ui'
const {RaisedButton} = materialUI

它会产生完全相同的捆绑包，对吧？

我做了一些测试，比较包大小使用不同的导入组合和 2 个文件：

index.js：

import RaisedButton from 'material-ui/RaisedButton'
// or import {RaisedButton} from 'material-ui'
import file from './otherFile.js'

console.log(RaisedButton)
console.log(file)

otherFile.js

import RaisedButton from 'material-ui/RaisedButton'
// or import {RaisedButton} from 'material-ui'

export default RaisedButton

结果完全符合预期，仅使用 import RaisedButton from 'material-ui/RaisedButton' 捆绑包将类似于 24k LoC（material-ui 加载 React 依赖项）。使用import {RaisedButton} from 'material-ui'，在一个或两个文件中，捆绑包将类似于57k LoC。

我的问题主要是关于性能和最佳实践，使用少量 Material-UI 我应该始终导入 from 'material-ui/ComponentName，但如果我在更大的项目中使用大量 Material-UI 组件，它不会影响如果我使用import {Comp1, Comp2, Comp3} from 'material-ui'，捆绑包的大小会只在捆绑包中导入一次？

Answer 1

是的，这是正确的。通过这样做：

import {RaisedButton} from 'material-ui'

将包含“material-ui”的根库文件。在该文件中，它可能有很多 import RaisedButton from './RaisedButton' 语句来一次包含库的所有组件（请参阅 https://github.com/callemall/material-ui/blob/master/src/index.js）。

在做：

import RaisedButton from 'material-ui/RaisedButton'

始终会在包大小方面保证更好的性能，因为您只会获得所需的依赖项。如果您只使用几个组件，这也将提高构建速度，因为它不需要为库中的其他组件解析文件。

如果您使用库中的所有或几乎所有组件，构建性能应该大致相同，因为如果“material-ui”的根脚本和您的文件都需要相同的组件两次，您的捆绑器将足够聪明地缓存结果并且不会重新解析文件。在这种情况下，您的捆绑器将使过度导入相同的东西成为一种廉价的操作。

我建议使用import RaisedButton from 'material-ui/RaisedButton' 语法，因为随着时间的推移，这更能适应您的需求，因为您可能并不总是需要所有组件，而且您不太可能同时使用所有组件。此外，一些打包工具（例如 webpack）支持打包拆分，这对于 import {RaisedButton} from 'material-ui' 方法来说并不容易。

Answer 2

如果您使用 Webpack，解构语法应该有助于从输出文件中删除未使用的 Javascript，因为 Webpack supports Tree-Shaking，前提是满足以下条件（引自 webpack 的网站）：

• 使用 ES2015 模块语法（即导入和导出）。
• 确保没有编译器将您的 ES2015 模块语法转换为 CommonJS 模块（这是流行的 Babel 预设的默认行为 @babel/preset-env - 查看文档了解更多详情）。
• 将“sideEffects”属性添加到项目的 package.json 文件中。
• 使用生产模式配置选项启用各种优化，包括缩小和摇树。