项目背景
Teams 开始做工业级的安防监控软件。主要的需求是通过安防设备以及传感器获取相应区域的参数信息，在Gateway 上做数据处理后上报给服务端，在云端进行数据聚合分析形成特定的模型，从不同的切面来监测区域和人身安全。
作为公司的大前端团队，web 部分的技术栈主要是Angular( angular 2+)。由于要采用公司内部的UI 库，需要采用React 作为前端的开发技术栈。后来经过对现在市面上的框架的调研，决定采用Umi。
为什么是Umi
Umi 是蚂蚁金服的底层前端框架，已经在阿里的业务中大量使用过，有足够多的项目作为技术实践和打磨。
简单理解：Umi = Dva + 配置式/约定式路由 + 大量webpck插件
umi 的实现业务的核心部分主要还是dva。
dva 是基于redux 和 redux-sage（异步解决方案）的数据流方案，其中还内置了react-router 和fetch, 是一个轻量级的应用框架。
dva: https://dvajs.com/
dva 入门教程： https://github.com/dvajs/dva-docs/tree/master/v1/zh-cn/tutorial
为什么是Typescript
由于Team 之前的前端技术栈是Angular, Ts 已经深入人心了。静态类型约束和TSlint 给予的类型检测，让代码更利于阅读，基本的引用及语法错误大大减少。
Team对于使用ts的基本要求是:
1、Components中必须要有props 和state 的接口声明以及对应参数的类型约束。参数的类型约束可以不用非常明确（可以采用any 或者{[key:string]: any}）的约束方式。
2、models 中对于复杂的数据结构，需要拆解结构类型。保证model 在引用时，能够明确清楚其完整的结构以及数据类型。
3、function 对入参和出参有明确的类型标识。
4、work space 不能有任何的Ts lint 的标红语法报错。
基于Umi的业务框架
项目迭代了一年多了，team 对umi 使用的有了一些积累。后面的项目都会采用相同的技术架构。我们再已运行的项目上抽象出公共的结构，形成我们team的基础业务框架，主要包括：
1、configure router，我们需要根据不同的用户形成不同的路由视图，在原在umi原本的路由基础上，再做配置。
2、Advance component，项目中采用的公司内部的组件库，并不能完全满足我们的业务需求，我们会在其基础上再做封装。
3、Utils，每个项目中积累的工具函数是我们一直维护的工具包，将会形成无依赖的工具库。
4、Local，基于umi 的local 插件，使用python 脚本处理excel 表格生成对应js 文件。
5、Draggable configuration dashboard，基于React-grid-layout基础上再封装，可拖拽可变尺寸，可配置的动态dashboard。
未来
Umi 框架的在项目中的应用已经相对成熟，将来我们会将基于的umi 的业务框架抽象出来后，以一种类似git subLirbrary 形式进行管理。多个项目启动时采用基础的项目结构，公共的结构和共享的部分共同维护。当多个项目迭代到一定程度之后，会生成大量的符合公司design language 的组件库，反馈给公司的组件设计和开发部门，形成一个良性循环。
