我是如何使用React+Redux构建大型应用的

背景

咱们团队有个项目因为开发时间较长，且是先后端杂糅的开发方式，维护成本很高，在线上暴露的问题不少。并且由于对接了公司一百多条产品线，天天都会接到大量的客诉和产品线反馈的问题。2017年11月份以产品为主导，从产品层面对流程进行从新设计，对该项目进行了先后端的重构。做为前端的负责人我用这篇文章分享下，整个过程从技术选型，开发，上线的一些经验。

技术选型的思考

首先咱们先看下下面咱们项目中的几个页面，来总结下一些他们的特色。

咱们的页面主要是须要用户填写的表单居多，在页面加载的时候不须要去请求获取和渲染大量的数据。并且一个页面须要显示的状态较多（好比上面的3张图，在项目中是一个组件）。还有一个最主要的业务需求，百度公司内部产品线较多，不一样的业务都有其独特的帐号标签，这些帐号除了会走一些通用流程还要走一些对应产品线特点的流程。

结合这些业务特点和以前有Nodejs和React的开发经验，我总体的一个技术选型是FIS3+Nodejs+React+Redux+React-Router。那么这些技术选型能带来什么呢？

1. 前端能够在浏览器端控制页面跳转的路由，增长了前端开发的灵活性；
2. 页面能够根据业务需求在服务选择模板引擎渲染或者是同构渲染；
3. 前端对错误码文案和页面文案作统一的管理，并且经过Nodejs来实现线下“热更新”他们，线上实时生效；
4. 有了Redux以后，作跨组件（多页面）的数据共享更加方便。减小无心义的网络请求。提升项目运行的稳定性和可用性。

这里简单的聊下工程化工具的选择。目前在业内最火的工程化工具就是Webpack了吧。除了看过文档以外，并无太多的实际应用经验。我一直认为使用工具就是来帮助开发者解决一些开发过程当中遇到的一些须要人为频繁去操做的无异议的工做。抛开Webpack咱们依旧能够手动去编译代码，手动部署，手动刷新页面来开发，使用工具只是让这一系列的流程可以连贯起来，下降开发成本。

在个人全部跟公司有关的项目中选择的都是FIS3，我也认为他足够的好用，能知足我各色各样的工程化需求。我并非排斥Webpack。我只是尚未找到一个理由，让我选择放弃如今使用的FIS3去使用Webpack。

新老框架机制的区别

这里简单介绍下，决定了技术选型以后，对于渲染页面渲染机制的一些区别。

以前旧项目使用PHP+Smarty的渲染模式，将页面在服务端渲染完成以后再统一吐给前端浏览器。而使用新的技术架构以后，咱们渲染页面的方式更加的灵活。能够选择在服务端渲染，能够彻底交给浏览器渲染，能够同构渲染。由于咱们的页面在首屏的时候不须要加载大量的数据，因此我仍是让大部分页面在浏览器端进行渲染。

还有一种区别就是以前全部来自用户的请求都会落到PHP的服务器上去。而新框架的请求都会落到前端的Nodejs服务器上去。因此前端工程师不只仅是写好页面和作好兼容性。对前端工程师的技术能力也会带来考验。

React带给前端的便利

前端控制路由渲染页面

前面谈的技术选型已经提到了使用React-Router来作页面路由控制。并且React-Router提供了异步加载组件的功能，这为咱们上线优化页面的异步加载提供了技术基础。

<Route path="/v4/appeal/fillname" component={FillName} />
{* 这里对某些组件作异步加载 *}
<Route
    path="/v4/appeal/selectuser"
    getComponent={selectUser()}
/>
        
function selectUser() {
    return (location, cb) => {
            require(['../accountselect/container/AccountSelect'], function (component) {
                cb(null, component);
            });
        };
    }

经过React-Router来作路由控制除了前端代码以外，服务端也许呀作些配置。否则咱们的页面在回退的时候就会出现问题（页面找不到路由）。其实就是在咱们一般说的action成面作下路由控制，由于我使用的是Nodejs，因此个人配置下面这样子的。

router.get('/fillname', router.action('index'));
router.get('/selectuser', router.action('index'));

事件

在前端事件由于开源协议的问题曾经短暂使用过Preact。React和Preact最大的区别就是对于一些事件的封装。这些形成了Preact相对于React体积小不少。
作移动端开发，前端常常会面临的一个问题就是click事件 300ms 延时的问题。在React中提供的onClick事件一样也会出现这样的问题。若是若是咱们想要在点击一个按钮以后，在其它地方当即出现反馈，最好就是使用onTouchEnd事件，或者就是使用开源的Npm包react-fastclick能很好的解决click事件 300ms延时的问题。

使用的方法就是在咱们代码的入口地方，声明如下语句，他默认会改变react的onClick事件的行为

import initReactFastclick from 'react-fastclick';

initReactFastclick();

组件的设计

在使用React的时候可能都会面临的问题，个人组件应该是无状态的仍是有状态的。个人组件状态怎么共享。何时我应该使用Redux来管理组件的状态。刚开始接触react都会有这样的疑问吧。

一种比较极端的作法就是，无论状态需不须要共享，组件的全部状态都试用Redux来管理。这样的作法就是咱们须要写大量的Action。若是是一两个页面还好，若是是十几个页面，真的写action是能把人写崩溃的。

那么最佳实践是什么呢？看下图

当咱们要写一个组件的时候，首先想下这个组件是否是须要与其它组件共享它自己的状态。若是须要咱们应该把它当作有状态的组件来设计，并且共享的状态使用Redux来管理。若是简单的就是无状态组件或者是这个组件自己的状态改变不会影响其它的组件，就能够将组件设计为无状态组件（虽然叫无状态组件，其实组件自己的状态也是可使用this.state来管理的）。

组件的复用关系

React的一大热点就是组件化的开发思想。小到页面上的一个按钮都是能够设计成一个组件。既然是组件咱们首先就应该考虑这个组件怎么被其它组件复用。

举个简单的例子，在整个项目中都会用到的弹窗组件：

class AlertForm extends Component {
    constructor(props) {
        super(props);

        this.state = {
            showlayout: false,  // false 以tip的方式提示错误， true以弹层的方式提示错误
            btnlist: false,
            formbtn: false
        };
    }

    componentWillReceiveProps(nextProps) {
        
    }

    handleHideLayout = () => {
    }

    handleMobile = () => {
    }

    handleChangeCheck = () => {
        history.go(-1);
    }

    render() {

        return (
            <div className="component-alertform" style={this.state.showlayout ? {display: 'block'} : {display: 'none'}}>
                
            </div>
        );
    }
}

export default AlertForm;

咱们将这种可能在其余页面都用的组件单独抽象成出来，在须要用的地方import。

import AlertForm from '../../components/AlertForm';

<AlertForm
    errno={errno}
    stateObj={fillAppealName}
    actions={actions}
/>

开发环境和生产环境打包优化

完成项目以后确定要作的一项工做就是上下前的优化，上线前我作的工做主要以下：

前面已经谈到错对于大多数用户来讲都只是会走一些普通流程。有些具备产品线特点的用户会走一些特殊流程。因此在上线前确定要拆包，和作组件的异步加载。具体的前面已经提到过了。在打包的时候对这些页面的js须要使用打包工具作单独的处理。

其实除了这些须要异步加载的页面以外还会存在一些其余本身编写的lib库（本身编写的小函数）。还有好比全国省市地区对应关系，电话区号对应关系。由于这些函数或者是地区关系映射图在上线之后基本上都是不会再变化的，因此与业务的js分开打包。

咱们的打包的配置文件以下：

运维

前面已经谈到使用Nodejs作中间层，作路由控制和服务端渲染。下面的这张图是我写这篇文章的时候截取的额以上服务实时状态图。能够发现，整个应用对于内存、磁盘IO利用率仍是很正常的，对于CPU的利用率有点儿高，这也是后续须要优化的地方。

这里想要说的是，若是使用了Nodejs，使用了服务端渲染，对于前端工程师的我的素质要求会比较高，由于须要处理不少服务端的问题。前面也分享过一篇处理安全工单的问题，不只仅要面对服务端的问题，还有面对来自互联网安全的问题。

其它能力补充

使用Nodejs除了来作服务端渲染。我还在使用Nodejs作了一些其它的工做。

好比我在服务端使用Nodejs管理了这样一个JSON文件。PHP端不在维护错误码和错误码显示的文案。全部前端须要显示文案放在Nodejs端作统一的管理。并且，我线下也能够同经过系统对这些错误文案进行动态的更新。提升系统的可用性。