• {{ item }}

无论实现的形式如何，其实基本不会影响太多写代码的逻辑，样式是目前前端工程化的难点和麻烦点，所以适合自己思维习惯即可。这里需要理解的是学习一门以组件为核心的技术，都能够先找到要素进行理解和学习，构造最简单的部分。

5.2 组件特性

虽然有了描述一个组件的基本要素，但是还远不足以让我们开发一个中大型应用，需要关注其他更多的点。这里提取组件基本都有的特性：

1. 注册组件

将组件拖到故事板

2. 组件接口（略）

别人家的代码能够修改组件的部分

3. 组件自属性

组件创建之初，就有的一些固定属性

4. 组件生命周期

组件存在到消失如何控制以及资源的整合

5. 组件 Zone

组件存在于什么空间下，或者说是上下文，很可能会影响到设计的接口和作用范围，比如 React.js 可用于写浏览器中的应用，React Native 可以用来写类似原生的 App，在设计上大多数能雷同，但是平台的特殊地方也许就会出现对应的代码措施）

这些主要就是拿来帮助去看一门不懂的技术的时候，只要是组件的范围，就先看看有没有这些东西的概念能不能联想帮助理解。

具体来看下代码是如何来落地这些模式的。

1.组件注册，其实注册就是让代码识别你写的组件

(1) 声明即定义，导入即注册

export SomeOneComponent {};
import {SomeOneComponent} from "SomeOneComponent";

(2) 直接了当的体现注册的模式

AppRegistry.registerComponent("ReactNativeApp", () => SomeComponent);

(3) 拥有模块来划分组件，以模块为单位启动组件

@NgModule({
    // 声明要用的组件
    declarations: [
        AppComponent,
        TabComponent,
        TableComponent
    ],
    // 导入需要的组件模块
    imports: [
        BrowserModule,
        HttpModule
    ],
    providers: [],
    // 启动组件, 每种平台的启动方式可能不一样
    bootstrap: [AppComponent]
})
export class AppModule { }

2.组件的自属性

比如 Button 组件，在平时场景下使用基本需要绑定一些自身标记的属性，这些属性能够认为是一个 Component Model 所应该拥有，下面用伪代码进行描述。

// 将用户的 touch, click 等行为都抽象成 pointer 的操作
~PointerOperateModel {
    selected: boolean;
    disabled: boolean;
    highlighted: boolean;
    active: boolean;
}

ButtonModel extends PointerOperateModel { }
LinkModel extends PointerOperateModel { }
TabModel extends PointerOperateModel { }
...

// 或者是具有对立的操作模型
~ToggleModel {
    on: boolean;
}

OnOffModel extends ToggleModel { }
SwitchModel extends ToggleModel { }
MenuModel extends ToggleModel { }

...

// 组件的使用
this.ref.attribute = value;
this.ref.attribute = !value;

这些操作如果需要更少的代码，也许能够这样：

~ObserverState {
    set: (value: T) => void;
    get: (value: T) => T;
    changed: () => void;
    cacheQueue: Map;
    private ___observe: Observe;
}

Model extends ObserverState { }

基本上组件的这些属性是遍布在我们整个代码开发过程中，所以是很重要的点。这里还有一个比较重要的思考，那就是表单的模型，这里不扩展开来，可以多带带立一篇文章分析。

3.组件的声明周期

与其说是生命周期，更多的是落地时候的代码钩子，因为我们要让组件与数据进行连接，也许需要在特定的时候去操作一份数据。在浏览器（宿主）中，要知道具体是否已经可用是一个关键的点，所以任何在这个平台的组件都会有这类周期，如果没有的话用的时候就会很蛋疼。

最简单的路线是：

mounted => update => destory

但是往往实际项目会至少加一个东西，那就是异常，所以就能够开分支了，但是更清晰的应该是平行的周期方式。

mounted => is error => update => destory

4.组件 Zone

组件在不同的 Zone 下可能会呈现不同的状态，这基本上是受外界影响的，然后自己做出反应。这里可以针对最基本的组件使用场景举例，但是这个 Zone 是一种泛化概念。

比如我们要开发一个弹框组件：Modal，先只考虑一个最基本需求：弹框的位置，这个弹框到底挂载到哪儿？

挂载到组件内部；

挂载到最近的容器节点下；

挂载到更上层的容器，以至于 DOM 基础节点。

每一种场景下的弹框，对于每种组件的方案影响是不同的：

组件内部，如果组件产生了 render，很可能受到影响；

挂载到最近的容器组件，看似问题不大，但是业务组件的拆、合是不定的，对于不定的需求很可能代码会改变，但是这种方案是不错的，不用写太远，当然在 React 16 有了新的方案；

挂载到更高的层级，这种方案适合项目对弹框需求依赖比较强的情况吧，因为受到的影响更小，弹框其实对于前端更强调的是一种渲染或者说是一种交互。

5.组件的递归特性

组件能够拥有递归是一个很重要的纵向扩展的特性，每一种库或者框架都会支持，就要看支持对于开发的自然度，比如：

// React
this.props.children

// Angular

基本上可以认为现在面向组件的开发是更加贴近追求的设计即实现的理想，因为这是面向对象方法论不容易具备的，组件是一种更高抽象的方法，一个组件也许会有对象分析的插入，但是对外的表现是组件，一切皆组件后经过积累，这将大大提升开发的效率。

经过前面的描述，知道了组件的概念和简单组件的编写方法，但是掌握了这些东西在实际项目中还是容易陷入蛋痛的地步，因为组件只是组成一个组件模块的基础单元，慢慢的开发代码的过程中，我们需要良好的去组织这些组件让我们的模块即实现效果的同时也拥有一定的鲁棒性和可扩展性。这里将组件的设计方法分为 2 个打点：

横向分类

纵向分层

其实这种思路是一直以来都有的，这里套用到平时自己的组件设计过程中，让它帮助我们更容易去设计组件。

这种设计的方法论是一个比较容易掌握和把握的，因为它的模型是一个二维的(x, y)两个方向去拆、合自己的组件。注意，这里基本上的代码操作单元是组件，因为这里我们要组装的目标是模块^0^感觉很好玩的样子，举例来描述一下。

比如我们现在来设计比较常用的下拉列表组件(DropDownList)，最简单的有如下做法：

class DropDownList {
    render() {
        return (
            

                

                    请选择
                
                
                {this.props.dataSource.map((itemData, index) => )}
                
            
        );
    }
}

现在自己玩的往上加点需求，现在我需要加一个列表前面都加一个统一的 icon, 首先我们要做的肯定是要有一个 Icon 的组件，这个设计也比较依赖场景，目前我们先设计下拉。现在就有2种方案：

在 DropDownList 组件里面加一个判断，动态加一个组件就行；

重新写一个组件叫 DropDownIconList。

第一种方案比较省事，但是其实写个 if...else... 算是一个逻辑分支的代码，以后万一要加一个 CheckBox 或者 Radio 组件在前面...

第二种方案看上去美好，但是容易出现代码变多的情况，这时候就需要再重新分析需求变化以及变化的趋势。

这时候按垂直和水平功能上，这里拆分 DropDownIconList 组件可以看成一个水平的划分，从垂直的情况来看，将下拉这一个行为做成一个组件叫 DropDown，最后就变成了下面的样子：

class DropDown  {
    render() {
        

            

                
请选择
            
            
{this.props.children}
        
    }
}

class DropDownList {
    render() {
        return (
            
                
                    {this.props.dataSource.map((itemData, index) => )}
                
            
        );
    }
}

class DropDownIconList {
    render() {
        return (
            
                
                    {this.props.dataSource.map((itemData, index) => )}
                
            
        );
    }
}

这样的缺点就是存在多个组件，也许会有冗余代码，优点就是以后增加类似组件，不会将代码的复杂度都加到一份代码中，比如我要再加一个下拉里面分页、加入选中的项、下拉内容分页、下拉的无限滚动等等，都是不用影响之前那份代码的扩展。

组件化的开发在结构上是一种分形架构的体现，是一个应用引向有序组件构成的过程。组件系统的复杂度可以理解成 f(x) = g(x) + u(x), g(x) 表示特有功能，u(x)表示功能的交集或者说有一定重合度的集合。组件弹性体现在 u(x) -> 0(趋近)的过程中，这个论点可参考：面向积木（BO）的方法论与分形架构

上面的过程中，有了组件、组件模块，既然有了基础的实体，那么他们或多或少会有沟通的需求（活的模块）。基本上现在主流的方案可以用下面的图来表示。

我们提取一下主要的元素：

Component 实体

Component 实体的集合：Container

Action

Action 的操作流

Service Or Store

状态同步中心

Observable Effect

如果要说单向数据流和双向绑定的体现基本可以理解成体现在虚线框选的位置，如果组件或者Store是一个观察的模型，那么方案实现后就很可能往双向绑定靠近。如果是手动党连接 ViewValue 和 ModelValue，按照一条流下来可以理解成单向流。虽然没有按定义完全约束，但是代码的落地上会形成这种模式，这块细讲也会是一个多带带的话题，等之后文章再介绍各种模式。

组件的关系能够体现在包含、组合、继承、依赖等方面，如果要更好的松耦合，一般就体现在配置上，配置就是一种自然的声明式，这是声明式的优势同时也是缺点。

以上是一些对组件的思考，码字好累，不一定很深入，但是希望能够帮助到刚踏入组件化前端开发的小伙伴~如果觉得有帮助请帮忙推荐，也可以阅读原文：小撸的博客