论前端的 “模块化” 与 “组件化”
08 Nov 2016
Reading time ~1 minute
论前端的 “模块化” 与 “组件化”
什么是 “模块” 和 “组件”
之前在思考架构时常常被这两个概念搞迷糊，两者听上去极其相似，都包含封装的意思，但区别是什么？
关于前端开发中 “模块” 和 “组件” 概念的思考 这一 issue 中对两者在前端中的是是非非有较为深入的讨论与剖析。
模块（对应英文 “module”）
通常所指 “模块” 是指编程语言所提供的代码组织机制，利用此机制可将程序拆解为独立且通用的代码单元。
组件（对应英文 “component”）
另一个概念是“组件”。大体上 “组件” 和 “模块” 的概念是类似的，只是 “组件” 通常指更 high-level 的东西。
下面的阐述个人是比较赞同的：
- “module” 指存储单元，其意义偏向静态的代码结构（不一定是文件）
- “component” 指功能单元，其意义偏向运行时的结构，并有更复杂的控制（如组件实例的生命周期管理）
两者是正交的。从开发者的角度来看，接触的是 components，一个页面是一个 component，里面包含若干 component（有 ui 的，也有与 ui 不相关的，比如一个 PageComponent 可以由 HeadComponent + ContentComponent + EventCenterComponent 组成），这些 component 在 react 里最终以 js 代码呈现，这些 js （含转换成 js 的 css）代码的存储方式，涉及 module system，一个好的 module system，可以做到让上层组件开发者透明。
组件化和模块化
“资源高内聚” html 与 js内聚 “作用域独立” js 的作用域独立 “自定义标签” jsx “可相互组合” 可组合，但缺乏有效的加载方式 “接口规范化” 组件生命周期方法
前端组件的复用性
所谓组件化，核心意义莫过于提取真正有复用价值的东西。那怎样的东西有复用价值呢？
-
组件 对于组件的可复用性，基本上是没有争议的，因为这是实实在在的通用功能，并且比较独立。
-
基础逻辑功能 基础逻辑功能主要指的是一些与界面无关的东西，比如underscore这样的辅助库，或者一些校验等等纯逻辑功能。
-
公共样式 公共样式的复用性也是比较容易认可的，因此也会有bootstrap，foundation，semantic这些东西的流行，不过它们也不是纯粹的样式库了，也带有一些小的逻辑封装。
-
稳定的业务逻辑 最后一块，也就是业务逻辑。这一块的复用是存在很多争议的，一方面是，很多人不认同业务逻辑也需要组件化，另一方面，这块东西究竟怎样去组件化，也很需要思考。
除了上面列出的这些之外，还有大量的业务界面，这块东西很显然复用价值很低，基本不存在复用性，但仍然有很多方案中把它们 “组件化” 了，使得它们成为了 “不具有复用性的组件”。为什么会出现这种情况呢？
组件化的本质目的并不一定是要为了可复用，而是提升可维护性。
前端组件化的根本目标是 分而治之 的开发维护方式，复用 只是第二位的需求。
参考文档
alcat2008
Dreamer, Practitioner, Incomplete Front-ender