最近一直在看React的一些东西，其实很早前就想开始重拾前端，但是一直提不起兴趣再去看JavaScript，对CSS这种布局方式也不是很来感，说白了，就是懒吧😂。去年年底开始在公司app里开始尝试接入Weex，所以不得不把JavaScript再重新撸了一遍，顺带着把ES6的一些新特性也了解了一下，更好的函数调用方式，Class的引入，Promise的运用等等，其实最吸引我的还是在用了Weex之后，感受到了Component带来的UI复用，高效开发的快感。Weex是运用Vue.js来调用，渲染native控件，来达到one code, run everywhere。不管是Vue.js，还是React，最终都是朝着W3C WebComponent的标准走了（今年会发布的Vue 3.0在组件上的语法基本上跟React一样了）。这篇就来讲讲我对React Component的理解，还有怎么把这个标准也能在native上面做运用
iOS UI开发的痛点
对iOS开发来说，最常用的UI组件就是UICollectionView了，就是所谓的一个列表页，现在的app大部分页面都是由一个列表来呈现内容的。对iOS开发者来说，我们可以封装每个UICollectionViewCell，从而可以在每个页面的UICollectionView中能够复用，但是痛点是，这个复用仅仅是UI上的复用，在每写一个新的页面（UIViewController）的时候，还是需要新建一个UICollectionView，然后再把UICollectionView的DataSource和Delegate方法再实现一遍，把这些Cell再在这些方法里重新生成一遍，才能让列表展现出来。比方说我们首页列表底部有猜你喜欢的cell，个人中心页面底部也有猜你喜欢的cell，这两个页面，都需要在自己拥有的UICollectionView中注册这个猜你喜欢的cell，返回这个猜你喜欢cell的高度，设置这个cell的model并刷新数据，如果有Header或者Footer的话，还得重新设置这些Header跟Footer。所以新写一个列表页面，对iOS开发者来说，还是很麻烦。
使用Weex或者RN开发原生列表页
使用Weex开发列表页的时候，我们组内的小伙伴都觉得很爽，很高效，基本上几行代码就能绘制出一个列表页，举个RN和weex的例子
// React
render() {
const cells = this.state.items.map((item, index) => {
if (item.cellType === 'largeCell') {
return <LargeCell cellData={item.entity}></LargeCell>
} else if (item.cellType === 'mediumCell') {
return <MediumCell cellData={item.entity}></MediumCell>
} else if (item.cellType === 'smallCell') {
return <SmallCell cellData={item.entity}></SmallCell>
}
});
return(
<Waterfall>
{ cells }
</Waterfall>
);
}
// Vue
<template>
<waterfall>
<cell v-for="(item, index) in itemsArray" :key="index">
<div class="cell" v-if="item.cellType === 'largeCell'">
<LargeCell :cellData="item.entity"></LargeCell>
</div>
<div class="cell" v-if="item.cellType === 'mediumCell'">
<MediumCell :cellData="item.entity"></MediumCell>
</div>
<div class="cell" v-if="item.cellType === 'smallCell'">
<SmallCell :cellData="item.entity"></SmallCell>
</div>
</cell>
</waterfall>
</template>
const
waterfall对应的就是iOS中的UICollectionView，waterfall这个组件中有cell的子组件，这些cell的子组件可以是我们自己定义的不同类型样式的cell组件。LargeCell，MediumCell，SmallCell对应的就是原生中的我们自定义的UICollectionViewCell。这些Cell子组在任何waterfall组件下面都可以使用，在一个waterfall组件下面，我们只需要把我们把在这个列表中需要展示的cell放进来，通过props把数据传到cell组件中即可。这种方式对iOS开发者来说，真的是太舒服了。在觉得开发很爽的同时，我也在思考，既然这种Component的方式用起来很爽，那么能不能也运用到原生开发中呢？毕竟我们大部分的业务需求还是基于原生来开发的。
React的核心思想
- 先来解释下React中的React Element和React Component
- React Elements
这段JSX表达式返回的就是一个React Element，React element描述了用户将在屏幕上看到的那个UI，跟DOM elements不一样的是，React elements是一个单纯的对象，仅仅是对将要呈现到屏幕上的UI的一个描述，并不是真正渲染好的UI，创建一个React element开销是极其小的，渲染的事情是由背后的React DOM来处理的。上面的那段代码相当于：const element = <div id='login-button>Login</div>const element = React.createElement( 'div', {id: 'login-button'}, 'Login' ) 返回的React element对象相当于 => { type: 'div', props: { children: 'Login', id: 'login-button' } } - React Components
React中最核心的一个思想就是Component了，官方的解释是Component允许我们将UI拆分为独立可复用的代码片段，组件中可以包含多个其他组件，这样将组件一个个单独抽离出来，并最终再组合到一起，大大提高了代码的可读性（Readability）、可维护性（Maintainability）、可复用性（Reusability）和可测试性（Testability）。这也是 React 里用 Component 抽象所有 UI 的意义所在。
这段代码中Button就是一个React Component，这个component接受一个叫props的参数，返回描述UI的React element。class Button extends React.Component { render() { const element = <div id='login-button>{ this.props.title }</div> return ( <div> { element } </div> ) }
- React Elements
- 可以看出React Component接受props是一个对象，也就是所谓的一种数据结构，返回React Element也是一种对象，所谓的另外一种数据结构，所以我认为的React Component其实就是一个function，这个function的主要功能就是将一种数据结构（描述原始数据）转换成另外一种数据结构（描述UI）。React element仅仅是一个描述UI的对象，可以认为是一个中间状态，我们可以用最小的开销来创建或者销毁element对象。
- React的核心思想总结下来就是这样的一个流程
- 原始数据到UI数据的转化 props -> React Component -> React Element
- React Element的作用是将Component的创建跟描述状态分离，Component内部主要负责这个Component的构建，React Element主要用来做描述这个Component的状态
- 多个Component返回的多个Elements，这个流程是进行UI组合
- React Element并不是一个渲染结果，React DOM的作用是将UI的状态（即Element）和UI的渲染分离，React DOM负责element的渲染
- 最后一个流程就是UI渲染了
- 上述这几个流程基本上代表了React的核心概念
怎么在iOS中运用React Component概念
说了这么多，其实iOS中缺少的就是这个Component概念，iOS原生的流程是原始数据到UI布局，再到UI绘制。复用的只是UI绘制结果的那个view（e.g. UICollectionViewCell）
-
在使用UICollectionView的时候，我们的数据都是通过DataSource方法返回给UICollectionView，UICollectionView拿到这些数据之后，就直接去绘制UICollectionViewCell了。所以每个列表页都得重新建一个UICollectionView，再引入自定义的UICollectionViewCell来绘制列表，所有的DataSource跟Delegate方法都得走一遍。所以我在想，我们可以按照React的那种方式来绘制列表么？将一个个UI控件抽象成一个个组件，再将这些组件组合到一起，绘制出最后的页面，React或者Weex的绘制列表其实就是waterfall这个列表component里面按照列表顺序插入自定义的cell component（组合）。那么我们其实可以在iOS中也可以有这个waterfall的component，这个component支持一个
insertChildComponent:的方法，这个方法里就是插入自定义的CellComponent到waterfall这个组件中，并通过传入props来创建这个component。所以我就先定义了一个组件的基类BaseComponent@protocol ComponentProtocol <NSObject> /** * 绘制组件 * * @param view 展示该组件的view */ - (void)drawComponentInView:(UIView *)view withProps:(id)props; /** * 组件的尺寸 * * @param props 该component的数据model * @return 该组件的size */ + (CGSize)componentSize:(id)props; @end @interface BaseComponent : NSObject <ComponentProtocol> - (instancetype)initWithProps:(id)props; @property (nonatomic, strong, readonly) id props;所有的Component的创建都是通过传入props参数，来返回一个组件实例，每个Component还遵守一个
ComponentProtocol的协议，协议里两个方法：-
- (void)drawComponentInView:(UIView *)view withProps:(id)props;每个component通过这个方法来进行native控件的绘制，参数中view是将会展示该组件的view，比方说WaterfallComponent中的该方法view为UIViewController的view，因为UIViewController的view会用来展示WaterfallComponent这个组件，'props'是该组件创建时传入的参数，这个参数用来告诉组件应该怎样绘制UI -
+ (CGSize)componentSize:(id)props;来描述组件的尺寸。
-
-
有了这个Component概念之后，我们原生的绘制流程就变成
- 创建Component，传入参数props
- Component内部执行创建代码，保存props
- 当页面需要绘制的时候（React中的render命令），component内部会执行
- (void)drawComponentInView:(UIView *)view withProps:(id)props;方法来描述并绘制UI
原生代码中想实现React element，其实不是一件简单的事情，因为原生没有类似JSX这种语言来生成一套只用来描述UI，并不绘制UI的中间状态的对象（可以做，比方说自己定义一套语法来描述UI），所以目前我的做法是在component内部，等到绘制命令来了之后，通过在
- (void)drawComponentInView:(UIView *)view withProps:(id)props方法中，调用原生自定义的UIKit控件，通过props来绘制该UIKit所以将通过封装component的方式，我们之前UIKit代表的UI组件转换成组件，把这些组件一个个单独抽离出来，再通过搭积木的方式，将各种组件一个个组合到一起，怎么绘制交给component内部去描述，而不是交给每个页面对应的UIViewController
Demo
Demo中，我会创建一个WaterfallComponent组件，还有多个CellComponent来绘制列表页，每个不一样列表页面(UIViewController)都可以创建一个WaterfallComponent组件，然后将不一样的CellComponent按照顺序插入到WaterfallComponent组件中，即可完成绘制列表，不需要每个页面再去处理UICollectionView的DataSource，Delegate方法。
WaterfallComponent内部会有一个UICollectionView，WaterfallComponent的insertChildComponent方法中，会创建一个dataController来管理数据源，并用来跟UICollectionView的DataSource方法进行交互从而绘制出列表页，最终UIViewController中绘制列表的方法如下：
self.waterfallComponent = [[WaterfallComponent alloc] initWithProps:nil];
for (NSDictionary *props in datas) {
if ([props[@"type"] isEqualToString:@"1"]) {
FirstCellComponent *cellComponent = [[FirstCellComponent alloc] initWithProps:props];
[self.waterfallComponent insertChildComponent:cellComponent];
} else if ([props[@"type"] isEqualToString:@"2"]) {
SecondCellComponent *cellComponent = [[SecondCellComponent alloc] initWithProps:props];
[self.waterfallComponent insertChildComponent:cellComponent];
}
}
[self.waterfallComponent drawComponentInView:self.view withProps:nil];
这样，每个我们自定义的Cell就可以以CellComponent的形式，被按照随意顺序插入到WaterfallComponent，从而做到了真正意义上的复用，Demo已上传到GitHub上，有兴趣的可以看看
总结
- React的核心思想是将组件一个个单独抽离出来，并最终再组合到一起，大大提高了代码的可读性、可维护性、可复用性和可测试性。这也是 React 里用 Component 抽象所有 UI 的意义所在。
- 原生开发中，使用Component的概念，用Component去抽象UIKit控件，也能达到同样的效果，这样也能统一每个开发使用UICollectionView时候的规范，也能统一对所有列表页的数据源做一些统一处理，比方说根据一个逻辑，统一在所有列表页，插入一个广告cell，这个逻辑完全可以在WaterfallComponent里统一处理。
思考
目前我们只用到了Component这个概念，其实React中，React Element的概念也是非常核心的，React Element隔离了UI描述跟UI绘制的逻辑，通过JSX来描述UI，并不去生成，绘制UI，这样我们能够以最小的代价来生成或者销毁React Elements，然后在交付给系统绘制elements里描述的UI，那么如果原生里也有这一套模板语言，那么我们就能真正做到在Component里，传入props，返回一个element描述UI，然后再交给系统去绘制，这样还能省去cell的创建，只创建CellComponent即可。其实我们可以通过定义一套语义去描述UI布局，然后通过解析这套语义，通过Core Text去做绘制，这一套还是值得我再去思考的。
