关于React，近期工做中项目的一点小体验

背景

最近一直都在作一个管理后台的重写，原项目是.net 4.x + layui作的一个SPA应用，暂不谈后台和数据库（谈的话又有好多要吐槽的了），单单从React开发的角度上来谈本身经历的问题吧。

这篇水文就不从特别技术的角度来说，react、redux什么的用法就不涉及了，更多的是最近的代码组织的一点总结。还但愿可以有大佬能指点一下，react开发到底如何组织。

数据管理

常见的React技术栈就是React+Redux，其中还涉及有redux-thunk和react-redux，由于传统的react单向数据流在组件交互频繁且组件嵌套过深的状况下数据传递效率很低，因此引入redux这样的解决方案做为数据集中管理的场所，便于数据交互。

最初个人使用中很天然的选用react+redux做为解决方案，可是后续的问题也产生了，首先，组件的数据交互并无那么复杂，假设组件交互要跨过中间一个组件，那么引入redux是有必定必要性的，可是，若是组件的交互是彻底是父子关系，那么redux反而会拖累开发的节奏和流畅行。

而后就是，redux+redux-thunk解决方案在项目代码项目文件的组织上相对繁琐，若是使用redux-thunk，除了你正常使用redux要使用的：一个actionType文件用于定义action信息、一个actions文件经过参数构造action、一个reducer用于根据action对state进行处理（state通常也在这个文件里），你还要在action中定义thunk-action，也就是说针对一个请求的action，一般状况下你须要写一个触发的thunk-action和三个请求状态action分别是start、success和fail，固然在项目小的时候，代码还不至于难以管理，可是当项目逐步增大的时候，对项目结构的设计和划分就变得异常重要，由于当不正常划分时，很容易出现一个文件里有几百行的action信息、action构造函数和reducer的switch-case。

还有一个问题就是connect组件问题，使用react-redux的connect方法能够有效的链接基础组建与业务state、action，可是不要过于依赖这样的方式，最优的方法仍然是原始的组件见的交互，当试着去对基础组件使用connect接入redux时，本来的数据交互逻辑从主组件向基础组件滑坡，最终致使不得不去在维护主组件逻辑的同时经过action影响state去控制基础组件，这样在多个文件中切换（主组件、actionType、actions、reducer）很容易出现失误。

上面的问题我目前的总结就是两点：

1.能不用redux尽可能不用redux进行数据管理，固然这个值根据项目的实际数据交互程度而定的

2.合理划分文件目录结构，必定要在开发前作到心中有数，通常来讲数据交互不频繁的就拆成不一样的reducer，同一个reducer内action和action-handle过多的状况下就根据组建拆分红不一样的文件，最后只要把全部的文件经过import整合成一个文件去处理就行了，这样有利于在开发中action和调用action组建的定位。

3.项目的组件链接尽可能使用原始的方式，而不要接入redux。而redux的接入通常在模块的层级上接入。这样能有效的避免因redux充斥项目而致使开发中逻辑随意流窜而理清逻辑须要在多个文件中跳转而引起的效率低下问题。

4.能够考虑使用redux-actions等辅助库来减轻action和reducer代码的繁琐

目录结构

如下是我采用的目录结构

├── src
│   ├── Bcomponent      //业务组建
│   ├── common      //通用内容
│   ├── components      //基础组件
│   ├── pages           //页面
│   │   ├── batch       //业务模块
│   │   ├── commonTool
│   │   └── project 
│   │       ├── landProject     //业务页面
│   │       │   ├── coordinates         //页面的独立组件
│   │       │   ├── detail
│   │       │   ├── docs
│   │       │   ├── mapperview      //每一个独立组件下都有本身的action和reducer代码文件方便查找
│   │       │   ├── measureplan
│   │       │   ├── pdfViewer
│   │       │   ├── _redux          //业务页面的redux相关内容
│   │       │   ├── villageeditor
│   │       │   └── villagelist
│   │       ├── minutes
│   │       │   ├── minutesDetail
│   │       │   └── _redux
│   ├── redux           //全局redux
│   │   ├── common
│   │   ├── commonSaga
│   │   ├── saga
│   │   └── store
复制代码

在目录结构设计上必定要下工夫，合理的设计目录结构对开发的思路理清至关重要

组件设计

react开发最重要的就是组件的开发与使用，在我两三个月的智障操做下，我认为组件的开发应该保证这样的特性：

1. 组件不该负责过多的业务要求，一个组件须要的是在特定的状况下方便复用，而涉及过多的业务需求在复用层面上显然是不方便的，举个例子连选输入获取市县街道，我我的认为最好的方法是编写基础连选组件，而后针对业务你能够在业务组件层对基础组件进行进一步包装，切记开发基础组件时抱着一步到位的想法。
2. 组件的配置应尽可能简洁，这点很难去量化，什么是简洁根据组件的使用状况有明显不一样，可是，若是当你使用组件时你须要配置不少不少的props，那么就是不简洁。是连选框组件，它有已经存在列表下的连选和须要动态获取的连选，那么不须要非得让组件同时能够知足两种状况的配置，把动态获取放在组件外，这样组件保证小而美也不会在从新看代码时脑袋疼。
3. 组件的状态，基础组件内状态不该该涉及到业务，这是为了组件复用，若是须要将业务包装在组件内最好仍是经过业务组件对基础组件进行包装来达到复用。引入一层业务组件是一个很好的实践，它可以保证你的逻辑有效的分散又不至于乱流窜。
4. 组件/页面的模式。个人此次开发中碰到的最头疼的问题的就是组件的模式，一个简单的窗体页面，它要涉及到展现、编辑、新增、校核和审核等几个模式。我在开发时选择的是同一个组件添加多个模式的状态，可是到最后一个页面代码和逻辑膨胀到本身都难以处理的程度，我感受这绝对不是一个正确的解决方案，可是目前没有明确的解决方案，只是认为应该把这样的页面分离开。我认为新版的react hooks可能会更好的解决这个问题，因此暂时很少说了。

代码问题

项目开发中代码要保证合理的封装，而且保证代码的整洁。这一点我后续也要深刻研究《重构》这本书。

目前个人我的总结简单的就是这么几个方面：

1. 代码分类，好比说转化状态成jsx的代码，那么就放在一块儿，而后给一个“命名空间”好比说叫transition。
2. 合理封装，一个对象若是涉及到对它的操做并返回一个结果，那么把它封装成类就很好，好比我业务中遇到的附件上传，一个附件类至少须要有附件名、服务器名、路径、上传状态，同时，若是是新上传的文件预览须要转成base64而后再预览，所以一个toBase64方法就可有放在附件类里而不须要做为简单的一个方法。

先后端链接

一个项目的先后端数据传输格式必定要协调好，不然有你受的（大哭）。若是请求出错了，后端必定要返回一个错误码附加错误内容，是一个200 ok + 错误内容string简直要死了，前端不得很少写一个string的错误判断。

另外，若是你的业务是一个傻*的后台，在先后数据交换没法优化的状况下，那么请放弃对前端的任何深刻重构吧，它绝对会浪费你的青春

写在最后

一个项目最重要的是防止其逐步腐烂，拯救一个被Green Day感染的项目（jojo梗）简直让人崩溃，并且最重要的是公司的状况，我如今反对任何盲目的重构和重写，若是想作这个事情，首先要对公司有一个明确的认识，状况是否容许作，并且老板是否对这件事情高度关注（口头说不算，要看他对业务的计划和本人的状况）。好了就这么多，发发牢骚，还得继续从坑里面爬出来，真难受。

写完一点都不想从新排版，心累