lowcode-engine
lowcode-engine copied to clipboard
物料中使用数据源的方案探讨
Describe the bug (required) / 详细描述 bug(必填)
A clear and concise description of what the bug is. / 请提供清晰且精确的 bug 描述
物料中使用数据源的方案探讨
To Reproduce (required) / 如何复现 bug?(必填,非常重要)
Steps to reproduce the behavior: / 详细复现步骤:
实际案例:有一个高级物料,分为两部分:上部分为查询表单,下部分为列表。点击查询表单的【提交】按钮发起请求,该请求会带上
表单数据和分页数据,请求结果为列表数据。
方案一
1:提供一个onSearch配置项,该配置项的setter为FunctionSetter 2:用户在数据源面板创建一个数据源 3:用户找到onSearch配置项,并手动绑定事件处理函数 4:在事件处理函数中手段调用数据源
this.dataSourceMap['userList'].load({
data: {}
}).then(res => {})
.catch(error => {});
优点:较为灵活,事件处理函数中可以添加很多自定义代码逻辑 缺点:用户需处理第2、3、4步,流程较长,且第4步用户使用成本较高,非前端开发人员基本上不可能完成
方案二
1:提供一个requestPath配置项,该配置项的setter为StringSetter 2:组件内部处理请求逻辑(无需对用户可见)
async onSearch(){
const params=this.form.getFieldValues()
const res=axios.get(this.props.requestPath)
this.dataSource=res.data
}
3:用户找到requestPath配置项,并填入请求路径 优点:用户仅需操作1步,且该步骤仅仅只是填入一个请求path,流程简单 缺点:灵活性较差,如有需求的时候需扩展请求前的参数处理以及请求后数据处理函数
English version example:
- Go to '...'
- Click on '....'
- Scroll down to '....'
- See error
中文版示例:
- 打开 demo;
- 点击标题;
- 在右侧修改标题内容为「修改后的标题」;
- 渲染画布标题组件没有更新显示为「修改后的标题」;
Expected behavior (required) / 预期行为(必填,非常重要)
A clear and concise description of what did you expect to happen. / 请清晰和精确的描述你预期的行为
Screenshots (optional) / bug 截图(可选)
Sceenshots for further information. (If applicable.) / 一些有用的截图将会帮助我们更好的明确以及定位问题
Environments (please complete the following information) (required): / 请提供如下信息(必填)
- AliLowCodeEngine version: [e.g. 1.0.0] / 低代码引擎版本
- AliLowCodeEngineExt version: [e.g. 1.0.0] / 低代码引擎扩展包版本
- Browser [e.g. chrome, safari] / 浏览器版本
- materials / plugins / tools / 其他物料 / 插件 / 工具链版本
(this information can be collected via the manual plugin / 版本信息可通过低代码用户手册插件收集)
Additional context (optional) / 更多额外信息(可选)
Any other context of the problem here. / 可以追加更多的额外信息,帮助定位问题
方案一和二写的都蛮好的,确实是不同的用户适合不同的方案,看目标用户情况吧
第二个方案需要后端接口遵守较强的规范,我觉得对于普通公司是有点难的,就比如日期,组件返回的可能是[startTime, endTime],后端需要的是{startTime, endTime},还有省市区之类的 个人觉得低代码能降低一定的门槛,但完全不懂代码逻辑也玩不转
第二个方案需要后端接口遵守较强的规范,我觉得对于普通公司是有点难的,就比如日期,组件返回的可能是[startTime, endTime],后端需要的是{startTime, endTime},还有省市区之类的 个人觉得低代码能降低一定的门槛,但完全不懂代码逻辑也玩不转
你说的有一定道理,第二种方案在接口比较规范时是比较方便的。但是如果需要对请求参数、返回数据进行处理的场景下还是需要扩展相应的配置,成本和方案一不会相差太多
这个数据请求的数据,可以在动态 setter 配置里面获取到吗? 或者说在动态setter里面,能够获取哪些数据呀?