Open vianvio opened 4 years ago
时间还没到期,先把问题1和3回答一下吧,问题2还要再琢磨一下
Q1. 根据你的描述:“通过拖拽配置控件自动实现一个自定义表单”,以及 “公司部门开发间业务比较封闭,各自完成自身业务为主”。业界公开的拖拽方案比较多,因为更容易产生宣讲效果。请你思考一下,你为什么当时选择拖拽形式来做这样的表单?目前从公司情况来看并不理想,现在应该如何改进? A
Q3. 描述数据采集链路(如果数据是目前公司自己采集的),ETL,BI,最后落到前端开发工作的流程,举一个典型的业务场景例子来说明整个数据链路,并谈谈你认为前端在这个过程中的价值。 A
拖拽的做法:实际上是为了更好的交互,控件拖拽进入表单里,在排序上,操作上也更加友好
从交互的角度确实如你所说的这样,但是请思考一下组件的用户群体,是以开发为主,还是以非开发的角色为主,再回来看拖拽的合理性。同时,基于用户群体,思考另一个问题,拖拽的结果核心是界面,还是代码,反推表单实现上是否会有不同。
问题3
流程非常清晰,感谢分享
问题3拓展
根据目前的业务形态,整个数据分析应该是离线完成的?那么抛开目前业务来看,流程上哪里可以做些改动来满足实时分析?
拖拽的做法:实际上是为了更好的交互,控件拖拽进入表单里,在排序上,操作上也更加友好
空闲时间,就问题一想和老师交流一下;老师厉害,一眼就道明了我们之前的问题和困惑。 背景:之前这个表单编辑器就是希望给用户用的,所以拖拽的考虑是合理的。但是在实现用户基本功能后发现很多配置操作是非开发用户难以完成的,比如联动需要调用远程接口,接口地址配置,表单编辑器字段与业务字段匹配的配置,等等问题。所以我们新增一个路由作为开发人员入口,这些配置可以通过开发人员的入口进入完成。 所以现在的结果是:简单表单可以通过非开发人员进行配置;复杂表单就需要开发人员介入了;如果是特别复杂的,我也提过,在业务中引入表单这个组件的时候可以在slot内自己完成自己的组件。目前的做法是这样,我其实也特别想和老师交流一下,有没有了解过这方面更优的做法,给些启示,谢谢🙏
整体思路上是一致的,这里我了解到的做法,一种是在拖拽后生成ast结构树,之后基于这棵树反推成代码,盒马那边有一个产品是这样做的,虽然我也不太理解为什么要整这个,而不是直接到代码层,其他同学可以补充。 另一种做法是比较常规的,在表单这层抽象一个json schema,拖拽之后与上面类似,不过是产出一份json配置,来描述整个表单,之后对应到开发那边只要封装一个Form的组件,把json作为props传入即可。这样在拖拽这一层,解决了简单的业务需求,同时,对复杂业务需求,开发人员可以用json配置确定大致的页面布局结构,之后再补充复杂逻辑即可,相当于减少一半的工作量。 这里Form组件需要考虑两个部分,第一是基础能力,基于json配置生成表单的能力,第二是拓展性,考虑form嵌套的能力。所以可以考虑将form抽象两部分,第一部分负责表单构建,第二部分负责表单布局。在布局里面增加类似slot的功能,保证整体灵活性。
问题列表: