文件加载器类型判定建议

[wengeezhang]

一.当前实现：

扫描阶段，按照文件信息（文件名+内部装饰器）确定该文件的loader类型

二.问题

1.对于lifecycle类型的，用户必须在文件中的export default 上加装饰器才发挥作用。虽然这样强制也说得过去，但是有些用户确实会踩坑。

2.一个文件一个加载类型，有点不够灵活。后续如果增加其他类型的，一个类型就要有一个文件。

三.优化建议和样例

既然用了装饰器，应该发挥它的作用，打破文件的限制。一个文件不再局限一个加载器，可能对应“1-n”个加载器。建议如下：

1.样例

比如下面这个例子，就会对于两个加载器：['module', 'lifecycle-hook-unit']

// controller/hello.ts
@Injectable()
export default class HelloController {
  @Inject(TestService)
  helloService: HelloService;

  async index () {
    return {status: 200};
  }
}

// HelloController专属的钩子函数
@LifecycleHookUnit()
export class MyLifecycle {
  @LifecycleHook()
  didLoad(){
    // 这里做HelloController相关的准备工作
  }
}

2.具体扫描方式如下：

• 扫描到controller/hello.ts，设置const loaderArr = []
• 先通过文件名确定是否为“config、package-json、meta”类型，比如是config，则往loaderArr中 push("plugin-meta")；否则往loaderArr中push('module')
  • 此时controller/hello.ts为普通文件，所以loaderArr的值为['module']
• 再require这个文件，遍历它的export(包括export default和普通export)，看export出来的class上有哪些装饰器。
  • 此时export上有一个MyLifecycle，它有个LifecycleHookUnit装饰器，所以往loaderArr中push('lifecycle-hook-unit')
  • 此时的loaderArr的值为['module', 'lifecycle-hook-unit']

3. loader时的调整：

• loader一个文件（manifestItem）时，先看它的loader，此时样例的loader值为：['module', 'lifecycle-hook-unit']
• 使用loader数组的每个类型，多次加载此文件（每次加载执行的逻辑在loader/impl中确定）

[DuanPengfei]

@wengeezhang 我理解现在就不局限文件（除了 config 和 package.json，plugin.meta.ts 这几个特殊的），所以技术上能做到，artus 确实也不限制。但是到了 gulu 或者 chair 里我们要有限制是因为我们是偏向为企业服务的框架，这个问题我理解 artus 是不存在。

[hyj1991]

我觉得这样做反而会 confuse，加载最小单元是文件，有助于理清应用自身的逻辑，lifecycle 和一个 injectable class 放到一个文件里，我认为不是合理的需求。

[DuanPengfei]

我觉得这样做反而会 confuse，加载最小单元是文件，有助于理清应用自身的逻辑，lifecycle 和一个 injectable class 放到一个文件里，我认为不是合理的需求。

+1

[DuanPengfei]

@wengeezhang 我可能局限在自己的视角里了，至少我自己开发不会混着写，即使允许这样写也不会。你这个思路出发点怎么样的，优劣势，适用场景，这些可以同步输出，提供下论据哈。

[wengeezhang]

@wengeezhang 我可能局限在自己的视角里了，至少我自己开发不会混着写，即使允许这样写也不会。你这个思路出发点怎么样的，优劣势，适用场景，这些可以同步输出，提供下论据哈。

每个class可能都需要有自己专属的hook，这个在业界无论是前端还是后端，都是普遍需求。 如果把这个hook专门新开一个文件维护，有点不太灵活。

[wengeezhang]

这里有两个点哈：

1. lifecycle和 injectable class可以在一个文件中（这个可能争议有点大，暂时可以不用实现，先观望）
2. 现有的lifecycle的判定，不要局限在export default（这个可以调整下）

[DuanPengfei]

@wengeezhang 我可能局限在自己的视角里了，至少我自己开发不会混着写，即使允许这样写也不会。你这个思路出发点怎么样的，优劣势，适用场景，这些可以同步输出，提供下论据哈。

每个class可能都需要有自己专属的hook，这个在业界无论是前端还是后端，都是普遍需求。 如果把这个hook专门新开一个文件维护，有点不太灵活。

那从开发经验上，我们是不是也会主动得将一类工作放到一起呢？即使现在没限制，作为开发者我自己也还是会这么做。而且也不局限 app.ts 写，只要能逻辑清楚就行。

[JerrysShan]

@wengeezhang 我可能局限在自己的视角里了，至少我自己开发不会混着写，即使允许这样写也不会。你这个思路出发点怎么样的，优劣势，适用场景，这些可以同步输出，提供下论据哈。

每个class可能都需要有自己专属的hook，这个在业界无论是前端还是后端，都是普遍需求。 如果把这个hook专门新开一个文件维护，有点不太灵活。

有什么样的场景每个class 都有自己的 hook ，感觉可以放在统一的一个 hook 里面做这个事情

[DuanPengfei]

这里有两个点哈：

1. lifecycle和 injectable class可以在一个文件中（这个可能争议有点大，暂时可以不用实现，先观望）
2. 现有的lifecycle的判定，不要局限在export default（这个可以调整下）

@wengeezhang 是说即使是 export xxx 这种非主入口，也允许加 decorator 的意思吗?
那这样用户就可以在一个文件里操作多类功能，感觉不是一个好的实践。

[wengeezhang]

@wengeezhang 我可能局限在自己的视角里了，至少我自己开发不会混着写，即使允许这样写也不会。你这个思路出发点怎么样的，优劣势，适用场景，这些可以同步输出，提供下论据哈。

每个class可能都需要有自己专属的hook，这个在业界无论是前端还是后端，都是普遍需求。 如果把这个hook专门新开一个文件维护，有点不太灵活。

有什么样的场景每个class 都有自己的 hook ，感觉可以放在统一的一个 hook 里面做这个事情

比如一些任务类的Service，需要在进程退出时，发送一个信号（给下游或者负责人）。这里的hook直接写在这个service的文件会比较好一点。

[wengeezhang]

这里有两个点哈：

1. lifecycle和 injectable class可以在一个文件中（这个可能争议有点大，暂时可以不用实现，先观望）
2. 现有的lifecycle的判定，不要局限在export default（这个可以调整下）

@wengeezhang 是说即使是 export xxx 这种非主入口，也允许加 decorator 的意思吗? 那这样用户就可以在一个文件里操作多类功能，感觉不是一个好的实践。

是的。主要是想export和export default都支持。避免有些人踩坑

[DuanPengfei]

@wengeezhang 我可能局限在自己的视角里了，至少我自己开发不会混着写，即使允许这样写也不会。你这个思路出发点怎么样的，优劣势，适用场景，这些可以同步输出，提供下论据哈。

每个class可能都需要有自己专属的hook，这个在业界无论是前端还是后端，都是普遍需求。 如果把这个hook专门新开一个文件维护，有点不太灵活。

有什么样的场景每个class 都有自己的 hook ，感觉可以放在统一的一个 hook 里面做这个事情

比如一些任务类的Service，需要在进程退出时，发送一个信号（给下游或者负责人）。这里的hook直接写在这个service的文件会比较好一点。

感觉有点说不通，我们的进程都是以应用维度启动的，进程退出的操作应该在 app 的 beforeClose 或者 afterClose 这种 hook 里去做。

如果是一个业务逻辑完成后，要去做什么操作，应该用代码去主动出发，通用的可以加上 AOP。

[DuanPengfei]

这里有两个点哈：

1. lifecycle和 injectable class可以在一个文件中（这个可能争议有点大，暂时可以不用实现，先观望）
2. 现有的lifecycle的判定，不要局限在export default（这个可以调整下）

@wengeezhang 是说即使是 export xxx 这种非主入口，也允许加 decorator 的意思吗? 那这样用户就可以在一个文件里操作多类功能，感觉不是一个好的实践。

是的。主要是想export和export default都支持。避免有些人踩坑

我反倒觉得一个文件里允许操作多种功能会比较困惑，更容易踩坑。😄