Nicolas
7d11dd1426
All checks were successful
CI / build-lint-test (pull_request) Successful in 37s
@RegisterService(uid) et @Service<T>(uid) prennent desormais l'uid en parametre explicite, choisi par l'appelant, plutot que de le generer automatiquement (crypto.randomUUID) et de resoudre par reference de classe. ServiceRepository simplifie en consequence : une seule map uid -> instance (plus de WeakMap constructeur -> uid, resolveClass/ getUidForClass/hasClass supprimes, devenus inutiles). @Service ne peut plus inferer le type depuis une reference de classe : a annoter la propriete ou a typer explicitement (@Service<T>(uid)). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
52 lines
2.6 KiB
Markdown
52 lines
2.6 KiB
Markdown
# @lightweight-sdk/service-registry
|
|
|
|
Registre de services en singleton, avec enregistrement et injection par décorateurs. Package `common` : isomorphe, aucune dépendance DOM ou Node-only.
|
|
|
|
## Installation
|
|
|
|
```bash
|
|
pnpm add @lightweight-sdk/service-registry
|
|
```
|
|
|
|
## Usage
|
|
|
|
```ts
|
|
import { RegisterService, Service } from '@lightweight-sdk/service-registry';
|
|
|
|
export const LOGGER_UID = 'logger';
|
|
|
|
@RegisterService(LOGGER_UID)
|
|
class LoggerService {
|
|
public log(message: string): void {
|
|
console.log(message);
|
|
}
|
|
}
|
|
|
|
class ReportGenerator {
|
|
@Service<LoggerService>(LOGGER_UID)
|
|
private readonly logger!: LoggerService;
|
|
|
|
public run(): void {
|
|
this.logger.log('generating report');
|
|
}
|
|
}
|
|
```
|
|
|
|
## Concepts
|
|
|
|
- **`ServiceRepository`** — singleton central qui stocke une instance unique de chaque service, indexée par l'uid choisi par le développeur à l'enregistrement. Accès direct rarement nécessaire : `RegisterService`/`Service` couvrent l'usage courant.
|
|
- **`@RegisterService(uid)`** — décorateur de classe. Instancie la classe décorée (constructeur sans argument obligatoire) et l'enregistre dans le `ServiceRepository` sous `uid`. **C'est au développeur de choisir `uid` et de garantir son unicité** — la registry refuse tout doublon.
|
|
- **`@Service<T>(uid)`** — décorateur de propriété. Injecte l'instance enregistrée sous `uid` dans le membre décoré. `uid` seul ne porte pas le type : annoter la propriété (ou passer le paramètre générique `<T>`) pour un typage correct. La résolution est **paresseuse** (au premier accès à la propriété, pas à la décoration) : peu importe que la classe consommatrice soit évaluée avant ou après l'enregistrement du service. Après le premier accès, la propriété est remplacée par la valeur résolue (pas de nouvelle recherche ensuite).
|
|
|
|
## Contraintes
|
|
|
|
- Une classe décorée par `@RegisterService(uid)` doit avoir un constructeur sans argument obligatoire — ses propres dépendances doivent elles-mêmes être injectées via `@Service`, pas passées au constructeur.
|
|
- `uid` doit être unique dans toute l'application — exporter une constante partagée (comme `LOGGER_UID` ci-dessus) entre le point d'enregistrement et les points d'injection évite les fautes de frappe.
|
|
- `experimentalDecorators: true` doit être activé côté consommateur (déjà le cas dans ce monorepo via `tsconfig.base.json`).
|
|
|
|
## API
|
|
|
|
- `RegisterService(uid)` — décorateur de classe.
|
|
- `Service<T>(uid)` — décorateur de propriété.
|
|
- `ServiceRepository` — singleton (`getInstance()`, `register(uid, target)`, `resolve(uid)`, `has(uid)`). `resetForTesting()` est réservé aux tests.
|
|
- `ServiceConstructor<T>`, `ServiceUid` — types associés.
|