项目背景
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 的组件库,反馈给公司的组件设计和开发部门,形成一个良性循环。
网友评论