关于 Pipeline 使用过程的一些困惑

[atian25]

背景

最近在基于 Artus 写一个 CLI 命令行工具，主要思考点是：

• 命令行本身也存在 pipeline 场景：process.argv -> parser -> middleware -> find command -> exec command -> respond
• 命令行有插件扩展的场景
• 等等。

具体情况先不在这里展开，目前还在 POC 验证阶段，相关代码：https://github.com/atian25/artus-common-bin/tree/init

实践过程中遇到的问题

1. Trigger 的 Input 和 Output 不知道什么场景来使用，我看几个 demo 都是直接操作 container 来作为数据传递。

然后 Input 的内容也不在 container 里面，所以后续的 Controller 之类的也没法 inject，因此在 Pipeline 的某个地方总要把 input 的一些内容放到 container。

这里的边界比较难把控，需要讨论下。

---

2. Context 和 ExcutionContainer 的区别是什么？

感觉不知道啥时该用啥

---

3. Storage 的 set 签名

// https://github.com/artusjs/pipeline/blob/master/src/base.ts#L22
  set(value: any, key?: string | symbol): void {
    key ??= ContextStorageSymbol;
    this.storageMap.set(key, value);
  }

set(value, key) 的方式不太符合直觉，可以考虑支持重载： set(value) 和 set(key, value) 方式。

同 Input，它的 namespace 的使用场景是怎么样的？

这块感觉需要有一些更表达设计意图的上层封装 demo 出来

---

4. Application、Lifecycle、Trigger 的边界和定位

如 https://github.com/atian25/artus-common-bin/tree/init 的写法，感觉有点别扭，不知道代码应该在哪个里面

---

5. Container 的 API
   可以考虑支持下语法糖 container.set(id, value) ，这个感觉是高频用法，目前 container.set({ id: '', value: '' ) 写的还是有点繁琐。

[hyj1991]

然后 Input 的内容也不在 container 里面，所以后续的 Controller 之类的也没法 inject，因此在 Pipeline 的某个地方总要把 input 的一些内容放到 container。

现阶段确实可以考虑去掉 ctx 以及附带的一系列前期设计，改成 execution 阶段完全由 execution container 驱动 @noahziheng @JerrysShan

[atian25]

从 API 倾向上，我觉得 container 是底层机制，最好在用户编程界面上不要暴露太多。
类似 Input 这些是在开发者上层封装时可以规范类型的，而 container 是随便塞，类型容易丢失。
可以考虑要不要扩展下 Input 的用法，它的底层可以是存到 container

[hyj1991]

这确实也是一个思路，保留 ctx 的设计，底层切换为基于 execution container 的实现，考虑到 pipeline 引入运行时容器后，实际上已经不再职能纯净了，重构下 ctx 的底层实现看起来也没啥问题

[atian25]

现在有 Input，但我不知道应该如何基于 Input 去定义我的上层 Trigger，最佳实践