本文想通过自己这一年的单页应用开发经验，来对SPA的开发做一个总结。
页面开发模式
通常我们在开发页面时，都会拿到一份设计图，假设我们拿到一份这样的设计图
对于页面的开发，我总是遵循自上而下的设计模式去开发。在这里首先会把页面分为两部分，头部导航，和内容主体。内容主体又分为两部分左侧关注信息以及右侧的动态列表。如果按照这样分，我们的组件编写会像如下这样
<Container>
<Nav />
<Body>
<BodyLeft />
<BodyRight />
</Body>
</Container>
这样写其实没什么问题，把所有的细节全部隐藏在组件内部，每个组件只要处理好自己就OK。但是要知道，现如今页面都比较复杂，一般的单页应用都需要一个可靠的数据流去处理，否则在日后维护方面会难度巨大。这里假设我们使用了redux，在redux中，我们的数据都是从顶层往下传，一般以route页面为维度，去做connect，然后route页面将所需的store以及action以props的形式分发。那就相当于，整个页面只有route组件是智能组件，其他组件尽可能写成木偶组件。如果按照这样的开发模式去开发左侧关注列表组件，应该是这样的
//BodyLeft
<Container>
<TopNav />
<List />
</Container>
而list组件应该可能是这样的
//List
<Container>
{data.map(item=>(
<Item>{item.name}</Item>
))}
</Container>
这时如果route页面想传递什么信息给左侧列表，每次都要层层传递，少了一层，多了可能会有两三层，这样会写很多没用的信息，并且很不利于日后的维护，因为每次有更改，都要去改许多无用的地方（那些中间层）。
而我个人更倾向一种扁平化的组件设计风格。
还是原来的页面，如果采用扁平化的设计模式，设计出来的组件结构是这样的
//ps：组件命名随便取的
<Container>
<Nav>
<NavLeft />
<NavRight />
</Nav>
<Body>
<BodyLeft>
<LeftTop />
<LeftList />
</BodyLeft>
<BodyRight>
<ArticleList />
</BodyRight>
</Body>
</Container>
首先最外层的布局是可以复用的。这也就意味着如果之后还有页面是这样，上下布局，下面又是左右布局的时候，可以拿来用。其次是数据的传递不需要像之前那样层层传递，可以直接传给想要的组件。
有人说route页面为什么不能这样写
<div>
<Nav />
<div>
<div className="left">
<div className="leftTop">
...
</div>
<List />
</div>
<div className="right">
<ArticleList />
</div>
</div>
</div>
也就是说把之前的那些组件换成div不就好了。但是在组件设计哲学里，通常在connect的组件，也就是智能组件里，是不处理与view有关的东西，智能组件只处理数据和逻辑。而于视图相关的东西全放在木偶组件去处理。好处是只要是逻辑处理，就会去找智能组件，而界面样式之类，就会去找木偶组件，思路清晰，更低耦合高内聚。
组件
很多人对组件的理解是复用。其实组件化开发还有一个好处就是模块化。模块化可以将一个复杂的问题划分为多个，简单的问题去处理。打个比方你的能力一次只能处理一个七十分的问题，现在来了一个八十分的问题，你一次性很难处理，经常需要写一写，停顿一下，思考一会，然后再写一写，直至完成；相反如果你采用模块化的方式去解决，直接将这个八十分的问题划分为四个二十分的问题，此时，你只需要先搭建一个架子，让这个四个二十分的模块加起来能等于八十分，接着再去处理每个二十分的问题就OK了。这其实也秉承了自上而下的设计风格。
我通常将组件分为四类
- 智能组件
- 木偶组件
- 容器组件
- 高阶组件
项目如果使用redux，智能组件通常是作为connect的那个组件，他只处理该组件下所有子组件的数据逻辑；而样式，真实的dom结构，由木偶组件来负责，他通常是stateless function，偶尔也有自己的state，但即使是state，也只处理与页面展示有关的逻辑；容器组件很简单，如果把一个页面比作一个人，容器组件就是人的头，身体，和四肢。将页面大致分类，通常的写法是这样的
//Body
<div className="body">{this.props.children}</div>
ps：为什么容器组件不直接写成div上文说过了。
如果说前三类组件都在为页面服务，那么最后一个组件就是专门为组件服务的组件。高阶组件就像高阶函数一样，将被修饰的组件作为参数，同时也可以传入其他配置参数，最后返回一个被增强的组件，redux的connect就是一个高阶组件，通常写法是这样的：
//高阶组件
const Hoc = props => WrapComponent => {
return class extends Component {
render() {
return <WrapComponent {...props} />;
}
};
};
// 使用
class WrapComponent extends Component{
render(){
return <div />
}
}
export default Hoc()(WrapComponent)
redux数据流
在redux数据流管理里，行业里有很多最佳实践，我这里就当抛砖引玉。
我认为一般页面逻辑不是很复杂的项目，简单的使用redux redux-thunk redux-action就够了，如果需要处理的请求很复杂，为了避免回调地狱，可以使用redux-saga。通常我们在对数据从顶部往下分发的时候，需要以一个维度为基点来做connect，这个维度一般是route页面。对于router，现在也基本达成了共识，那就是router的数据状态也是redux数据的一种，它与view无关，因此使用react-redux-router将router与redux结合在一起是一个比较好的做法。
在redux里，有一个比较有争议的点是，关于页面的状态，是否要放在redux里。有人认为redux就应该只放数据，即后台的数据和部分前台自己存储的数据；但是我认为，我们页面在开发过程中，页面的展示逻辑通常与后台的数据是非常耦合的，可能一个按钮的状态，一个icon的颜色，都与后台的数据有关，那么如果强行拆分，就会变成对于一个流程，我们要先去redux里处理后台数据，处理好之后，再去智能组件里根据redux数据处理内部state（页面的状态），这样很麻烦，也很难维护。我自己的做法是，每一个流程，只对应一个action，这个action内部再去根据不同的参数去处理不同的数据，直至页面正常反应这个操作为止。
总结
总的来说，我们中很多人包括我自己，给view层赋予了太多的职能和责任，造成redux的价值没有发挥出来，view里跑着各种state，后期难以维护，这无疑是本末倒置的。写这篇总结也是对我最近写项目的一些反思，希望能有更多的人一起讨论，谢谢。
