[RFC]: trigger 实现机制存在的问题

[JerrysShan]

现在 core 中提供了trigger 机制，有个默认实现，上层如果有自定义的需求可以实现覆盖，现在的覆盖机制存在一定的问题：
因为覆盖机制在 didLoad 阶段生效，假如在 configDidLoad 阶段，我添加了自定义中间件，会发现中间件应用到了 core 中 default trigger ，而不是 custom trigger ; 在 didload 阶段之后添加的中间件会应用到 custom trigger 中。

• 一种方案是 core 中只定义 trigger 规范，而不提供实现，交给上层实现
• 另外一个角度看 trigger 是否有必要， trigger 现在只是对洋葱模型 compose 的包装 ，为什么我们不直接使用compose 洋葱模型，而非得添加个中间层

[hyj1991]

内置实现有必要，描述出现的问题其实是在当前的基于 scan 的加载机制下的 didLoad 生命周期的误用，按照 #145 中，三者顺序应当为：

• module
• lifecycle-hook-unit
• config

即普通的无自定义 loader 的文件其实需要最先加载，保证 container 在启动期的预先完备性。

生命周期实际上也是 didLoad 或者叫 fileDidLoad 是前置 hook，然后才是 config 相关的 hook，这样的顺序更加适合当前基于 Scan 的机制

[wengeezhang]

trigger的设计和实现，是有一定的问题的。现在上层插件是通过“设置相同的id”来获取trigger实例，而不是通过明确trigger class来获取。

这就导致的结果就是：仅通过id + 加载流程时序问题没处理好，拿到的到底是哪个trigger肯定会出问题。

[hyj1991]

内置类靠 id 覆盖我觉得没有什么太大问题，这给了上层一些灵活性，只是基于 Scan 的机制下，用户逻辑介入前 global container 的完备性变成了启动期的一个隐含前置条件，目前的 didLoad 生命周期又是 follow 了传统框架（譬如 egg）的设计，这才导致了这个矛盾的产生，需要修改的是启动步骤（以及对应的生命周期执行时机）

[JerrysShan]

修改启动步骤，仍然解决不了我上面描述的问题，仍会存在一定阶段拿到的 trigger 是不同实例的值

[hyj1991]

可以解决，module 加载完毕后，这些 id 覆盖的过程都结束了，container 里面是最终结果，此时开始生命周期处理并不会有问题

[JerrysShan]

那就是调整后的生命周期流程是 didLoad -> configWillLoad -> configDidLoad -> willReady -> didReady

[hyj1991]

对，实际上基于 Scan 的机制，文件载入 container 是需要前置的，并且这个过程并不依赖 config

[JerrysShan]

get

[DuanPengfei]

@hyj1991 @JerrysShan 有关 lifecycle 这块，当前阶段的结论是订正成 didLoad -> configWillLoad -> configDidLoad -> willReady -> didReady 这样吗？

[hyj1991]

我认为这样是合理的，主要的理由是 scan 机制下 global container 的完备性变成了一个前提（依赖），Inject 的静态元信息构造的依赖图，有点类似传统 web 框架启动前那个用户无感知的 require 或者 import 过程。cc @DuanPengfei

[DuanPengfei]

我认为这样是合理的，主要的理由是 scan 机制下 global container 的完备性变成了一个前提（依赖），Inject 的静态元信息构造的依赖图，有点类似传统 web 框架启动前那个用户无感知的 require 或者 import 过程。cc @DuanPengfei

@hyj1991 我爬楼看历史消息，看起来当前也是满足要求的，我问这个问题的原因是要准备演讲文稿，而 lifecycle 是咱们这次很看重的一个概念，协议实现现在也是基于 lifecycle 和 plugin 机制去实现的，想确定一个版本 😄。

[noahziheng]

@hyj1991 @JerrysShan 有关 lifecycle 这块，当前阶段的结论是订正成 didLoad -> configWillLoad -> configDidLoad -> willReady -> didReady 这样吗？

这一点上我持保留意见，这涉及 didLoad 的语义调整，之前是指（全部）加载完成，调整后存在歧义和使用错误的风险（Config 未加载，依赖 @config 的类如被实例化使用将报错），Config 也应当是 Global Container 完备的必要条件

另外，对应的，各插件的实例化行为也需要调整到 configDidLoad，这不科学

[DuanPengfei]

@hyj1991 @JerrysShan 有关 lifecycle 这块，当前阶段的结论是订正成 didLoad -> configWillLoad -> configDidLoad -> willReady -> didReady 这样吗？

这一点上我持保留意见，这涉及 didLoad 的语义调整，之前是指（全部）加载完成，调整后存在歧义和使用错误的风险（Config 未加载，依赖 @config 的类如被实例化使用将报错），Config 也应当是 Global Container 完备的必要条件

另外，对应的，各插件的实例化行为也需要调整到 configDidLoad，这不科学

@noahziheng 这里应该是“文件加载完成”，而 didLoad 的感觉是全部都加载完成了对吗？

[hyj1991]

另外，对应的，各插件的实例化行为也需要调整到 configDidLoad，这不科学

可以增加一个 container did load 的周期，至于 didload，也可以保留目前的语义，作为 load 结束后 emit

[hyj1991]

我的本意并非一定要更改 didLoad 的语义，而是认为 container 文件的完备后再执行框架的逻辑，这个在 scan 模式下是合理的，也可以避免一些边加载框架逻辑边加载 contianer 文件造成的问题（比如本例）

[hyj1991]

6f79b40 已经解决此问题，调整顺序后 module 预先执行，保证了 container 的完备性

[hyj1991]

本 RFC 涉及到的生命周期顺序问题已经在 6f79b40 解决，剩下的关于内置 Trigger 合理性的讨论重定向至 #165