单页应用开发总结

zzbo 发布于2019-08-20 17:01 / 1317人阅读

摘要：本文想通过自己这一年的单页应用开发经验，来对的开发做一个总结。但是要知道，现如今页面都比较复杂，一般的单页应用都需要一个可靠的数据流去处理，否则在日后维护方面会难度巨大。

本文想通过自己这一年的单页应用开发经验，来对SPA的开发做一个总结。

页面开发模式

通常我们在开发页面时，都会拿到一份设计图，假设我们拿到一份这样的设计图

对于页面的开发，我总是遵循自上而下的设计模式去开发。在这里首先会把页面分为两部分，头部导航，和内容主体。内容主体又分为两部分左侧关注信息以及右侧的动态列表。如果按照这样分，我们的组件编写会像如下这样

这样写其实没什么问题，把所有的细节全部隐藏在组件内部，每个组件只要处理好自己就OK。但是要知道，现如今页面都比较复杂，一般的单页应用都需要一个可靠的数据流去处理，否则在日后维护方面会难度巨大。这里假设我们使用了redux，在redux中，我们的数据都是从顶层往下传，一般以route页面为维度，去做connect，然后route页面将所需的store以及action以props的形式分发。那就相当于，整个页面只有route组件是智能组件，其他组件尽可能写成木偶组件。如果按照这样的开发模式去开发左侧关注列表组件，应该是这样的

//BodyLeft

而list组件应该可能是这样的

//List

  {data.map(item=>(
    {item.name}
  ))}

这时如果route页面想传递什么信息给左侧列表，每次都要层层传递，少了一层，多了可能会有两三层，这样会写很多没用的信息，并且很不利于日后的维护，因为每次有更改，都要去改许多无用的地方（那些中间层）。
而我个人更倾向一种扁平化的组件设计风格。
还是原来的页面，如果采用扁平化的设计模式，设计出来的组件结构是这样的

//ps：组件命名随便取的

首先最外层的布局是可以复用的。这也就意味着如果之后还有页面是这样，上下布局，下面又是左右布局的时候，可以拿来用。其次是数据的传递不需要像之前那样层层传递，可以直接传给想要的组件。

有人说route页面为什么不能这样写

...

也就是说把之前的那些组件换成div不就好了。但是在组件设计哲学里，通常在connect的组件，也就是智能组件里，是不处理与view有关的东西，智能组件只处理数据和逻辑。而于视图相关的东西全放在木偶组件去处理。好处是只要是逻辑处理，就会去找智能组件，而界面样式之类，就会去找木偶组件，思路清晰，更低耦合高内聚。

组件

很多人对组件的理解是复用。其实组件化开发还有一个好处就是模块化。模块化可以将一个复杂的问题划分为多个，简单的问题去处理。打个比方你的能力一次只能处理一个七十分的问题，现在来了一个八十分的问题，你一次性很难处理，经常需要写一写，停顿一下，思考一会，然后再写一写，直至完成；相反如果你采用模块化的方式去解决，直接将这个八十分的问题划分为四个二十分的问题，此时，你只需要先搭建一个架子，让这个四个二十分的模块加起来能等于八十分，接着再去处理每个二十分的问题就OK了。这其实也秉承了自上而下的设计风格。
我通常将组件分为四类

智能组件

木偶组件

容器组件

高阶组件

项目如果使用redux，智能组件通常是作为connect的那个组件，他只处理该组件下所有子组件的数据逻辑；而样式，真实的dom结构，由木偶组件来负责，他通常是stateless function，偶尔也有自己的state，但即使是state，也只处理与页面展示有关的逻辑；容器组件很简单，如果把一个页面比作一个人，容器组件就是人的头，身体，和四肢。将页面大致分类，通常的写法是这样的

//Body
{this.props.children}

ps：为什么容器组件不直接写成div上文说过了。

如果说前三类组件都在为页面服务，那么最后一个组件就是专门为组件服务的组件。高阶组件就像高阶函数一样，将被修饰的组件作为参数，同时也可以传入其他配置参数，最后返回一个被增强的组件，redux的connect就是一个高阶组件，通常写法是这样的：

//高阶组件
const Hoc = props => WrapComponent => {
  return class extends Component {
    render() {
      return ;
    }
  };
};
// 使用
class WrapComponent extends Component{
  render(){
    return 
  }
}
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，后期难以维护，这无疑是本末倒置的。写这篇总结也是对我最近写项目的一些反思，希望能有更多的人一起讨论，谢谢。

GPU云服务器云服务器单页应用单页应用cdn 单页应用程序应用技巧总结

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/83327.html

Vue.js SSR 内容总结

摘要：本文只是对官方文档和对官方的个人学习总结，说得不够完整的请见谅本文主要对以下几方面内容对的内容进行分析总结出现的原因的总体原理当中的数据预取在编写代码时候的限制的构建原理出现的原因单页应用有一个很大的缺点就是问题，搜索引擎目前只能对同步的进本文只是对Vue.js官方SSR文档和对官方hackernews demo的个人学习总结，说得不够完整的请见谅本文主要对以下几方面内容对Vue....

曹金海 2019-08-23 18:25 评论0 收藏0
在单页应用中，如何优雅的监听url的变化

摘要：单页应用的原理从早起的根据的变化，到根据的的变化，实现无刷新条件下的页面重新渲染。那么在单页应用中是如何监听的变化呢，本文将总结一下，如何在单页页面中优雅的监听的变化。在下几章中，重点介绍一下如何监听的改变。单页应用的原理从早起的根据url的hash变化，到根据H5的history的变化，实现无刷新条件下的页面重新渲染。那么在单页应用中是如何监听url的变化呢，本文将总结一下，...

leap_frog 2019-08-30 15:55 评论0 收藏0
在单页应用中，如何优雅的监听url的变化

摘要：单页应用的原理从早起的根据的变化，到根据的的变化，实现无刷新条件下的页面重新渲染。那么在单页应用中是如何监听的变化呢，本文将总结一下，如何在单页页面中优雅的监听的变化。在下几章中，重点介绍一下如何监听的改变。单页应用的原理从早起的根据url的hash变化，到根据H5的history的变化，实现无刷新条件下的页面重新渲染。那么在单页应用中是如何监听url的变化呢，本文将总结一下，...

姘存按 2019-08-02 14:00 评论0 收藏0
在单页应用中，如何优雅的监听url的变化

摘要：单页应用的原理从早起的根据的变化，到根据的的变化，实现无刷新条件下的页面重新渲染。那么在单页应用中是如何监听的变化呢，本文将总结一下，如何在单页页面中优雅的监听的变化。在下几章中，重点介绍一下如何监听的改变。单页应用的原理从早起的根据url的hash变化，到根据H5的history的变化，实现无刷新条件下的页面重新渲染。那么在单页应用中是如何监听url的变化呢，本文将总结一下，...

zhkai 2019-08-23 14:23 评论0 收藏0