首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    JS模块化开发的价值

    非模块化方式开发的痛苦 (1)命名冲突 起初,我们定义了一个通用功能的JS文件,例如 utils.js(其中有一个 each 函数),谁需要谁调用即可 但随着项目和团队越来越大,就会出现问题 小杨在自己的...a.js 中也定义了一个 each 函数,这时有人同时引用了 utils.js 和 a.js,冲突就出现了,小杨只好把自己的 each函数名改为别的,再通知别人改名了,之后,不同开发人员之间不断出现这类问题...后来,团队决定引入命名空间,对 utils.js 进行改造 var org = {}; org.CoolSite = {}; org.CoolSite.Utils = {}; org.CoolSite.Utils.each...function (arr) { // 实现代码 }; 这时,为了调用一个简单的each函数,就要记住一长串的包名 (2)文件依赖 团队又写了一个工具文件,叫 dialog.js,其中需要使用 utils.js...其中的函数,在文档中明确指出使用 dialog.js时必须要先引入 utils.js 有一个 b.js,使用了 dialog.js,页面中就必须引入多个文件,并且顺序不能错 <script src="

    1.6K40

    为什么 CommonJS 会使你的程序包变大

    例如在上面的代码段中,最终的包应该只包含 add 函数,因为这是你从utils.js 中导入到在 index.js 中的的唯一符号。...如果看一下输出,我们将从 utils.js 中找到所有函数,再从 lodash 中找到很多模块。...因为 webpack 能够(在构建时)静态地知道我们正在从 utils.js 中导入及导出了哪些符号,所以只能进行 tree-shaking 。...让我们看一看完全相同的例子,但是这次将 utils.js 改为使用 CommonJS 而不是 ES 模块: // utils.js const { maxBy } = require('lodash-es...这次,我们没有把来自 utils.js 和 index.js 的所有符号放在同一个命名空间下,而是在运行时动态地使用了__webpack_require__ 的 add 函数。

    94730
    领券