# ServiceLocator Module data flow

**Purpose:** Concise overview of service locator.

**Primary role:** Simple registry for cross-module services. Provides `getService` (lookup) and `register` (bind) for named service instances used across workbook and spreadsheet subsystems.

- **Internal state:** `services: { [x: string]: Object }` map storing registered services by name.

**API**
- `getService<T>(name: string): T` — returns the instance previously registered under `name`. If missing, throws a string error: `The service ${name} is not registered`.
- `register<T>(name: string, type: T): void` — stores `type` at `services[name]` only if not already present (noop if already registered).

**Behavior & invariants**
- Registration is idempotent: subsequent `register` calls for the same `name` are ignored.
- Lookup throws when a service is absent — callers must handle or ensure registration order.
- Lightweight and synchronous; no lifecycle or disposal semantics.

**Where it's used**
- Used by the Spreadsheet/Workbook host to provide shared utilities (locale, renderer factories, etc.) to decoupled modules via dependency lookup.

**Maintainer notes**
- If multiple modules register services during initialization, ensure deterministic ordering to avoid silent no-ops.
- Consider adding `unregister` or an `override` flag if dynamic replacement is required by tests or hot-reload workflows.