记一波大规模前端系统重构
2017-12-20 本文已影响5人
cyuamber
最近参与了一波规模较大的前端系统构建项目，有一些感悟和实用的经验想记录下来。主要分为以下几点：
一、前端系统架构方面
二、UI库选择方面
三、代码结构方面
四、功能点实现方面
五、代码调试方面
六、bug解决方面
七、项目总结
下面，分点说一说吧。
- 前端系统架构
首先阐释一下项目背景。此次重构的目的是将原系统的功能全部迁移到新系统中，之所以不选择复用原系统，是因为原有系统采用了angular1.x，angular2.x，vue等多个框架，给后期维护带来了很大困难，因此在评估时间成本的基础上，选择了重构的方案，统一使用react框架来对系统进行重构。
本项目采用create react app构建，同时使用了webpack构架，同时提供mock数据功能。
在项目搭建方面，本项目以react-router为基底，通过路由定位至每个页面；对于每个单独的页面，均包含：组件、actions、reducer三个部分，同时采用了immutable的方式进行状态管理。
- UI库选择
本项目采用了一贯使用的Ant Design框架，一方面考虑使用熟练性，一方面考虑和react的兼容性和配色问题。主要使用的组件有：Form、Table、Modal、Upload、DatePicker、TimePicker等
- 代码结构
本项目使用create react app构建。
- 功能点实现
根据项目功能点，本项目大功能点主要分为以下几个：
4.1. toolbar
toolbar中主要包含：查询、选择、重置这三个功能，使用的控件有：Form、Input、Select、Button、TimePicker等。
4.2. table
4.3. modal
-
代码调试
没有数据的时候，使用连接原有项目的机器，将原有数据代理到本地进行开发，或者直接使用mock数据进行开发；在接口开发完成后，将rd机器代理到本地进行调试，需要在package.json文件中进行开发环境的配置。
图5.1 proxy的配置实例
同时，为了方便接口更换调试，也将所有接口单独放在constant.js文件中，进行所有api的统一管理。
图5.2 控件中需要使用的接口
- bug解决
6.1 对异常情况的考虑
对于前端来说，最频繁的异常情况出现在与后端交互时产生的数据结构的变动，所以在考虑这方面的异常情况时需要尽量把情况考虑完全。
通过这个项目，我的经验总结如下：
首先，需要和RD沟通清楚，结合双方的情况进行数据结构的协商，这个过程既不能完全迁就前端也不能完全迁就后端；比如，如果前端依赖了某个组件库进行开发，那么最佳的后端数据结构应该是符合这个组件库的，如此，前端就不需要再做其他的处理。但是，事实上并非每次后端都可以提供最合适的数据结构，比如后端代码大规模继承了之前的数据结构，或者是RD能力有限等等，如果遇到这种情况，前端也只能迁就后端对数据结构进行进一步的改造和处理（常用方法有：object.keys, map, for...in 等）。但在这个项目中，由于前端统一使用了antd的组件库，因此如果每个人都重写一边数据结构来契合组件库的需求的话，代价是很大而且无意义的，因此，就和后端就此问题进行了沟（si）通（bi）。最终，终于在数据结构上达成了一致。。。。
第二，对数据为空情况的考虑。这个部分一定要细致，很细致，用我师兄的话说，一定要让自己的系统拥有很强的容错性。可以和后端约定：空的数据都返回[]，但也一定要考虑后端还有可能返回：null, undefined等各种奇葩的情况，所以在请求发送后，除了对返回码进行判断外，还需要对正确返回码中的数据进行额外的处理，比如，对数组的length进行判断，或者简单粗暴的typeof判断等。除此之外，当涉及到数据层面的操作时，一定要考虑到数据返回undefined或者null的情况，比如，当显示请求数据时，不能简单的采取{this.data.delivery_id}这种方式，而是需要判断this.data是否存在，最好采用可以备选方案，比如三元运算符(this.data)?(this.data.delivery_id):('-')
这一点在开发H5页面时尤为重要。
- 项目总结
7.1 momentjs
7.2 antd框架实践
ant真的是很强大的一个框架，最近刚刚发布了3.0版本，此次也是使用了最新的版本进行开发。
首先要说的是DatePicker这个控件。需求中有提到...
以上，就是对这个大规模项目开发过程的总结，随着上线会有接连不断的问题涌来，到时候再慢慢解决。
未完待续。。
