组件化开发

作者: 文兴 | 来源:发表于2017-03-07 23:20 被阅读1462次

Android组件化和插件化开发
滚动栏的开发
Android 组件化开发实践
Android组件化和插件化开发
Vue组件化开发
Gradle实战——组件化的gradle build优化
Android组件化开发实践笔记
浅谈Android插件化
Vue 组件化开发
iOS端组件化架构开发与管理

介绍

组件化什么时候在软件工程领域提出已经无从考究了，这个概念很早就被提出，近年来随着前端开发的迅速发展和工程化转变，组件化开发的思想也得到了进一步的发展和实践。我也是在前端开发中使用到Vue这个框架，接触到了组件化开发的思想。那什么是组件化呢？其实对（大）前端工程师来说很好理解，用一句话概括就是，接受外部数据输入，暴露特定事件的UI+逻辑组成的单元。

对iOS工程师来说，系统提供的各种原生控件就是一种组件。例如一个输入框UITextField，它接受外部传入的初始值，接受用户输入，通过Delegate方式暴露出各种可以被关注的事件如textChange。我们可以在xib/Storyboard/代码中方便的引入，用一个一个组件单元，组成我们的用户界面，同时监听我们所需的事件。对安卓工程师，也是一样的开发体验，各种原生的控件都相当的强大和方便。同时，当原生控件不能满足我们的需求时，我们也可以很方便的使用继承对原生控件进行扩展，比如添加子控件、添加自定义事件等，对于我们来说，开发手机客户端和搭积木非常相似，我们只需要选择合适的积木，按照一定的规则堆好就行了。

组件化.jpg

上图就是一个组件化开发的例子，页面分为Nav、List两个大的组件，List组件下包含了ListHeader、ListBody、ListFooter三个子组件，ListBody有包含若干ListCell组件，逻辑结构就可以表示成如下

<app>
  <Nav></Nav>
  <List>
    <ListHeader></ListHeader>
    <ListBody>
      <ListCell></ListCell>
      <ListCell></ListCell>
      ...
    </ListBody>
    <ListFooter></ListFooter>
  </List>
</app>

相信有客户端开发经验的同学看到这种结构一定非常熟悉——这不就是iOS里的Xib，Android中的Xml布局文件嘛！其实组件化的思想早已深入到了客户端开发中

Web组件化发展

而对于web前端来说，世界可能就没有那么美好了，我们没有那么多强大的控件得以使用，很多基础性的、公共的组件，浏览器都没有提供给我们，留给我们的只有

简单的HTML标签
JS操作DOM的能力
CSS描述布局的功能。

在这种前提下，web前端初学者，包括我在初学的时候非常容易把代码写成意大利面条一样，所有的逻辑，比如ajax，更新DOM，更新数据等等都混杂在一起。这种写法在前端逻辑简单，界面层级不复杂的阶段是可行的，这种情况下引入框架反而会增加复杂性。

但随着前端的逐步发展以及前后端分离的开发趋势，现阶段的后端往往只提供数据，而不进行界面的构建和渲染，这样的好处就在于后端不必再给Web端提供专门的开发，而只需和手机客户端一样只提供接口和数据，让后端真正负责后台应该做的事情——处理业务逻辑、并发、分布式、缓存等等。这就要求前端处理更多的逻辑和渲染的工作，这是一个方面。另一方面，随着Google Mail Web版的横空出世，其与PC版几乎无异的流畅操作体验第一次把单页面应用（Single Page Application）带入人们的视线。于是，前端又有更多的事情要做了——路由、状态、本地存储、复杂动画。。。我们也把单页应用成为Web App，和iOS App、Android App等是平等的关系，开发的复杂程度也日趋接近。

所以，正如“人民日益增长的物质文化需求和落后的生产力之间的矛盾一样”，Web前端日益增长的需求和落后的开发标准和体验之间的矛盾，促使W3C标准的快速发展，从HTML5新增标签（也是组件的一种），到编程语言的发展ES5、ES6，以及Web的组件化标准Web Component`=，Web标准在一步一步走向完善，EmacScript更是加快到一年更新一个新版本。标准的制定是一回事，浏览器厂商的支持程度又是另一回事，目前的情况就是，虽然浏览器厂商积极的跟进Web标准，但距离主流浏览器完全实现还是有一定的距离，譬如组件化标准Web Components虽然很早提出但现在还没有定案。

正因为浏览器对组件化的支持程度不足，所以诞生了一系列的支持组件化的前端框架——Angular Directives、Ember Components、React Components、Vue.js Components等等，解决了前端开发的燃眉之急！

组件化的优势

下面以Vue组件为例，展示一下组件化开发的优势

1.可扩展

通过组件之间的合理组合搭配，可以构建出满足业务需求的新组件。
这一点很好理解，举个例子，我们有一个基础的树形组件tree和tree-node，现在来了一个业务需求，需要开发一个人员/机构的选择器，那么我们就可以很方便的基于我们的tree组件进行扩展，创建一个新的组件xx-selector

// xx-selector.vue
<template>
  <list :data="selectedData" /> // 已选列表
  </selected>
  <tree :data="treeData"  onSelect="onSelect">
    <template slot="treeNode">
      ...custom ui here
    </template>
  </tree> 
</template>

<script>
  import tree from ./tree.vue
  import list from ./list.vue
  module.exports = {
    data:{
      treeData:[],  
      selectedData:[]
    },
    created:function(){
      this.init()
    }
    methods:{
      onSelect:function(selected){
        this.selectedData = selected
        this.$emit('onSelectedChange',selected)
      },
      initData:function(){
        // ajax请求获取人员信息
      }
    }
  }
</script>

我们在逻辑代码部分加上诸如请求人员信息的接口、响应用户点击事件、响应全选/反选事件等等，这样就组成了一个功能完备的人员选择器组件。

2.可复用

刚才的xx-selector组件就复用到了基础的tree组件和tree-node组件。同样的道理，我们开发的xx-selector人员选择器组件，可以在任何有同样需求的地方重复使用，可以成为一个专属你们开发团队的一个基础组件，减少了开发量。

3.高内聚/低耦合

在我们使用xx-selector组件时，我们无需关心该组件内部的实现细节，我们只需要监听它暴露出来的onSelectedChanged(selectedList)事件，这个事件在选中人员发生改变时触发，把已选人员列表selectedList传递我们——我们使用选择器，所该关心就只是已选列表而已。

// my-app.vue
<template>
  <xx-selector onSelectedChanged="selectorChanged">
</template>
<script>
  import xx-selector from ./xx-selector.vue
  module.exports = {
    data:{ },
    methods:{
      selectorChanged:function(selected){
        // 处理已选
      }
    }
  }
</script>

这样就实现了