我是如何使用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