看到题目，个别会有两种反馈：
「哇～好高大上啊！」
「嗯，这个话题真大……」
——的确如此。
深情前戏
我不生吞活剥那个什么百科来说啥是「面向组件」和为啥这么做，而是从工作现状以及本人思考的角度来论述，并试着拟出一个解决方案。
前端眼里的「组件」
对于前端开发人员来说，「组件」通常就是指页面上的 UI 组件，次要包含外观和交互。一个合格的组件应该是可复用、可定制、松耦合的，它可能代表一个事物，能够实现一个动作。
组件能够很简略，也能够很简单。依照复杂程度从小到大排的话，能够分为几类：
- 根底组件；
- 复合组件；
- 页面；
- 利用。
对，不必揉眼睛，你没有看错！
站在更高的角度去看，「页面」和「利用」也是一种「组件」，只不过它们更为简单。在这里我想要说的不是它们，而是「根底组件」和「复合组件」。
其中，根底组件具备简略的外观和根底的性能，而复合组件则是依据具体场景所进行的根底组件的组合和封装。
为啥要「面向组件」
在从事一段时间的前端开发之后，就会发现：
「一个零碎里的页面性能怎么都差不多？」
「每个网站根本都一个模子里刻进去的！」
——说得没错！
你在 CTRL + C 并 CTRL + V，改掉雷同中的不同之后，保留文件并刷新页面，点这点那看看成果——「我靠！这俩页面的交互一毛一样，怎么在那个页面好好的，到这里就不好使了？！」
1……2……3……个小时过来了，这该死的小强到底是从哪里溜进来的一点儿脉络也没有……心里窝火地始终在「MMP」，一不小心说漏了嘴——「妈卖批的！！！」
兄弟，淡定！
呈现这种问题，是因为没有面向组件开发。那些你所感觉的「类似」的局部，就能够提取进去造成组件，以备再次出现相似场景时应用。你以往所依赖的「CTRL + C / V 大法」，讲道理，是下下策中的下下策。
等组件积攒得多了，页面就不再是本人苦思冥想一行一行代码挤出来的，而是顺手从现成的库中拿来一个一个组件拼出来的。如此一来，不仅页面性能更加稳固，前端开发也能脱离干燥而变得更加乏味，辞别那一整天大部分工夫在摁臭虫的鬼日子——
后端：「什么时候能够联调？」
前端：「页面早就弄好了，接口呢？」
后端：「……」
「面向组件」是啥啊
换个词，「组件化」，兴许更为相熟。但，所以，到底是指什么呢？
对于抽象概念的含意，每个人都会有本人的了解，正所谓「一千个读者心中有一千个哈姆雷特」。有人会说：
就是把相干的 HTML、CSS、JS 和图片等文件放到同一个文件夹里吧？
——没啥故障。
在进行面向组件开发时，的确会将同一个组件的相干文件放在一个文件夹中，然而，这并不是外围。重要的是，可能将一个简单的货色恰到好处地拆分成更小且独立的，高内聚低耦合，让他人不用理解其外部运作原理拿来就用——这是思维，也是能力。
进入正题
「面向组件」开发，或者说「组件化」，由来已久，并不陈腐。这个话题在前端圈儿也炒了很多年了，这个框架那个库的层出不穷，为什么我当初还要再拿进去嚼一遍呢？
理由很简略：
- 在他人那不成问题的，在我这可能很是问题；
- 对他人很管用的工具，对我可能并不太实用。
他人爽的姿态我不爽
要进行面向组件开发，前提是得有可行的技术计划，依我看，须要必备几点：
- 组件的款式和交互不会意外地被外界烦扰——对外隔离；
- 一个组件相干的资源要在我用到时再给我——按需加载；
- 让前端技术不那么强的后端开发也能够用——门槛低。
红极一时的充分发挥 jQuery 专长的两个宝儿，jQuery UI 和 Bootstrap 提供了很多 UI 组件，对后端开发人员也很敌对，看起来符合要求。但从它们组件的实现形式以及资源加载模式来看——
jQuery UIBootstrap
当初的前端圈儿，一提到「组件」，大多数人的兴奋点都在 React、Vue、Angular 等 MV* 框架上。它们是很不错，不仅满足了「对外隔离」和「按需加载」，还大大地晋升了前端开发的效率，能大红大紫成这样自有其情理。
我司的业务是 to B 的，因而前端开发场景很「明确」，根本能够简略粗犷地了解为：「前台」就是挪动端，「后盾」就是桌面端。
前台开发用的是基于 React 和 Ant Design Mobile 二次开发的框架。It works well，可能 hold 住以后的需要。然而，后盾开发就不一样了。
咱们后盾的需要很多，比前台多，并且源源不断地减速增长；咱们后端的人员很多，比前端多，并且不成比例地继续加人。这就导致了一些问题：
- 每条业务线的前、后端开发人员比例均匀为 1:4；
- 一个前端人员可能会去反对一条业务线的多个我的项目；
- 一个前端人员可能会去反对多条业务线。
——人不够用！
该如何去解决呢？从公司的角度登程，必定是要降低成本——不靠招更多的人，而是靠改良办法最大化利用已有资源——让前端人员可能写更多页面，让后端人员也能写页面。
为了达到上述目标，我在 jQuery 和 Bootstrap 的根底上封装了一个用于后盾的框架。
尽管在写 JS 时曾经节俭很多工夫，也有几个后盾零碎是由后端人员独立开发的，但还是要写一堆 HTML 代码。就连前端人员都会感觉有点心烦，更别说后端人员望而生畏了。
在应用 React 组件时能够少写不少 HTML 标签，可是，但可是，后端开发人员会去写吗？他们会想写？！
综上所述，MV* 类框架并不能解决我司后盾现阶段所存在的问题——
ReactVueAngular
有人不满了：
你这也不行，那也不行，那还有啥了？！
——大大的有！
大家爽的姿态才正确
有那么一个被各种 MV* 框架的光芒所覆盖的，尽管有那么点缺陷但却很有实力且颇具后劲的技术——是的，就是 Web Components！光从名字来看，不难想象它正是为了解决前端组件的问题而呈现的。
Web Components 由能够彼此离开应用也可能协同工作的四个局部组成：
- Custom Elements——定义新的 HTML 元素；
- Shadow DOM——隔离 DOM 和款式；
- HTML Imports——申明要引入的 HTML 文档；
- HTML Templates——定义可复用的 HTML 片段。
因为是 W3C 的亲儿子，使用者能够像对其余如 <div>、<p> 一样看待由 Web Components 封装的组件——齐全关照了前端技术不娴熟的后端开发大大们。
被你说得那么神，我咋就没听说过呢？？？
——问得很好。
既然是 W3C 亲儿子，从出世到被世间，尤其是被那些「有权有势」的所认可须要工夫——它进去多年仍未成为举荐规范，兼容性不太现实。
能够说，兼容性和不稳定性成了推广 Web Components 的致命伤。
然而，并不必感觉过于败兴。
曾经有 polyfill 帮咱们填了一些坑，并且还有几个简化开发的库，如：Polymer、X-Tag 和 Skate 等。再加上，我司的后盾是对内的，简直只需思考 Chrome 类浏览器，兼容性缺点根本能够忽视。
这样一来，开发一套基于 Web Components 的组件，是不是既让前端人员爽了，又让写页面的后端人员爽了呢？
心里美滋滋〜(*´艸`)
低潮来了
当初看来，前端团队的面向组件开发的技术计划仿佛曾经确定了：
- 挪动端用 React 和 Ant Design Mobile；
- 桌面端用 jQuery、Bootstrap 和 Web Components。
如果认为这样就好了，那真是 think too much！
除了啪啪啪，什么都要快！
随着公司业务的倒退，曾经将触角伸向了正一直发力的微信小程序。尽管目前在这方面的业务很少，但我置信相干需要会接踵而至。
家喻户晓，微信小程序的开发自成体系，对于咱们前端开发人员来说又多了一个货色要去学……不过，作为一名前端工程师，早就习惯了这比女人的情绪还变幻莫测的前端技术。
略微往远点看，如果公司的业务须要，可能还会要做进去没多久的支付宝小程序。没准将来又呈现了别的什么小程序，或者其余具备组件个性的新的什么轮子。
为了反对公司的业务，每进去一个新的货色，前端人员就不得不去学怎么去用并且用好它。从团队治理、团队合作以及开发效率等方面来看，会产生一些重大的问题：
- 得每个人都把握所用到的库 / 框架能力任意分配任务；
- 技术栈芜杂而不便于进行培训和代码品质治理；
- 抽取积淀组件库将要变得异样艰巨。
这些问题在疾速倒退的业务的催化下，就会导致：
- 开发工夫太少啊太少——加班！加班！！加班！！！
- 前端人员不够啊不够——加班！加班！！加班！！！
要是加班还解决不了怎么办？那就我的项目延期呗。
可我的项目延期会耽搁公司的业务啊！那就……
想个新姿态
为了躲避以上问题，为了以不变应万变，为了让反对业务的前端开发童鞋可能忽视运行环境而有始终如一的便捷开发体验，我试着想了一个解决方案——通用组件编写标准。
所谓的「通用组件编写标准」次要蕴含两局部：组件定义和目录构造。
组件定义应用 ES6+ 语法，采纳类的形式，要兼顾组件的属性映射、数据绑定、事件处理、生命周期等个性。类的各成员的设计参考现有风行库 / 框架，但不同于它们。
目录构造遵循前端开发的「关注点拆散」准则，一个目录代表一个组件，一个 JS 文件就是一个组件定义。组件的款式用 Sass 来写。
通用组件编写标准解决的是开发阶段的问题，是反对业务的前端童鞋所要重点关注的，接下来的事件就交给构建工具去实现。
贤者工夫
正如结尾所说，「面向组件」开发是一件很高大上、很大的话题，想搞出一套「Write once, Run anywhere」的组件开发计划更是听起来天方夜谭。
我曾经做好了被各种泼冷水的心理准备，兴许在实现的路线上困难重重、踩坑有数，到最初被证实这的确是胡思乱想；但为了能让公司业务的倒退不受前端开发的妨碍，让团队中的小伙伴们缩小加班次数，对于团队留下更多美妙的记忆，不会放弃前端开发这条不归路，我愿去一试！！！
要发车了，没工夫做更多解释了！
本文首发于欧雷流：https://ourai.ws/posts/compon…