refactor(appkit): introduce CoreServiceRegistry and ServiceLocator#371
Closed
ditadi wants to merge 1 commit into
Closed
refactor(appkit): introduce CoreServiceRegistry and ServiceLocator#371ditadi wants to merge 1 commit into
ditadi wants to merge 1 commit into
Conversation
AppKit's core previously ran a hardcoded boot sequence for cache +
telemetry. This refactor introduces a generic registry so the core no
longer names concrete services:
- `CoreServiceFactory<T>` — interface every core service implements,
returning `{ instance, shutdown }` (or `null` for intentional opt-outs).
- `CoreServiceRegistry` — boots a list of factories in declared order,
shuts down in reverse, doubles as a typed locator via `get<T>(name)`.
- `bootstrap-factories.ts` — composes the list `_createApp` boots,
living next to the concrete service modules so `core/appkit.ts` stays
free of concrete-class imports.
Cache and Telemetry are migrated to expose `.factory()` static methods
and flow through the registry. Behaviour is identical: same boot order,
same shutdown order, same opt-out semantics.
Plugins now receive a typed `services: ServiceLocator` through
`attachContext`, in addition to the existing per-service fields kept
for backwards compatibility (`cache`, `telemetry`, plus a `taskflow`
placeholder typed as `unknown` for forward compat). New plugins should
consume `services.get<T>(name)`; the named legacy fields are marked
`@deprecated`.
This PR is groundwork — no behaviour change, no public-API removal.
The purpose is to make room for a third core service (TaskFlow) without
re-threading the cross-package `attachContext` contract: adding a new
service now only touches the service module and `bootstrap-factories.ts`.
TaskFlow itself is intentionally NOT in this PR; it lands in a follow-up.
Verified: pnpm -r typecheck, pnpm build, full pnpm test
(122 files, 2255 tests) all green.
Signed-off-by: ditadi <victordperd@gmail.com>
Contributor
Author
|
Superseded by #374 — replatformed onto |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stack
CoreServiceRegistry+ServiceLocator(layer 1, base:main)SQLWarehouseConnectorinto submit/get/poll/transform (layer 2, base: this PR)Review independently — this PR is groundwork, no behaviour change.
AppKit's core previously ran a hardcoded boot sequence for cache +
telemetry. This refactor introduces a generic registry so the core no
longer names concrete services:
CoreServiceFactory<T>— interface every core service implements,returning
{ instance, shutdown }(ornullfor intentional opt-outs).CoreServiceRegistry— boots a list of factories in declared order,shuts down in reverse, doubles as a typed locator via
get<T>(name).bootstrap-factories.ts— composes the list_createAppboots,living next to the concrete service modules so
core/appkit.tsstaysfree of concrete-class imports.
Cache and Telemetry are migrated to expose
.factory()static methodsand flow through the registry. Behaviour is identical: same boot order,
same shutdown order, same opt-out semantics.
Plugins now receive a typed
services: ServiceLocatorthroughattachContext, in addition to the existing per-service fields keptfor backwards compatibility (
cache,telemetry, plus ataskflowplaceholder typed as
unknownfor forward compat). New plugins shouldconsume
services.get<T>(name); the named legacy fields are marked@deprecated.This PR is groundwork — no behaviour change, no public-API removal.
The purpose is to make room for a third core service (TaskFlow) without
re-threading the cross-package
attachContextcontract: adding a newservice now only touches the service module and
bootstrap-factories.ts.TaskFlow itself is intentionally NOT in this PR; it lands in a follow-up.
Verified: pnpm -r typecheck, pnpm build, full pnpm test
(122 files, 2255 tests) all green.
Signed-off-by: ditadi victordperd@gmail.com
Stack created with GitHub Stacks CLI • Give Feedback 💬