ApplicationLifecycle 名称是否要调整

[wengeezhang]

背景

#52 将extension改为了lifecycle。
目前artus/core中types有一个interface ApplicationLifecycle，是以Application开头的。

提议

为了和#52的结论保持一致，@DuanPengfei 提议 是否要把ApplicationLifecycle改为 Lifecycle。

[wengeezhang]

@noahziheng @hyj1991

[DuanPengfei]

因为会涉及到用户界面，这些地方我的思路比较偏执的期望是能做到一致，implement Lifecycle，然后使用 LifecycleXXX decorator，这个是我的思路。

[noahziheng]

这个 interface 只是放了生命周期用的 Hook 名，Application Lifecycle 没有歧义，Lifecycle 太短了感觉有可能产生歧义

[wengeezhang]

我的提议：
之前我有一个提议https://github.com/artusjs/core/issues/58，是想让一个文件被多个加载器加载，所有功能模块（controller/middleware/aop）都可以有自己的hook。

当然这个提议的合理性，有待进一步讨论，这里不再展开。

只是用这个来举例，顺着这个思路，叫ApplicationLifecycle反而局限了，可以调整为Lifecycle:

export interface Lifecycle {
  configWillLoad?: HookFunction;
  configDidLoad?: HookFunction;
  didLoad?: HookFunction;
  willReady?: HookFunction;
  didReady?: HookFunction;
  beforeClose?: HookFunction;
}

[JerrysShan]

建议保留 Application 前缀更清晰标注是 app 的生命周期类型

[DuanPengfei]

@noahziheng @JerrysShan 你们的定义里是 Lifecycle 是 Application 的生命周期，这么理解对吗？我其实理解的 Lifecycle 是应用的声明周期，但这个应用是指一个完整的“应用”，不是 Application，我有点不知道怎么表述了，在我的思路里应用和 Application 不是一个中英文的概念。我举个例子，但有可能不恰当 😂

当我们想感知插件的加载与加载完成时，其实会提供类似于 pluginWillLoad 这种，它是应用的声明周期，但不一定是 Application 的。

[noahziheng]

@DuanPengfei 那我顺着你这例子，是不是 pluginWillLoad 其实有两种情况：

1. 所有插件 willLoad，那就是 Application 的生命周期（LoaderFactory 开始执行 plugin 部分之前）
2. 单个插件 willLoad，那是不应该向用户提供 PluginLifecycle 这一 interface，并在 @LifecycleHookUnit 的参数中指定 target 生效目标，这个做法会更有优？

综上，反而 Lifecycle 会混淆其生效目标

[DuanPengfei]

@DuanPengfei 那我顺着你这例子，是不是 pluginWillLoad 其实有两种情况：

1. 所有插件 willLoad，那就是 Application 的生命周期（LoaderFactory 开始执行 plugin 部分之前）
2. 单个插件 willLoad，那是不应该向用户提供 PluginLifecycle 这一 interface，并在 @LifecycleHookUnit 的参数中指定 target 生效目标，这个做法会更有优？

综上，反而 Lifecycle 会混淆其生效目标

嗯嗯，你成功的给我讲明白了，接受 ApplicationLifecycle 这个 interface。

[wengeezhang]

@DuanPengfei 那我顺着你这例子，是不是 pluginWillLoad 其实有两种情况：

1. 所有插件 willLoad，那就是 Application 的生命周期（LoaderFactory 开始执行 plugin 部分之前）
2. 单个插件 willLoad，那是不应该向用户提供 PluginLifecycle 这一 interface，并在 @LifecycleHookUnit 的参数中指定 target 生效目标，这个做法会更有优？

综上，反而 Lifecycle 会混淆其生效目标

可以叫Lifecycle, 多增加一个属性 target：

export interface Lifecycle {
  target?: string
  configWillLoad?: HookFunction;
  configDidLoad?: HookFunction;
  didLoad?: HookFunction;
  willReady?: HookFunction;
  didReady?: HookFunction;
  beforeClose?: HookFunction;
}

[noahziheng]

@wengeezhang 现在的 willReady/didReady/beforeClose 不是普适的，仅针对 Application 设计

[DuanPengfei]

综上，使用 ApplicationLifecycle 这个 interface 能够做到定义明确，不过在提到的 plugin lifecycle 情况下，decorator 可能要考虑加参数。都能做到的情况下，保持当前实现不变，暂时不改动，后续如果最佳实践出来确实有更合理的，再看情况。