拼多多C端前端数据层改进方案
2017-11-09 14:05:36 0 举报
使用async后数据层的设计
作者其他创作
大纲/内容
实例化model,管理model
返回数据
使用model获取数据
新的方式:所有请求都用model来封装1.一个model应具备一个接口,以及这个接口所请求的所有字段,这样不需要写接口文档,通过model就可以知道是什么接口请求了什么字段(类似schma)2.用promise封装这个model的get方法,用于请求数据3.用@decorator写注解封装dataformat方法,在数据请求回来时自动做相应的类型转换4.用Flow在数据赋值时做类型检查,减少不必要的parseInt等类型转换代码
后端渲染
缺陷1.model只能处理一个数据的请求,对于有依赖的多个数据的请求无法组织。2.apiRequest直接把api地址写在业务代码里,没有单独的封装,没有可读性,之后接手项目的人不知道这个接口请求了都干了什么3.apiRequest是回调函数的写法,加上埋点,记录页面信息等,容易出现回调地狱,代码不易维护4.容易造成一个接口多次调用,没有一个通用的store存放所有的已请求数据,往往是再请求一次的暴力解决方式
两种方案:1.数据的请求在用node层做一次代理,用node拦截掉前端发起的请求,处理成近似GraphQL的方式,前端可以随意控制请求到的数据,但是实现难度高,容易背锅,这个暂时不好实现2.强制在vm层独立一个数据请求的对象或增加一个control层,为数据的请求封装对象,把方案一在node层处理的步骤放在前端,一切数据层的部分全在这一层去处理。
model层
type类型检查
前端渲染
页面进入
view-model1.处理业务逻辑2.组织数据的请求逻辑3.将数据和view对应
view视图
方案二的具体方案:
将所有请求规约到model层中1.过去的做法:过去是通过继承base-model来实现model可以直接获取数据,然后再process方法中进行数据的格式化
粒度单一,一个model只负责一个请求
VM层
用不同action语义化描述产品的需求,可以满足由于五类人逻辑,平台不同,灰度不同,导致文案显示不同的问题,最终生成唯一的文案给view层
model用类似ORM的方式组织
强制建立一个独立的数据层1.若使用mobx,就在store层的action做这个事情,把一个或多个数据的请求看成一次action,用action获取完整的数据添加到store中2.不使用mobx,在纯react中,添加一个对象,用对象的set和get规约数据的获取,比如对象的get就是去三个不同的接口取不同的数据然后拼在一起,避免直接把请求逻辑写在react内部
两种方式1.写一个model获取2.直接用apiRequest来获取
schema数据结构
维持现状原因:1. node层存放太多请求容易出锅2. 后端渲染没有必要请求太多数据,把第一屏展示了即可,之后上了PWA还有骨架可以优化首屏显示问题
收藏
0 条评论
下一页
为你推荐
查看更多