模块化

开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天，点击查看活动详情

复杂文件封装成几个文件或者几个模块 解决各个模块之间的耦合性 命名之间的冲突

模块化

全部写在一个文件中 命名污染

//mod.js
var msg = '111'
function add(){
}
function some(){
}

//html
<script>
var msg = '222'
忘记mod.js中写入过msg，污染了变量
</script>

NameSace模式 减少全局变量 避免命名冲突 但是保存在对象中不安全

var MYAPP = {
    msg:'111',
    fn(){
        console.log(this.msg)
    }
}
MYAPP.fn() //111
MYAPP.msg = '222'
MYAPP.fn() //222
变量被修改 不安全

IIFE立即执行函数 相对安全 外界操作不到

var modules = (function(){
    var _private = 'safe'
    var foo = function(){
    }
    retrun {
    foo:foo
    }
})()
modules._private //undefined
modules.foo() //undefined

引入依赖 模块模式 现代模块实现的基石

为什么要模块化

降低复杂度 提高解耦性

部署优化 某个Js模块只针对某个功能进行开发 其他模块中没有必要再进行引入 按需加载

可维护性更高

高复用性

如果没有模块化规范 现实是在写模块化中 可能引起 十次标签意味着发十次请求 而且各个script之间可能存在互相依赖 依赖模糊 修改一个文件可能其他文件跟着报错 请求过多

commonjs 有require语法 export暴露语法 每个文件都是一个模块 浏览器端：需要提前打包编译 打包工具是browrify

服务端：模块同步加载 需要加载某个模块可能需要再服务端进行等待 导致页面白屏

语法 有require语法 export暴露语法 暴露的本质是对象 module.export本身就是一个对象 只是value把它覆盖了

package.json 处在根目录 必须要有俩个字段 name version 用于下载 更新

commonjs在node的应用

commonjs在浏览器的应用

使用browserify --dev表示只在开发使用 线上运行不使用这个包 因为只是帮助我们进行打包 上线没有其他用处

客户端在使用src引入app.js的时候 使用require方法 浏览器不会识别出来 需要借助打包工具

开发和线上的包放在不同的地方

npm install的时候回创建node_modules

使用工具 找到目标文件达到 输出文件

AMD 没有amd的写法

AMD规范