1 .开头说一下为什么要写这篇文章。 总有一天，大家会相信前端摩尔定律。 “每18个月前端难度增加一倍”。 我不完全承认这个数字的可靠性，但这句话的本意还是非常肯定的。
是的，前端越来越简单了，但越来越复杂了。 通过在Github的starter上构建框架，整合所有家庭成员的水桶，覆盖单元测试和功能测试、部署和发布，以及开发时使用的UI库，您将无法编写任何行css。 但是如此复杂的框架和库层出不穷，还没来得及学习官方网站的doc，就有了新的替代品。 冷静下来学习源代码，练习原理，当然跟不上脚步硬搬砖头自然会有点累。
尖端的迅速发展使尖端看起来很简单，但很难想深入。 顺便说一下，去年6月末发布了ES8。 没错，你没错。 我不觉得不能学习(开玩笑，其实什么都没有更新。 已经没有ES5-ES6那样的跨度了)。
所以，我认为最近使用的框架多了一点，dbwb必须沉淀和沉淀。 为什么要写组件化思想呢？ 我认为这是前端发展不可缺少的设计思想，所以现在一些大流行框架也非常好地实现了React、Vue等组件化。 由于React以前非常常用，所以这次我们决定以Vue为基础，思考前端模块化、组件化、可维护化的设计。
2 .组件化并不是前端特有的，其他语言和桌面程序等也有组件化的先例。 准确地说，只要有UI层的展示，就一定有可以组件化的地方。 简而言之，组件将一种UI样式及其相应功能视为独立的整体，具有相同的功能和样式并由此进行复用，而不管它整体位于何处。 可见组件化设计是为了提高复用性、灵活性，提高系统设计，提高开发效率。
3 .组件化的进展如果对JS的理解还停留在jQuery上，请跳过此语句，因为jQuery本身就是一个非常好的库。 当时，大多数前端开发应该是充分的流程表达式开发，可以操作DOM、启动ajax请求、更新数据和局部更新页面。 这样的动作会反复进行。 同一项目可能会重复同样的过程。 实际上，jQuery本身也有自己的模块化设计，在某些情况下，它可能会使用很好的库(如jQuery UI )来减少工作量，但请注意，这里只考虑模块化。
频繁操作DOM，流程式的开发方式确实不太好。 此时，MVC等MV*开始流行。 前端开始学习后端思想，开始谈论业务逻辑、UI和功能。 可以按文件划分，结构清晰，设计明确，开发也很好。 此外，还有更好的MVVM框架，其出现使前端操作更加简单，为前端UI赋予了真正的意义。 你看到的UI应该对应于相应的ViewModel，也就是说，你看到的view是真实的数据，实现了双向绑定。 如果UI发生变化，则UI所对应的数据也发生变化，反之亦然。 这确实很有用，但是大多数MVVM框架不是组件化的，或者不是很好的组件化。 MVVM最大的问题包括：
1 .执行效率。 当数据发生更改时，绑定到下面所有监视数据的UI通常会更新，效率很低。 频繁操作很可能会调谐数十万次(可能层次太深或监视数据更改太多)。
由于MVVM通常需要严格的ViewModel范围，因此大多数情况下不支持多次绑定，或者只允许绑定一个根节点进行顶级DOM渲染，这给组件化带来了困难
而且在此基础上，React和Vue的相似之处在于，一些新的前端框架开始通过“取其精华，去其糟粕”来大力推进前端组件化的开发方式
但是，从框架本身来说，React和Vue完全不同。 前者是单向数据流管理设计的先驱。 如果允许我进行不恰当的比较，我认为React Redux将MVC推向了极限。 (action-request，reducer-controller ) ) 后者是后起之秀，引入了React数据流管理方式(Vue本身也可以用React这样的方式开发，只是难度大，不是Vue )的设计理念，引入了MVVM的双向绑定和数据监控(这应该是Vue的核心
PS1: 并非讨论孰好孰坏，两大框架我都很喜欢，因为都非常好的实现了组件化。
PS2: 上面有提到模块化，个人觉得如果更广义的来讲，模块化和组件化并不在一个维度上，模块化往往是代码的设计和项目结构的设计；但很多时候在狭义的场景中，比如一个很通用的功能，也完全能够将其组件化或模块化，这两者此时十分相似，最大的区别就是组件必定是模块化的，并且往往需要实例化，也应当赋有生命周期，而模块化往往是直接引用。
4 .如何实现零部件化，我以搜房网为例，进行demo分析。 随手截图如下：
4.1页面布局分析
大致来看，可以分为顶级搜索、中间内容展示。 中间内容分为部分1、2、3三种类型。 由于篇幅问题，本文只分析部件1、2、3
> 每一个part中又可以分为header(title + link)和content(每个part不一样) 4.2初步开发如果没有经过任何设计，也许会出现下面的代码：
<template> <div id="app"> <div class="nav-search">...</div> <div class="panel"> <div class="part1 left"> <div> <span>万科城润园楼盘动态</span> <a rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" href="">更多动态>></a> </div> <div>这里是每个part里面的具体内容</div> </div> <div class="part2 right"> <div> <span>楼盘故事</span> <a rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" href="">更多>></a> </div> <div>这里是每个part里面的具体内容</div> </div> <div class="part3"> <div> <span>万科城润园户型</span> <a rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" href="">二居(1)</a> <a rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" href="">三居(4)</a> <a rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" href="">四居(3)</a> <a rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" rel="external nofollow" href="">更多>></a> </div> <div>这里是每个part里面的具体内容</div> </div> </div> </div></template>其中我省略了大部分的细节实现，实际代码量应该是这里的数倍。
这段代码有几个问题：
1.part1，2，3的结构很类似，有些许重复
2.实际的代码量将会很多，很难快速定位问题，维护难度较大
4.3化繁为简首先我们可以将part1，2，3进行分离，这样就独立出来三个文件，那么结构上将会非常清晰
<template> <div id="app"> <div class="nav-search">...</div> <div class="panel"> <part1 /> <part2 /> <part3 /> </div></template>这有些类似将一个大函数逐步拆解成几部分的过程，不难想象part1，2，3中的代码，必然是适用性很差，确切的说只有这里能够引用。(但我看过很多项目的代码，就是这么干的，认为自己做了组件化，抽象还不错(@_@))
4.4组件抽象仔细观察part1，2，3，正如我上面所说，它们其实是很相似的：都具有相同的外层border并附有shadow，都具有抬头和显示更多，各自内容部分暂不细说的话，这三个完全就是一模一样。
如此，我们将具有高度相似的业务数据进行抽离，实现组件的抽象。
part.vue
<template> <div class="part"> <div class="hearder"> <span>{{ title }}</span> <a :rel="external nofollow" href="linkForMore">{{ showMore || '更多>>' }}</a> </div> <slot name="content" /> </div></template>我们将part内可以抽象的数据都做成了props，包括利用slot去做模版，同时showMore || '更多>>'也考虑到了part1的link名字和其他几个part不一致的情况。
这样一来app.vue就更加清晰化
<template> <div id="app"> <div class="nav-search">...</div> <div class="panel"> <part title="万科城润园楼盘动态" linkForMore="#1" showMore="更多动态>>" > <div slot="content">这里是part1里面的具体内容</div> </part> <part title="楼盘故事" linkForMore="#2" > <div slot="content">这里是part2里面的具体内容</div> </part> <part title="万科城润园户型" linkForMore="#3" > <div slot="content">这里是part3里面的具体内容</div> </part> </div></template>这里有几点需要说明一下：
1.三个part中部分UI差异应该在哪里定义？比如三个part的宽度都不一样，并且part1和part2可能要需要进行浮动。
必须要记住，这种差异并不是组件本身的，<part />的设计本身应该是无浮动并且宽度占100%的，至于占谁的100%，那就取决于谁引用它，至于向左还是向右浮动，同样也取决于引用它的container需要自己去定义，在上面的代码中，app.vue就应该是<part />的container，app想要的是一个左浮动且宽度为80%的part（part1），右浮动且宽度为20%的part（part2）和一个宽度为100%的part（part3），但它们都是part，所以应该由app来设置这些差异。
记住这一点，将给你的抽象和扩展但来事半功倍的效果。
2.三个part中的数据差异应该在哪里定义？比如part3中，其他的part只有一个类似更多>>的link，但是它却有多个(一居，二居...)。
这里我推荐将这种差异体现在组件内部，设计方法也很多：
比如可以将link数组化为links；
比如可以将更多>>看作是一个default的link，而多余的部分则是用户自定义的特殊link，这两者合并组成了links。用户自定义的默认是没有的，需要引用组件时进行传入。
总之，只要有数据差异化，就应该结合组件本身和业务上下文将差异合理的消除在内部。
3.注意组件内数据的命名方式一个通用的，可扩展性高的组件，必然是有非常合理的命名的，比如观察一些组件库的命名，总会出现类似list,data,content,name,key,callback,className等名词，绝对不会出现我们系统中的类似iterationList, projectName等业务名词，这些名词和任一产品和应用都无关，它与自身抽象的组件有关，只表明组件内部的数据含义，偶尔也会代表其结构，所以只有这样，才能让用户通用。
我们在组件化时，也需要遵循这种设计原则，但库往往是想让广大开发者通用，而我们可以降低scope，做到在整个app内通用即可。所以从这个角度来说，好的组件化必然有好的BA和UX，这是大实话
5.写在最后你也许会认为这样抽象没有太大的必要性，毕竟它只是一段静态UI（pure component），但任何的设计都是基于一定的复杂度才衍生出来的，其实大部分情况下这种设计都是需要将功能逻辑代码也纳入其中的，并不光只是UI（如antd, element-ui等），我这里举的例子也相对比较简单，并不想有太多的代码。
个人认为在一个大型前端项目中，这种组件化的抽象设计是很重要的，不仅增加了复用性提高了工作效率，从某种程度上来说也反应了程序员对业务和产品设计的理解，一旦有问题或者需要功能扩展时，你就会发现之前的设计是多么的make sense（毕竟需求总是在变哪）。