@equinor/fusion-framework-module-context 9.0.0-next.0 → 9.0.1

package/docs/data-model.md

@@ -1,134 +0,0 @@
-# Data Model
-
-What a context item actually looks like, how context *types* relate to each other, and the
-shapes used to query and filter them.
-
-## `ContextItem`
-
-A context item is the thing your application or portal is currently scoped to — a project, a
-facility, a contract, or any other entity the Fusion context API knows about.
-
-```ts
-type ContextItem<TValue = Record<string, unknown>> = {
-  id: string;
-  type: ContextItemType;
-  value: TValue;
-  externalId?: string;
-  source?: string;
-  title?: string;
-  subTitle?: string;
-  isActive?: boolean;
-  isDeleted?: boolean;
-  created?: Date;
-  updated?: Date;
-  graphic?: string | { type: 'html' | 'svg'; content: string };
-  meta?: string | { type: 'html' | 'svg'; content: string };
-};
-```
-
-The fields that matter most day to day:
-
-- **`id`** — the identifier the context module itself uses everywhere: `setCurrentContextById`,
-  `extractContextIdFromPath`, cache keys, and equality checks (`connectParentContext` only
-  reacts when `id` actually changes).
-- **`type`** — see [`ContextItemType`](#contextitemtype-and-hierarchies) below; this is what
-  `contextType` allow-lists and `validateContext` check against.
-- **`value`** — the domain payload for this item (e.g. the actual project or facility record).
-  Type it with the generic parameter, `ContextItem<MyProjectShape>`, when you know the shape.
-- **`externalId`** and **`source`** — identifiers from an upstream system, when the context item
-  was imported or mirrored from somewhere other than the context API itself.
-- **`title`** / **`subTitle`** / **`graphic`** / **`meta`** — presentation hints for UI
-  components (e.g. a context switcher) to render without needing to know the `value` shape.
-
-> [!NOTE]
-> `ContextItem` is currently a hand-written type, not yet backed by a runtime schema — see
-> [issue #5122](https://github.com/equinor/fusion-framework/issues/5122). Values coming back
-> from a real context API are not validated at the type boundary; a custom `setContextClient`
-> is responsible for shaping its own responses correctly.
-
-## `ContextItemType` and hierarchies
-
-```ts
-interface ContextItemType {
-  id: string;
-  isChildType?: boolean;
-  parentTypeIds?: string[];
-}
-```
-
-Every context item carries a `type` that says what *kind* of entity it is — `'ProjectMaster'`,
-`'Facility'`, `'Contract'`, and so on. Types can be organized as a shallow hierarchy:
-`isChildType: true` plus `parentTypeIds` marks a type as a child of one or more parent types
-(e.g. a `'Facility'` that belongs to a `'ProjectMaster'`).
-
-This hierarchy is informational — nothing in this module walks `parentTypeIds` automatically.
-It exists so that:
-
-- application code can build a "these types are related" UI (e.g. grouping facilities under
-  their parent project) without a second API call,
-- a custom `resolveContext` or `contextParameterFn` can use `parentTypeIds` to broaden a search
-  or a relation lookup by type family instead of a single exact type ID.
-
-`setContextType(['ProjectMaster'])` restricts which type **IDs** `validateContext` accepts — it
-does not expand automatically to include child or parent types unless you list them explicitly
-or write a custom `setValidateContext`.
-
-> [!NOTE]
-> Type ID matching in `validateContext`'s default implementation is case-insensitive, so
-> `'projectmaster'` and `'ProjectMaster'` are treated the same.
-
-## Querying and relating
-
-```ts
-type QueryContextParameters = {
-  search?: string;
-  filter?: { type?: string[]; externalId?: string };
-};
-
-type RelatedContextParameters = {
-  item: ContextItem;
-  filter?: { type?: string[] };
-};
-
-type ContextFilterFn = (items: ContextItem[]) => ContextItem[];
-```
-
-- **`QueryContextParameters`** is what `queryContext`/`queryContextAsync` sends to the query
-  client, after `contextParameterFn` has had a chance to transform it — see
-  [`setContextParameterFn`](../README.md#configuration-reference) and the
-  [OData recipe](recipes.md#odata-query-parameters) for a non-default mapping.
-- **`RelatedContextParameters`** is what `relatedContexts`/`relatedContextsAsync` sends when
-  looking up items related to a given `item` — this is what the default `resolveContext`
-  uses internally when validation fails; see [Lifecycle](lifecycle.md#resolving-context).
-- **`ContextFilterFn`** (`setContextFilter`) runs *after* a query returns, entirely client-side —
-  use it to hide items the API returned but that shouldn't be selectable (e.g. `isDeleted`
-  items), as opposed to `contextParameterFn`, which shapes the request itself.
-
-## The context client
-
-`ContextClient` is the piece that actually holds "the current context" and fetches a single
-item by ID. It underlies `currentContext`/`currentContext$` on `ContextProvider` — the provider
-does not keep its own separate copy of the state.
-
-```ts
-type GetContextParameters = { id: string };
-```
-
-`currentContext$` (and `currentContext`) can be in exactly three states, and the difference
-matters for anything that reacts to it:
-
-| Value | Meaning |
-|---|---|
-| `undefined` | No context has been resolved yet — the provider hasn't initialized (or finished initial-context resolution). |
-| `null` | Context was explicitly cleared, e.g. via `clearCurrentContext()`. |
-| a `ContextItem` | A context is actively set. |
-
-Treat `undefined` and `null` differently in UI code: `undefined` usually means "still loading,
-don't show an empty state yet", while `null` means "there really is no context — show the
-picker".
-
-## Errors
-
-`ContextClient`/the query clients throw `FusionContextSearchError` for domain-specific search
-failures thrown from a custom `setContextClient`'s `query` — see
-[Errors](../README.md#errors) in the README for a full example.

package/docs/lifecycle.md

@@ -1,163 +0,0 @@
-# Lifecycle
-
-How the context module decides whether to accept a new context, how it resolves one
-automatically on startup, and how a parent/child pair of instances stay in sync.
-
-## Setting context
-
-`setCurrentContext(item, opt)` is the entry point behind `setCurrentContextById`,
-`connectParentContext`, and the initial-context resolver below. It takes two options, both
-optional and both defaulting to `true`:
-
-- **`validate`** — check `item` against `validateContext` before accepting it.
-- **`resolve`** — when validation fails, try to resolve a related item instead of throwing.
-
-```mermaid
-flowchart TD
-  callSet["setCurrentContext"] --> sameId{"same id as current context?"}
-  sameId -- "yes, unchanged" --> keepCurrent["keep current context"]
-  sameId -- "no" --> shouldValidate{"validate requested?"}
-
-  shouldValidate -- "no" --> changeEvent[["onCurrentContextChange"]]
-  changeEvent -- "canceled" --> throwChange["throw: change rejected"]
-  changeEvent -- "not canceled" --> applyContext["apply item as current context"]
-
-  shouldValidate -- "yes" --> runValidate["run validateContext"]
-  runValidate -- "valid" --> changeEvent
-  runValidate -- "invalid" --> shouldResolve{"resolve requested?"}
-
-  shouldResolve -- "no" --> throwInvalid["throw: item did not validate"]
-  shouldResolve -- "yes" --> resolveEvent[["onSetContextResolve"]]
-  resolveEvent -- "canceled" --> throwResolveCanceled["throw: resolution canceled"]
-  resolveEvent -- "not canceled" --> runResolve["run resolveContext"]
-
-  runResolve -- "failed" --> throwResolveFailed["throw: no related item resolved"]
-  runResolve -- "resolved" --> resolvedEvent[["onSetContextResolved"]]
-  resolvedEvent -- "canceled" --> throwResolvedCanceled["throw: resolved item rejected"]
-  resolvedEvent -- "not canceled" --> callSet
-```
-
-A few things worth calling out that aren't obvious from the diagram alone:
-
-- **Setting context is queued, not immediate.** Every call to `setCurrentContext` is pushed
-  onto an internal queue and processed in order — even if nobody subscribes to the returned
-  `Observable`. This means two rapid calls (e.g. a user clicking two picker items quickly)
-  resolve one after another rather than racing.
-- **Unsubscribing aborts the queued task.** If the caller unsubscribes from the returned
-  observable before it completes, that in-flight context change is aborted and removed from the
-  queue — it will not silently apply later.
-- **`onCurrentContextChange` (no "d") fires *before* the context actually changes** and is
-  cancelable — a listener calling `event.preventDefault()` makes `setCurrentContext` throw
-  instead of silently no-op-ing.
-- **`onCurrentContextChanged` (with "d") fires *after*** a change has been applied, and is
-  *not* cancelable — it's an announcement, not a gate. This is the event `connectParentContext`
-  listens for to bubble changes to a parent.
-
-## Resolving context
-
-When validation fails and `opt.resolve` is `true`, the provider looks for a related item of an
-accepted type instead of rejecting the item outright:
-
-```mermaid
-flowchart LR
-  start["run resolveContext"] --> related["fetch relatedContexts for item"]
-  related --> filterValid["keep items where validateContext passes"]
-  filterValid -- "one or more found" --> firstMatch["return the first matching item"]
-  filterValid -- "none found" --> fail["throw: no related item found"]
-```
-
-> [!NOTE]
-> If no `contextType` allow-list is configured (`setContextType`), every context item
-> validates, so resolution never has anything left to correct — see
-> [Configuration](../README.md#configuration).
-
-The default `resolveContext` implementation can be replaced entirely with `setResolveContext`
-when the "look at related items of an accepted type" strategy doesn't fit — see the
-[Configuration reference](../README.md#configuration-reference) in the README.
-
-## Resolving the initial context
-
-When a context module instance is initialized, it tries — without any application code asking
-it to — to figure out what its current context should be, in this order:
-
-1. **From the URL.** If this instance (or its parent, when nested) has a `navigation` module,
-   its current path is run through `extractContextIdFromPath` (a GUID matcher by default). If an
-   ID is found, that item is fetched via the context client's `get` and used as a candidate.
-2. **From the parent context.** If step 1 doesn't produce anything — no navigation module, no
-   ID in the path, or no matching item — the instance falls back to its parent context module's
-   *current* context, if it has one.
-3. Whichever of the two resolves first is set as the current context, with both
-   `validate: true` and `resolve: true` — so an ID found in the URL still has to pass
-   `validateContext` (and can fall through to `resolveContext`) before it "sticks".
-
-```mermaid
-flowchart TD
-  init["module initializes"] --> tryPath{"path available and id extracted?"}
-  tryPath -- "yes" --> fetchById["fetch context item by id"]
-  fetchById -- "found" --> apply["set current context, validate and resolve"]
-  fetchById -- "not found or errors" --> tryParent
-  tryPath -- "no" --> tryParent{"parent has a current context?"}
-  tryParent -- "yes" --> apply
-  tryParent -- "no" --> none["current context stays unresolved"]
-```
-
-A portal opened directly at `/apps/my-app/7fd97952-...` resolves its context straight from that
-GUID; an app embedded inside a portal with no context in its own URL instead inherits whatever
-project the portal already has selected.
-
-Replace this entire strategy with `setResolveInitialContext` when neither source fits — for
-example, an application that always derives its context from a non-GUID slug, or one that must
-never auto-adopt a parent's context. Failures here are caught and logged as a warning rather
-than thrown, so a broken initial-context lookup doesn't block the rest of module
-initialization.
-
-## Parent/child propagation
-
-Every context module instance observes its nearest ancestor's current context and mirrors it
-locally, unless a listener opts out. This is what keeps a portal's selected project and an
-embedded application's context in sync without either side polling the other — set once in the
-portal, and it propagates down; a validated change from the app can bubble back up.
-
-```mermaid
-flowchart TD
-  subgraph parent["parent instance, e.g. a portal"]
-    parentSet["setCurrentContext is called"]
-    parentObserve["listens for onCurrentContextChanged"] --> sourceCheck{"event source is a different provider?"}
-    sourceCheck -- "yes" --> parentSet
-  end
-  subgraph child["child instance, e.g. an embedded app"]
-    childSubscribe["subscribes to parent currentContext stream"] --> parentChangedEvent[["onParentContextChanged"]]
-    parentChangedEvent -- "not canceled" --> childValidate["validate context"]
-    childValidate -- "fails" --> childResolve["resolve context"]
-    childValidate -- "passes" --> childChanged[["onCurrentContextChanged"]]
-    childResolve -- "resolved" --> childChanged
-    childResolve -- "fails" --> childNone["child keeps no current context"]
-  end
-  parentSet -.->|"currentContext stream emits"| childSubscribe
-  childChanged -- "not stopped" --> parentObserve
-```
-
-- A listener calls `event.stopPropagation()` on `onCurrentContextChanged` to keep a context
-  change local, so it never reaches ancestors or siblings.
-- A listener calls `event.preventDefault()` on `onParentContextChanged` to reject an incoming
-  context change from a parent instead of mirroring it.
-- A child that fails to validate *and* resolve a parent's context is left with **no current
-  context** — the parent's context is never force-applied. This is deliberate: an app that only
-  understands `'Facility'` context shouldn't be silently handed a `'Contract'` it can't use.
-- Only the first parent-context emission after connecting can be skipped
-  (`connectParentContext(provider, { skipFirst: true })`), and even without that option, a
-  context that already matches the child's current context by `id` is ignored — so a child
-  reconnecting to a parent it's already in sync with does not re-trigger validation.
-
-```ts
-// constrain a context change to this instance only, never bubbling to ancestors
-modules.event.addEventListener('onCurrentContextChanged', (event) => {
-  if (event.source === modules.context) {
-    event.stopPropagation();
-  }
-});
-```
-
-See [Events](../README.md#events) in the README for the full list of dispatched events and
-whether each is cancelable, and [Data model](data-model.md) for what a context item and its
-`type` actually look like.

package/docs/recipes.md

@@ -1,89 +0,0 @@
-# Recipes
-
-Configuration patterns that go beyond the [Configuration reference](../README.md#configuration-reference)
-in the README.
-
-## OData query parameters
-
-`setContextParameterFn` maps a search + type into the parameters `setContextClient`'s `query`
-receives. The default shape is a plain `{ search, filter: { type } }` object, but a context API
-backed by OData can build the filter with [`odata-query`](https://www.npmjs.com/package/odata-query)
-instead:
-
-```ts
-import buildQuery from 'odata-query';
-
-enableContext(configurator, (builder) => {
-  builder.setContextParameterFn(({ search, type }) =>
-    buildQuery({
-      search,
-      filter: { type: { in: type } },
-    }),
-  );
-});
-```
-
-## Rewriting a path on context change
-
-`setContextPathGenerator` builds the URL a navigation module pushes to when the current
-context changes. Beyond a simple GUID swap, a path can also carry an application-specific key
-derived from the resolved item:
-
-```ts
-enableContext(configurator, (builder) => {
-  builder.setContextPathGenerator((item, path) => {
-    // /app/old-app-key/overview -> /app/new-app-key/overview
-    return path.replace(/^(\/)?app\/[^/]+(.*)$/, `/app/${item.value.appKey}$2`);
-  });
-});
-```
-
-Pair this with a matching `setContextPathExtractor` so the same key round-trips back into a
-context id on page load — see [setContextPathExtractor](../README.md#configuration-reference)
-in the README.
-
-## Accepting a family of related context types
-
-`setContextType` matches exact type IDs, so an allow-list of `['ProjectMaster']` rejects a
-`'Facility'` item even if that facility's [`ContextItemType.parentTypeIds`](data-model.md#contextitemtype-and-hierarchies)
-includes `'ProjectMaster'`. To accept a type *and* its declared children, widen validation
-instead of the allow-list:
-
-```ts
-enableContext(configurator, (builder) => {
-  const acceptedTypes = ['ProjectMaster'];
-
-  builder.setContextType(acceptedTypes);
-  builder.setValidateContext((item) => {
-    if (acceptedTypes.includes(item.type.id)) return true;
-    return Boolean(item.type.isChildType && item.type.parentTypeIds?.some((id) => acceptedTypes.includes(id)));
-  });
-});
-```
-
-This keeps `setContextType` as the source of truth for the query allow-list (so searches still
-scope to the right types server-side) while letting validation reason about the type hierarchy.
-
-## Skipping the default initial-context lookup
-
-By default, a newly initialized instance tries to resolve its context from the URL, then from
-its parent — see [Resolving the initial context](lifecycle.md#resolving-the-initial-context).
-An application that manages its own startup context entirely (e.g. from application state
-rather than the URL or a parent) can replace that lookup outright:
-
-```ts
-import { EMPTY } from 'rxjs';
-
-enableContext(configurator, (builder) => {
-  // never auto-resolve an initial context; the application sets one explicitly later
-  builder.setResolveInitialContext(() => EMPTY);
-});
-```
-
-## Custom search errors
-
-`FusionContextSearchError`, thrown from `setContextClient`'s `query`, lets an application
-surface a domain-specific search failure instead of a generic error — see the
-[app-react-context-custom-error](https://github.com/equinor/fusion-framework/tree/main/cookbooks/app-react-context-custom-error/src/config.ts)
-cookbook for a complete example.
-

package/src/ContextModuleConfig.ts

@@ -1,147 +0,0 @@
-import type { AnyModuleInstance, ModuleInstance } from '@equinor/fusion-framework-module';
-import type { ObservableInput } from 'rxjs';
-import type { QueryCtorOptions } from '@equinor/fusion-query';
-
-import type {
-  ContextFilterFn,
-  ContextItem,
-  QueryContextParameters,
-  RelatedContextParameters,
-} from './types';
-import type { GetContextParameters } from './client/ContextClient';
-import type { IContextProvider } from './ContextProvider';
-
-/**
- * Resolved configuration for the context module.
- *
- * Holds query clients, type filters, parent-connection settings, and
- * optional callbacks for validation, resolution, and path integration.
- * Produced by {@link ContextModuleConfigurator.createConfigAsync} after all
- * registered config builders have run.
- *
- * @see IContextModuleConfigurator — fluent API for populating this config.
- * @see ContextProvider — runtime consumer of this config.
- */
-export interface ContextModuleConfig {
-  /**
-   * Query client options used to fetch, search, and resolve related context items.
-   *
-   * - `get` — retrieves a single context item by ID.
-   * - `query` — searches context items by text and optional type filter.
-   * - `related` — fetches context items related to a given item (used during resolution).
-   */
-  client: {
-    get: QueryCtorOptions<ContextItem, GetContextParameters>;
-    query: QueryCtorOptions<ContextItem[], QueryContextParameters>;
-    related?: QueryCtorOptions<ContextItem[], RelatedContextParameters>;
-  };
-
-  /**
-   * Allowed context type IDs (e.g. `['ProjectMaster', 'Facility']`).
-   *
-   * When set, {@link ContextProvider.validateContext} only accepts items
-   * whose `type.id` matches one of these values (case-insensitive).
-   */
-  contextType?: string[];
-
-  /**
-   * Optional post-query filter applied to the result set returned by
-   * {@link ContextProvider.queryContext}.
-   */
-  contextFilter?: ContextFilterFn;
-
-  /**
-   * Whether to connect the context module to a parent context module.
-   *
-   * When `true` (the default), the provider subscribes to the parent's
-   * `currentContext$` and mirrors changes into its own state.
-   *
-   * @defaultValue `true`
-   */
-  connectParentContext?: boolean;
-
-  /**
-   * When `true`, skips resolving an initial context from the path or parent
-   * during module post-initialization.
-   */
-  skipInitialContext?: boolean;
-
-  /**
-   * Extracts a context ID from a URL path segment.
-   *
-   * Used during initial context resolution and deep-link support.
-   * If not provided, the default GUID-based extractor is used.
-   *
-   * @param path - The URL path to inspect.
-   * @returns The extracted context ID, or `undefined` if none is found.
-   */
-  extractContextIdFromPath?: (path: string) => string | undefined;
-
-  /**
-   * Generates a URL path that embeds the given context item's ID.
-   *
-   * Used by navigation integrations to update the browser URL when
-   * the context changes.
-   *
-   * @param context - The active context item.
-   * @param path - The current URL path.
-   * @returns The updated path, or `undefined` to leave it unchanged.
-   */
-  generatePathFromContext?: (context: ContextItem, path: string) => string | undefined;
-
-  /**
-   * Transforms a user search string and the configured context type into
-   * the query parameters sent to the context API.
-   *
-   * Override this to customise how free-text searches are mapped to the
-   * backend query contract.
-   */
-  contextParameterFn?: (args: {
-    search: string;
-    type: ContextModuleConfig['contextType'];
-  }) => string | QueryContextParameters;
-
-  /**
-   * Custom context resolution strategy.
-   *
-   * Called with `this` bound to the {@link IContextProvider} when a context
-   * item fails validation and the caller requests resolution.
-   *
-   * @param item - The context item to resolve, or `null`.
-   * @returns An observable emitting the resolved context item.
-   */
-  resolveContext?: (
-    this: IContextProvider,
-    item: ContextItem | null,
-  ) => ReturnType<IContextProvider['resolveContext']>;
-
-  /**
-   * Custom context validation strategy.
-   *
-   * Called with `this` bound to the {@link IContextProvider} to decide
-   * whether a candidate context item is acceptable.
-   *
-   * @param item - The context item to validate, or `null`.
-   * @returns `true` if the item is valid.
-   */
-  validateContext?: (
-    this: IContextProvider,
-    item: ContextItem | null,
-  ) => ReturnType<IContextProvider['validateContext']>;
-
-  /**
-   * Resolves the initial context during module post-initialization.
-   *
-   * The default implementation tries to extract a context ID from the
-   * current navigation path, falling back to the parent provider's context.
-   *
-   * @param args - Module reference and instance map.
-   * @returns An observable input emitting the initial context item, or void.
-   */
-  resolveInitialContext?: (args: {
-    // biome-ignore lint/suspicious/noExplicitAny: `AnyModuleInstance | any` intentionally widens to accept any module instance shape for `ref`
-    ref?: AnyModuleInstance | any;
-    modules: ModuleInstance;
-    // biome-ignore lint/suspicious/noConfusingVoidType: `void` here relies on TypeScript's special-cased "void-returning callback accepts any return value" behavior — `undefined` would break assignability of resolver functions that only conditionally emit a `ContextItem`
-  }) => ObservableInput<ContextItem | void>;
-}

package/src/ContextModuleConfigurator.interface.ts

@@ -1,145 +0,0 @@
-import type { Modules, ModuleType } from '@equinor/fusion-framework-module';
-import type { QueryCtorOptions, QueryFn } from '@equinor/fusion-query';
-
-import type { ContextModuleConfig } from './ContextModuleConfig';
-import type { ContextItem, QueryContextParameters, RelatedContextParameters } from './types';
-import type { GetContextParameters } from './client/ContextClient';
-
-/**
- * Callback passed to {@link IContextModuleConfigurator.addConfigBuilder}.
- *
- * Receives the {@link IContextModuleConfigurator} itself and may use its
- * setter methods to populate the context module configuration. The
- * callback may be async.
- */
-export type ContextConfigBuilderCallback = (
-  builder: IContextModuleConfigurator,
-) => void | Promise<void>;
-
-/**
- * Public configurator contract for the context module.
- *
- * Consumers call {@link addConfigBuilder} to register one or more
- * {@link ContextConfigBuilderCallback} functions that will run during
- * module initialization to populate the {@link ContextModuleConfig}, using
- * the fluent setter methods declared below.
- */
-export interface IContextModuleConfigurator {
-  /**
-   * Registers a configuration callback that receives this configurator.
-   *
-   * Multiple builders can be added; they execute sequentially against the
-   * same configurator instance, so later calls win when they touch the
-   * same field.
-   *
-   * @param init - Builder callback invoked during module initialization.
-   */
-  addConfigBuilder: (init: ContextConfigBuilderCallback) => void;
-
-  /**
-   * Requires a module instance by its registered key or name.
-   *
-   * Only resolvable from within a {@link ContextConfigBuilderCallback} —
-   * throws if called before module initialization has started.
-   *
-   * @param module - The key or name of the module to resolve.
-   * @returns A promise that resolves to the requested module instance.
-   */
-  requireInstance<TKey extends string = Extract<keyof Modules, string>>(
-    module: TKey,
-  ): Promise<ModuleType<Modules[TKey]>>;
-  requireInstance<T>(module: string): Promise<T>;
-
-  /**
-   * Sets the context type for the current configuration.
-   *
-   * @param type - The context type to assign, as defined by `ContextModuleConfig['contextType']`.
-   */
-  setContextType(type: ContextModuleConfig['contextType']): void;
-
-  /**
-   * Sets the context filter function for the configuration.
-   *
-   * @param filter - A function that determines whether a context should be included, as defined by `ContextModuleConfig['contextFilter']`.
-   */
-  setContextFilter(filter: ContextModuleConfig['contextFilter']): void;
-
-  /**
-   * Sets the function or configuration used to connect to a parent context.
-   *
-   * @param connect - The function or configuration that defines how to connect to the parent context.
-   */
-  connectParentContext(connect: ContextModuleConfig['connectParentContext']): void;
-
-  /**
-   * Sets the function used to provide context parameters for the module configuration.
-   *
-   * @param fn - A function conforming to the `contextParameterFn` type defined in `ContextModuleConfig`.
-   */
-  setContextParameterFn(fn: ContextModuleConfig['contextParameterFn']): void;
-
-  /**
-   * Sets the function used to validate the context within the configuration.
-   *
-   * @param fn - A function that implements the `validateContext` signature from `ContextModuleConfig`.
-   */
-  setValidateContext(fn: ContextModuleConfig['validateContext']): void;
-
-  /**
-   * Sets the function used to resolve the context for the module configuration.
-   *
-   * @param fn - A function that defines how the context should be resolved, conforming to the `resolveContext` type from `ContextModuleConfig`.
-   */
-  setResolveContext(fn: ContextModuleConfig['resolveContext']): void;
-
-  /**
-   * Sets the function responsible for extracting the context ID from a given path.
-   *
-   * @param fn - A function that defines how to extract the context ID from a path.
-   *             This function should match the type defined in `ContextModuleConfig['extractContextIdFromPath']`.
-   */
-  setContextPathExtractor(fn: ContextModuleConfig['extractContextIdFromPath']): void;
-
-  /**
-   * Sets the function responsible for generating a path from the context.
-   *
-   * @param fn - A function that takes a context and generates a corresponding path.
-   */
-  setContextPathGenerator(fn: ContextModuleConfig['generatePathFromContext']): void;
-
-  /**
-   * Sets the function used to resolve the initial context during module post-initialization.
-   *
-   * @param fn - A function that returns an observable input emitting the initial context item.
-   *             The default resolver extracts a context ID from the navigation path, falling
-   *             back to the parent provider's current context.
-   */
-  setResolveInitialContext(fn: ContextModuleConfig['resolveInitialContext']): void;
-
-  /**
-   * Sets the context client configuration for fetching context items.
-   *
-   * This method allows you to provide custom query functions or query constructor options
-   * for retrieving single context items (`get`), querying multiple context items (`query`),
-   * and optionally fetching related context items (`related`). Each query can be provided
-   * as either a function or a configuration object. The expiration time for cached results
-   * can also be specified.
-   *
-   * @param client - An object containing the query functions or options for `get`, `query`, and optionally `related` context items.
-   * @param expire - Optional. The expiration time (in milliseconds) for cached query results. Defaults to 1 minute.
-   */
-  setContextClient(
-    client: {
-      get:
-        | QueryFn<ContextItem, GetContextParameters>
-        | QueryCtorOptions<ContextItem, GetContextParameters>;
-      query:
-        | QueryFn<ContextItem[], QueryContextParameters>
-        | QueryCtorOptions<ContextItem[], QueryContextParameters>;
-      related?:
-        | QueryFn<ContextItem[], RelatedContextParameters>
-        | QueryCtorOptions<ContextItem[], RelatedContextParameters>;
-    },
-    expire?: number,
-  ): void;
-}