Cordis插件配置API:Config、inject与provide的对照表
Cordis插件配置APIConfig、inject与provide的对照表【免费下载链接】cordisMeta-Framework of Spatiotemporal Composability项目地址: https://gitcode.com/GitHub_Trending/co/cordisCordis 是一个主打时空可组合性Spatiotemporal Composability的元框架Meta-Framework插件是其整个生态的灵魂。对刚接触 Cordis 的新手来说插件配置 API 里的三个概念——Config、inject、provide——最容易混淆它们都出现在插件声明里名字又短又像实际作用却天差地别。这篇文章就用一张清晰的对照表帮你一次性理清 Cordis 插件配置 API 的这三兄弟。先给结论三个词各管什么在 Cordis 中一个插件可以同时拥有这三种身份Config定义这个插件自己需要什么样的配置结构、校验、合并规则。inject声明这个插件依赖别人提供的服务缺了就不启动。provide声明这个插件能给别人提供什么服务让别人可以注入。一句话记忆法Config 管我要什么参数inject 管我等谁provide 管我是谁。Config插件的参数说明书Config 本质上是插件的配置结构声明它在 Cordis 中用一个 schema 对象表示遵循 Standard Schema 规范。定义在 packages/core/src/registry.ts 的Plugin.Base接口中。Config 主要有两个职责配置校验当插件被加载时Cordis 会拿你的配置去和 Config 做校验不合法会直接抛出ValidationError并告诉你哪一项、哪个字段出了问题见 packages/core/src/fiber.ts 的resolveConfig。配置合并当父子作用域都对同一个服务做了配置拦截时Cordis 会按层级合并。默认用Object.assign浅合并如果你定义了Config.merge则会调用它做自定义合并见 packages/core/src/service.ts 的resolveConfig逻辑。// 伪代码示意给插件声明配置结构 function plugin(ctx: Context, config: { port: number }) {} plugin.Config schema.object({ port: schema.number() })inject声明我等谁inject 声明了插件运行所需的依赖服务列表。Cordis 会等到这些服务都被 provide 之后才真正执行你的插件回调如果服务迟迟未提供插件就一直处于等待状态。inject 的写法有两种数组形式inject: [logger, http]只声明依赖名。对象形式inject: { http: { port: 8080 } }除了声明依赖还能覆盖该服务的默认配置这就是 Cordis 的配置拦截机制见 packages/core/src/context.ts 的intercept。在类插件中还可以用Inject()装饰器挂在类或方法上。加载器Loader也支持在配置文件的 entry 里写inject字段见 packages/loader/src/config/entry.ts。provide声明我是谁provide 声明插件对外提供的服务名。它把插件实例注册到当前作用域的 store 中这样其他插件就能通过ctx.xxx或 inject 拿到它。// 伪代码示意插件对外提供名为 http 的服务 function http(ctx: Context, config: HttpConfig) { const server createServer(config) ctx.provide(http, server) return () server.close() } http.provide http如果你继承Service基类构造函数会自动调用reflect.provide(name, self)无需手动声明见 packages/core/src/service.ts 和 packages/core/src/reflect.ts。Config、inject、provide 完整对照表对比维度Configinjectprovide中文定位配置结构依赖声明服务提供核心问题我要什么参数我等谁就绪我能给别人什么方向面向自身向外索取向外供给数据类型Standard Schema 对象字符串数组 或 键值对象字符串或字符串数组主要作用校验配置、合并配置控制启动时机、覆盖依赖配置注册服务、暴露能力错误表现校验失败抛 ValidationError依赖未提供则一直挂起重复提供同名服务会报错代码位置插件函数的.Config属性插件的inject属性插件的provide属性生命周期插件加载时解析插件激活前检查插件激活时注册典型场景端口、路径、开关等参数依赖数据库、HTTP 服务提供数据库、HTTP 服务三者如何协同工作理解 Cordis 插件配置 API 的关键在于看懂这三者组成的依赖闭环插件 A 声明provide: http把自己注册为 http 服务的提供者。插件 B 声明inject: [http]Cordis 检测到 http 尚未就绪B 进入等待队列。插件 A 被加载http 服务 provide 成功。Cordis 立即唤醒 B此时 B 的ctx.http可用插件体才开始执行。如果 B 的 inject 带了配置对象还会在 B 的作用域内拦截并覆盖http 服务的部分配置——这就是时空可组合性中配置按作用域叠加的体现。整个过程由 packages/core/src/registry.ts 的RegistryService与 packages/core/src/fiber.ts 的Fiber协作完成每个插件都运行在独立的 Fiber作用域里注入与提供的关系天然支持嵌套与隔离。新手最容易踩的三个坑把 inject 和 provide 搞反inject 是索取provide 是供给。一个插件可以既 inject 别人又 provide 自己。忘了写 Config 导致配置失效不声明 ConfigCordis 不会对配置做任何校验错误参数会在运行时静默出错。重复 provide 同名服务同一个作用域内同名服务只能 provide 一次重复注册会直接抛错。若想覆盖请用 inject 的配置拦截而不是再 provide 一次。小结Cordis 插件配置 API 的三兄弟分工明确Config 定义参数规则inject 声明依赖关系provide 暴露服务能力。把它们记成参数—索取—供给三个动作再看一遍上面的对照表你就能顺畅地阅读和编写 Cordis 插件了。想深入源码可以从 packages/core/src/registry.ts、packages/core/src/service.ts 和 packages/core/src/reflect.ts 三个文件入手它们分别对应本文的 Config、provide 与依赖解析实现。【免费下载链接】cordisMeta-Framework of Spatiotemporal Composability项目地址: https://gitcode.com/GitHub_Trending/co/cordis创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考