vianvio / FE-Companions

山虽高,我心已决要攀登, 路再难,绊不住我的脚跟; 因为我看到生命之路就在这里。 -- 《天路历程》
447 stars 34 forks source link

20200224 - 梦想客Joy #11

Open vianvio opened 4 years ago

vianvio commented 4 years ago

问题列表:

  1. 根据你的描述:“通过拖拽配置控件自动实现一个自定义表单”,以及 “公司部门开发间业务比较封闭,各自完成自身业务为主”。业界公开的拖拽方案比较多,因为更容易产生宣讲效果。请你思考一下,你为什么当时选择拖拽形式来做这样的表单?目前从公司情况来看并不理想,现在应该如何改进?
  2. 公司内业务使用grafana的整体技术架构图(包括前后端),需要说明大数据领域ELK技术体系的职责。
  3. 描述数据采集链路(如果数据是目前公司自己采集的),ETL,BI,最后落到前端开发工作的流程,举一个典型的业务场景例子来说明整个数据链路,并谈谈你认为前端在这个过程中的价值。
lijingying91 commented 4 years ago

时间还没到期,先把问题1和3回答一下吧,问题2还要再琢磨一下

Q1. 根据你的描述:“通过拖拽配置控件自动实现一个自定义表单”,以及 “公司部门开发间业务比较封闭,各自完成自身业务为主”。业界公开的拖拽方案比较多,因为更容易产生宣讲效果。请你思考一下,你为什么当时选择拖拽形式来做这样的表单?目前从公司情况来看并不理想,现在应该如何改进? A

  1. 拖拽的做法:实际上是为了更好的交互,控件拖拽进入表单里,在排序上,操作上也更加友好
  2. 不理想原因:第一、公司各个部门业务各自为王,可能难以推广,这个虽然不能算是原因可确实有这样的客观因素;第二、从部门组内使用上看,业务场景比较复杂,比如会出现各个控件数据联动、控件选项值服务端实时调用、权限等问题,这些问题虽然有通过方案解决,但在使用上还是比较繁琐的;第三、为了减轻某些复杂控件开发人员的负担,我们开放两个控件,第一个控件业务方可以根据自己的需求通过slot方案在表单中开发添加自己的方案,第二个方案一个在线编辑平台,业务方可以提交自己在线编辑的控件。

Q3. 描述数据采集链路(如果数据是目前公司自己采集的),ETL,BI,最后落到前端开发工作的流程,举一个典型的业务场景例子来说明整个数据链路,并谈谈你认为前端在这个过程中的价值。 A

  1. 流程:qian d前端开发内容为web标注 5011582803986_ pic_hd
  2. 场景:爬公众号文章,先爬虫爬取页面,因为存在更新,所以会定时跑任务爬取,爬取后的页面进行解析,解析成可以解析的一切字段,然后对字段内容的数据进行清洗入库,这个库是个总库,包含一切来源的所有数据;接下来不同的业务有不同的业务规则获取数据,如果有数据错误的情况,算法可进行校验后可重新打日志进行入库。
  3. 前端的价值:第一是透明化,数据可查,哪个环节出错一眼可见;第二可视化,数据量情况一眼可见,例如数据图表统计;第三是规则存储,存储各个数据解析阶段的规则;最后也是最无奈的一点,数据的采集也不是完全正确的,开发人工校验平台。
vianvio commented 4 years ago

拖拽的做法:实际上是为了更好的交互,控件拖拽进入表单里,在排序上,操作上也更加友好

从交互的角度确实如你所说的这样,但是请思考一下组件的用户群体,是以开发为主,还是以非开发的角色为主,再回来看拖拽的合理性。同时,基于用户群体,思考另一个问题,拖拽的结果核心是界面,还是代码,反推表单实现上是否会有不同。

问题3

流程非常清晰,感谢分享

问题3拓展

根据目前的业务形态,整个数据分析应该是离线完成的?那么抛开目前业务来看,流程上哪里可以做些改动来满足实时分析?

lijingying91 commented 4 years ago

拖拽的做法:实际上是为了更好的交互,控件拖拽进入表单里,在排序上,操作上也更加友好

空闲时间,就问题一想和老师交流一下;老师厉害,一眼就道明了我们之前的问题和困惑。 背景:之前这个表单编辑器就是希望给用户用的,所以拖拽的考虑是合理的。但是在实现用户基本功能后发现很多配置操作是非开发用户难以完成的,比如联动需要调用远程接口,接口地址配置,表单编辑器字段与业务字段匹配的配置,等等问题。所以我们新增一个路由作为开发人员入口,这些配置可以通过开发人员的入口进入完成。 所以现在的结果是:简单表单可以通过非开发人员进行配置;复杂表单就需要开发人员介入了;如果是特别复杂的,我也提过,在业务中引入表单这个组件的时候可以在slot内自己完成自己的组件。目前的做法是这样,我其实也特别想和老师交流一下,有没有了解过这方面更优的做法,给些启示,谢谢🙏

vianvio commented 4 years ago

整体思路上是一致的,这里我了解到的做法,一种是在拖拽后生成ast结构树,之后基于这棵树反推成代码,盒马那边有一个产品是这样做的,虽然我也不太理解为什么要整这个,而不是直接到代码层,其他同学可以补充。 另一种做法是比较常规的,在表单这层抽象一个json schema,拖拽之后与上面类似,不过是产出一份json配置,来描述整个表单,之后对应到开发那边只要封装一个Form的组件,把json作为props传入即可。这样在拖拽这一层,解决了简单的业务需求,同时,对复杂业务需求,开发人员可以用json配置确定大致的页面布局结构,之后再补充复杂逻辑即可,相当于减少一半的工作量。 这里Form组件需要考虑两个部分,第一是基础能力,基于json配置生成表单的能力,第二是拓展性,考虑form嵌套的能力。所以可以考虑将form抽象两部分,第一部分负责表单构建,第二部分负责表单布局。在布局里面增加类似slot的功能,保证整体灵活性。