面向更多运行场景特别是云上的各种环境，咱能不能别用 egg loader 那套机制了？

[kurten]

• rt

[DuanPengfei]

@kurten 可以详细讲讲你的思路和想法吗？Loader 这个概念确实存在，不过跟 Egg 的 Loader 还是不太一样的。

• 想听听看你的理解，以及 Loader 机制不好的地方
• 有什么好的思路和想法可以抛出来聊聊

[cevio]

也用过egg，对与loader我觉得没有tegg的加持，很难知道每个小服务上的内容，特别是对于不了解项目的同学。其实这是种心智负担。js发展到现在理论上可以通过标准的js声明式规则来减轻负担。

先上一个例子：

https://github.com/pjblog/blog/blob/master/packages/bootstrap/src/index.ts

所有服务都是标准的，不需要知道依赖顺序，不需要让开发者确定加载过程，而这些事情都应该是系统内部自己处理掉的。这样开发者只需要关注逻辑即可。

至于，依赖的关系，通过算法是能解决的。

看一个例子：

https://github.com/pjblog/blog/blob/master/packages/core/src/article/service.ts

通过@Provider和@Consumer直接将依赖服务绑定在一起了。只需要无顺序add到factory就能自动算出启动顺序。而每个服务理论上给出生命周期即可，让开发者自由度变高。

我的意思是，所有逻辑其实都应交由开发者自己决定，而依赖则由系统处理。

看一个实现插件化的例子：

https://github.com/pjblog/pjblog-plugin-comment/blob/master/packages/widget/index.ts

这说明了其实无所谓插不插件，所有服务即插件的概念。其实也应证了目前主流的想法，声明式。

当然，我只是简单抛出一个想法，官方团队可以参考下。

核心实现也很简单 https://github.com/pjblog/blog/blob/master/packages/manager/src/root.ts

[atian25]

@cevio 没太看懂你举的 2 个例子，跟这个 issue 的 title 的关系是什么？没看懂他们跟 egg loader 有什么关系。

你指的开发者，是应用开发者，还是插件开发者，还是框架开发者？

第 1 个例子，artus 本身就是 ioc 的，从业务开发者的角度，本身就不需要写 loader，也不需要知道顺序。
第 2 个例子，artus 插件就是这样的啊，插件只需要 export 对象，会自动被 container 维护和 ioc，至于插件是能力插件，还是业务逻辑插件，这是用户可以自行决定的（当然未来可能会梳理出最佳实践）

[cevio]

@cevio 没太看懂你举的 2 个例子，跟这个 issue 的 title 的关系是什么？没看懂他们跟 egg loader 有什么关系。

你指的开发者，是应用开发者，还是插件开发者，还是框架开发者？

第 1 个例子，artus 本身就是 ioc 的，从业务开发者的角度，本身就不需要写 loader，也不需要知道顺序。 第 2 个例子，artus 插件就是这样的啊，插件只需要 export 对象，会自动被 container 维护和 ioc，至于插件是能力插件，还是业务逻辑插件，这是用户可以自行决定的（当然未来可能会梳理出最佳实践）

意思是不需要动态loader文件来实现，走标准的声明式import也许对用户心智负担低一些。

[atian25]

不冲突吧，如果你不需要 artus 来帮你实现对应的实例化管理，直接 import 就好了吧，这个没禁止。