amis 如何用 Tasks 任务操作集合实现上线任务的提交、检测与失败重试【免费下载链接】amis前端低代码框架通过 JSON 配置就能生成各种页面。项目地址: https://gitcode.com/GitHub_Trending/am/amis当你需要在页面上放一个上线任务清单——比如依次执行 hive 运算、小流量、全量这几个步骤每个任务可以点按钮提交、提交后自动轮询状态、失败后可以点重试——amis 的 Tasks 渲染器type: tasks文档描述为任务操作集合类似于 orp 上线就是为这个场景准备的。这篇文章基于 amis 仓库中的 Tasks 组件文档 和 渲染器源码把提交submitApi、状态检测checkApi、失败重试reSubmitApi三条链路串起来。适用前提页面已经接入 amis并且后端能提供三个接口检测、提交、重试接口返回格式符合 amis 的 API 规范status为0表示正常msg为提示信息data为数据体详见 API 类型文档。定义任务列表与状态码Tasks 渲染器把每个任务建模为一个数组项核心字段是label任务名称、key任务键值文档要求唯一区分、status任务状态、remark当前任务状态备注支持 html。状态码是理解整个流程的基础源码和文档保持一致status含义界面上的表现0初始状态不可操作提交按钮置灰is-disabled1就绪可操作提交按钮可用2进行中还没有结束操作列显示加载动画Spinner3有错误不可重试显示出错无重试按钮4已正常结束显示已完成5有错误且可以重试显示重试按钮点击走reSubmitApi状态列的文字由statusTextMap控制默认值就是按上面 05 的顺序排列的[未开始, 就绪, 进行中, 出错, 已完成, 出错]列标题、按钮文字也都可以改taskNameLabel、btnText默认上线、retryBtnText默认重试等完整属性见 属性表。最简单的用法是不请求任何接口直接用items静态渲染一份任务列表{ type: tasks, name: tasks, items: [ { label: hive 任务, key: hive, status: 4, remark: 查看详情a target\_blank\ href\http://www.baidu.com\日志/a。 }, { label: 小流量, key: partial, status: 4 }, { label: 全量, key: full, status: 4 } ] }remark支持 html示例中就是用来挂日志链接的。接入 checkApi提交前的初始检测与进行中的轮询要让任务状态来自后端配置checkApi。API 支持字符串简写[method:]urlmethod可取get、post、put、delete缺省为get[ { type: tasks, name: tasks, checkApi: /api/mock2/task }, 为了演示目前获取的状态都是随机出现的。]这是仓库文档里的官方示例/api/mock2/task对应仓库自带的 mock 接口返回的任务状态会随机变化只用于演示。实际使用时把url换成你自己的检测接口。checkApi的返回必须遵循 API 格式且data必须是一个数组数组里每项就是一个任务对象结构参考items{ status: 0, msg: , data: [ {label: Hive 运算, key: hive, status: 2}, {label: 小流量, key: partial, status: 0}, {label: 全量, key: full, status: 0} ] }上面是参照 mock 实现 的示例输出格式。如果返回的response.data不是数组组件会弹出提示返回格式不正确, 期望 response.data 为数组, 包含每个 task 的状态信息——看到这条提示说明后端返回结构不对这是排查检测链路的第一步。轮询行为在源码中是明确的组件挂载后会先按checkApi请求一次拿到初始任务列表之后只有当列表中存在status 2进行中的任务时才会每隔interval毫秒再次请求interval默认3000全部任务都不是进行中时不发起请求如果配置了轮询但checkApi没有设置会提示checkApi 没有设置, 不能及时获取任务状态。配置 submitApi提交上线任务在检测的基础上加上提交接口就构成完整的操作链路。checkApi沿用文档示例的演示地址submitApi、reSubmitApi两个地址仓库文档未提供需要替换成业务侧真实的提交与重试接口post:前缀按后端实际请求方式调整{ type: tasks, name: tasks, checkApi: /api/mock2/task, submitApi: post:/api/task/submit, reSubmitApi: post:/api/task/resubmit, interval: 3000 }提交时的行为均以源码为准只有status 1就绪的任务其上线按钮才处于可用状态其余行按钮置灰点击提交后该任务立即置为status: 2进行中操作列切换为加载动画随后组件用请求数据发起submitApi调用请求体会把当前行任务的数据label、key、status、remark合并进页面数据一起发送源码中为createObject(data, item)后端可以据此区分是哪一行任务提交接口的返回按三种情况处理data是数组则整表刷新并继续轮询data是单个对象则按key匹配更新对应任务API 配置replaceData为 true 时整行替换没有返回data则 4ms 后立即触发一次检测如果submitApi没有配置就点击提交组件提示submitApi 没有配置。失败后重试reSubmitApi 的触发条件任务失败后能否重试完全由checkApi或提交接口返回的status决定而不是由按钮逻辑决定status: 5有错误且可以重试操作列渲染重试按钮默认文字危险样式点击后走reSubmitApi后续流程与提交相同——状态先变 2 并轮询直到检测接口给出新的状态status: 3有错误不可重试只显示出错状态不提供重试按钮如果任务状态是 5 但没有配置reSubmitApi点击重试会提示reSubmitApi 没有配置。另外提交/重试请求本身抛错时接口请求失败源码会把该行状态置为错误码并把错误信息写入remark列展示。验证方式与限制完成配置后可以按下面几点核对链路是否打通初始加载打开页面后任务列表来自checkApi各行状态标签按statusTextMap显示未开始/就绪/进行中/出错/已完成/出错提交点击某行上线后该行立即出现加载动画随后状态跟随checkApi的轮询结果变化interval内默认 3 秒可观察到刷新重试构造一个status: 5的返回例如在检测接口中把某任务置为 5确认操作列出现重试按钮点击后请求发往reSubmitApi仓库内的 示例页面 包含静态items与checkApi两种配置mock 服务 可以本地跑起来观察随机状态流转注意文档明确说明演示接口的状态是随机出现的不能当作固定预期。两个边界需要记住status: 3的任务按设计不可重试轮询只在存在进行中任务时进行所以全部完成后停止请求是正常现象不是检测失效。如果后端的状态码与 amis 默认的 05 不一致可以在 schema 中用initialStatusCode、readyStatusCode、loadingStatusCode、errorStatusCode、finishStatusCode、canRetryStatusCode逐项映射见 源码接口定义不需要改造后端。状态标签配色可通过statusLabelMap调整列标题与按钮文字通过各*Label、btnText、retryBtnText配置其余请求参数超时、请求头、数据映射等参照 API 类型文档 中复杂配置一节补齐即可。【免费下载链接】amis前端低代码框架通过 JSON 配置就能生成各种页面。项目地址: https://gitcode.com/GitHub_Trending/am/amis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 22:35:20 · 阅读 1.2k amis 如何用 Tasks 任务操作集合实现上线任务的提交、检测与失败重试
amis 如何用 Tasks 任务操作集合实现上线任务的提交、检测与失败重试【免费下载链接】amis前端低代码框架通过 JSON 配置就能生成各种页面。项目地址: https://gitcode.com/GitHub_Trending/am/amis当你需要在页面上放一个上线任务清单——比如依次执行 hive 运算、小流量、全量这几个步骤每个任务可以点按钮提交、提交后自动轮询状态、失败后可以点重试——amis 的 Tasks 渲染器type: tasks文档描述为任务操作集合类似于 orp 上线就是为这个场景准备的。这篇文章基于 amis 仓库中的 Tasks 组件文档 和 渲染器源码把提交submitApi、状态检测checkApi、失败重试reSubmitApi三条链路串起来。适用前提页面已经接入 amis并且后端能提供三个接口检测、提交、重试接口返回格式符合 amis 的 API 规范status为0表示正常msg为提示信息data为数据体详见 API 类型文档。定义任务列表与状态码Tasks 渲染器把每个任务建模为一个数组项核心字段是label任务名称、key任务键值文档要求唯一区分、status任务状态、remark当前任务状态备注支持 html。状态码是理解整个流程的基础源码和文档保持一致status含义界面上的表现0初始状态不可操作提交按钮置灰is-disabled1就绪可操作提交按钮可用2进行中还没有结束操作列显示加载动画Spinner3有错误不可重试显示出错无重试按钮4已正常结束显示已完成5有错误且可以重试显示重试按钮点击走reSubmitApi状态列的文字由statusTextMap控制默认值就是按上面 05 的顺序排列的[未开始, 就绪, 进行中, 出错, 已完成, 出错]列标题、按钮文字也都可以改taskNameLabel、btnText默认上线、retryBtnText默认重试等完整属性见 属性表。最简单的用法是不请求任何接口直接用items静态渲染一份任务列表{ type: tasks, name: tasks, items: [ { label: hive 任务, key: hive, status: 4, remark: 查看详情a target\_blank\ href\http://www.baidu.com\日志/a。 }, { label: 小流量, key: partial, status: 4 }, { label: 全量, key: full, status: 4 } ] }remark支持 html示例中就是用来挂日志链接的。接入 checkApi提交前的初始检测与进行中的轮询要让任务状态来自后端配置checkApi。API 支持字符串简写[method:]urlmethod可取get、post、put、delete缺省为get[ { type: tasks, name: tasks, checkApi: /api/mock2/task }, 为了演示目前获取的状态都是随机出现的。]这是仓库文档里的官方示例/api/mock2/task对应仓库自带的 mock 接口返回的任务状态会随机变化只用于演示。实际使用时把url换成你自己的检测接口。checkApi的返回必须遵循 API 格式且data必须是一个数组数组里每项就是一个任务对象结构参考items{ status: 0, msg: , data: [ {label: Hive 运算, key: hive, status: 2}, {label: 小流量, key: partial, status: 0}, {label: 全量, key: full, status: 0} ] }上面是参照 mock 实现 的示例输出格式。如果返回的response.data不是数组组件会弹出提示返回格式不正确, 期望 response.data 为数组, 包含每个 task 的状态信息——看到这条提示说明后端返回结构不对这是排查检测链路的第一步。轮询行为在源码中是明确的组件挂载后会先按checkApi请求一次拿到初始任务列表之后只有当列表中存在status 2进行中的任务时才会每隔interval毫秒再次请求interval默认3000全部任务都不是进行中时不发起请求如果配置了轮询但checkApi没有设置会提示checkApi 没有设置, 不能及时获取任务状态。配置 submitApi提交上线任务在检测的基础上加上提交接口就构成完整的操作链路。checkApi沿用文档示例的演示地址submitApi、reSubmitApi两个地址仓库文档未提供需要替换成业务侧真实的提交与重试接口post:前缀按后端实际请求方式调整{ type: tasks, name: tasks, checkApi: /api/mock2/task, submitApi: post:/api/task/submit, reSubmitApi: post:/api/task/resubmit, interval: 3000 }提交时的行为均以源码为准只有status 1就绪的任务其上线按钮才处于可用状态其余行按钮置灰点击提交后该任务立即置为status: 2进行中操作列切换为加载动画随后组件用请求数据发起submitApi调用请求体会把当前行任务的数据label、key、status、remark合并进页面数据一起发送源码中为createObject(data, item)后端可以据此区分是哪一行任务提交接口的返回按三种情况处理data是数组则整表刷新并继续轮询data是单个对象则按key匹配更新对应任务API 配置replaceData为 true 时整行替换没有返回data则 4ms 后立即触发一次检测如果submitApi没有配置就点击提交组件提示submitApi 没有配置。失败后重试reSubmitApi 的触发条件任务失败后能否重试完全由checkApi或提交接口返回的status决定而不是由按钮逻辑决定status: 5有错误且可以重试操作列渲染重试按钮默认文字危险样式点击后走reSubmitApi后续流程与提交相同——状态先变 2 并轮询直到检测接口给出新的状态status: 3有错误不可重试只显示出错状态不提供重试按钮如果任务状态是 5 但没有配置reSubmitApi点击重试会提示reSubmitApi 没有配置。另外提交/重试请求本身抛错时接口请求失败源码会把该行状态置为错误码并把错误信息写入remark列展示。验证方式与限制完成配置后可以按下面几点核对链路是否打通初始加载打开页面后任务列表来自checkApi各行状态标签按statusTextMap显示未开始/就绪/进行中/出错/已完成/出错提交点击某行上线后该行立即出现加载动画随后状态跟随checkApi的轮询结果变化interval内默认 3 秒可观察到刷新重试构造一个status: 5的返回例如在检测接口中把某任务置为 5确认操作列出现重试按钮点击后请求发往reSubmitApi仓库内的 示例页面 包含静态items与checkApi两种配置mock 服务 可以本地跑起来观察随机状态流转注意文档明确说明演示接口的状态是随机出现的不能当作固定预期。两个边界需要记住status: 3的任务按设计不可重试轮询只在存在进行中任务时进行所以全部完成后停止请求是正常现象不是检测失效。如果后端的状态码与 amis 默认的 05 不一致可以在 schema 中用initialStatusCode、readyStatusCode、loadingStatusCode、errorStatusCode、finishStatusCode、canRetryStatusCode逐项映射见 源码接口定义不需要改造后端。状态标签配色可通过statusLabelMap调整列标题与按钮文字通过各*Label、btnText、retryBtnText配置其余请求参数超时、请求头、数据映射等参照 API 类型文档 中复杂配置一节补齐即可。【免费下载链接】amis前端低代码框架通过 JSON 配置就能生成各种页面。项目地址: https://gitcode.com/GitHub_Trending/am/amis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考