现代化前端的全局引入是一个颇有趣的东西。 先来看下如下几个场景:前端
resolve: { alias: { '@': path.join(__dirname, '..', 'src') }}
。Vue.prototype.$_ = lodash
,在应用了vue的应用上下文中,能够经过this.$_得到对lodash的引用。来思考一个问题:vue
若是咱们再Vue.prototype上绑定了太多,太大的第三方库,会不会致使root vue过大?
答案是确定的。
有没有办法解决这个问题?
你可能会说,我不用this.xxx。用到的vue单文件组件直接import或者require就行了。
若是数以百计,数以千计甚至是数以万计的.vue文件中用到了呢?一直引入吗?
能够一直引入。可是会形成没必要要的工做量。
复制代码
有没有更加优雅的解决办法?webpack
再来思考一个问题:web
若是我要在一个webpack打包覆盖的地方的xxx.js文件中用到lodash,该怎么作?
一般来说,咱们会直接`import _ from' lodash'`或者`const _ = require('lodash')`。
若是和.vue同样,有不少不少js文件须要引入呢?一直引入吗?
能够一直引入。一样会形成没必要要的工做量。
复制代码
有没有更加优雅的实现方式?vuex
看一张一直引入moment,引了99次的图先来感觉一下:bash
// 语法
new webpack.ProvidePlugin({
identifier: 'module1',
// identifier: ['module1', 'property1'],
});
复制代码
new webpack.ProvidePlugin({
$_: 'lodash',
});
复制代码
new webpack.ProvidePlugin({
$_uniqBy: ['lodash','uniqBy']
});
复制代码
new webpack.ProvidePlugin({
Vue: ['vue/dist/vue.esm.js', 'default']
});
复制代码
加入咱们有a~z,a.js到z.js总结26个js文件,每一个文件都须要引入lodash。ide
// a.js
import $_ from 'lodash';
// b.js
import $_ from 'lodash';
// c.js
import $_ from 'lodash';
// d.js
import $_ from 'lodash';
// e.js
import $_ from 'lodash';
// f.js
import $_ from 'lodash';
...
// z.js
import $_ from 'lodash';
复制代码
这样作有如下几个弊端函数
好比说下面这种场景,对于代码可读性是很很差的。优化
// a.js
import $_ from 'lodash';
// b.js
import _ from 'lodash';
复制代码
// webpack.base.config.js
plugins: [
new webpack.ProvidePlugin({
$_: 'lodash',
}),
],
复制代码
// .eslintrc.js
globals: {
$_: 'readonly', // 或者true
},
复制代码
配置为readonly是由于咱们不会改写lodash,仅仅是调用其方法。ui
假设在a.js中。 删除单独的lodash引入 _ :import _ from 'lodash' 直接使用$_
:$_.uniqBy(...)
不会。 这是我本身对比使用ProvidePlugin前和使用ProvidePlugin后打包文件体积大小得出的结论。 至于具体缘由还有待探索。
这些注意事项其实主要是为了加强代码可读性和可维护性。
看到这里,文章开头Vue.prototype.xxx
和import和require重复引入的问题”有没有更加优雅的实现方式?“就迎刃而解啦。
快到你的项目中试试ProvidePlugin吧~