前端组件化思想

Qter

https://github.com/xufei/blog

https://github.com/xufei/blog/issues/22

1. 基本概念什么是Web应用？

所谓Web应用，指的是那些虽然用Web技术构建，但是展现形式却跟桌面程序或者移动端原生应用类似的产品。这类产品的特点是逻辑较重，交互复杂，通常也是单页式的。

主要包括：

• 交互占比较高的页面体系
• 以各种Hybrid技术构建的应用，其中的Web部分
  

大部分可以等同于所谓的“单页面应用”，可以参见之前写的这篇：构建单页Web应用

组件化开发的优势是什么？

组件化的最重要作用就是提升开发和维护的效率。

最原始的组件，其功能可以单独开发测试，然后逐级拼装成更复杂的组件，直到整个应用。每一级都是易装配，可追踪，可管控的。

在Web应用中，组件化一般指什么？

在开发Web应用的时候，无论技术选型，工程方案，还是对人员的技能需求都是有一些特点的，最重要的特点莫过于组件化。

组件化这个词，在UI这一层通常指“标签化”，也就是把大块的业务界面，拆分成若干小块，然后进行组装。

狭义的组件化一般是指标签化，也就是以自定义标签（自定义属性）为核心的机制。

广义的组件化包括对数据逻辑层业务梳理，形成不同层级的能力封装。

在Web应用中，组件化的主要目标是什么？

很多人会把复用作为组件化的第一需求，但实际上，在UI层，复用的价值远远比不上分治。

分治带来的是可管理性，相比一大团HTML和JavaScript的混杂，组件化之后，整个应用成为了一个很清晰的树，一眼就能看清包含关系，也能够很容易理清数据的传递方向。而且，整个应用可以从叶子节点，逐步向上测试，哪一级出了问题，可以很容易发现。

但是复用就很麻烦了，因为组件的内部实现与外部接口都很难取舍。很可能我们在设计之初，都是把组件设想成一个单一的东西，然后在实际项目中，发现最后都面目全非了。

所以，复用的工程成本很高，在使用的时候需要权衡，除了最常用了基础控件，其他的不要刻意追求。

2. 组件化应当做到什么程度？一个软件产品中，如果把核心稳定的部分视为资产，灵活可变的部分视为耗材，我们如何对待资产？如何对待耗材？

对待资产，我们一般会比较重视，会有长远的规划，优雅的实现，持续的维护，细致的测试，详尽的文档等等，但是对于耗材，基本上会视为一次性的东西，不会有这么严谨的过程。

组件属于资产还是耗材？模板呢？

按照上面的分类，组件明显属于资产，而模板一般属于耗材。

在有些框架中，模板的使用度较低，但是常见的包含双向绑定的框架中，都有很大比重的模板。有些模板是嵌入到组件内部的，有些则是独立存在的，比如Angular中，可以使用ng-include动态包含一个模板，这个模板就是独立的了。

大部分Web应用中，资产多一些，还是耗材多一些？

大部分Web系统的前端部分，其实都是耗材比资产多，人们选用Web相关技术的一个典型心理就是容易写，而且相对随意一些。

大部分Web应用都适合“全”组件化吗？

这个问题要从几个方面回答：

• 成本。从技术角度，任何系统都是可以不计成本的，如果资源无限充足，我们可以把每个东西都实现得非常完美，但现实世界不是这样的，每个东西都会有开发时间之类的限制，这就迫使我们只能对重要性较高，可复用性较高的东西多花时间，其他东西少花时间。
• 实现难度。组件化方案是需要有规划能力的，不但需要全局的规划能力，还需要各个局部的规划能力，这其实是比较高的需求了。
• 集成难度。很多时候，我们做一个东西，并不是就只有它自己，还会有跟其他系统的集成，比如说“我的淘宝”PC版，它现在的版本是用React实现的，但仍然需要跟其他东西集成，比如公共头尾，购物车之类，而这些东西是需要兼顾老系统，所以可能就会集成得比较别扭。一切组件化框架，如果要跟其他异构系统作集成，基本上都不可能优雅。