otter-new-config

Otter New Config

When introducing new config flags (feature toggles, URLs, enums, numeric thresholds) in an Otter workspace, follow this decision process to ensure safe defaults and correct scoping.

When to Use

• Adding runtime configuration to a component
• Introducing new config flags (feature toggles, URLs, enums, thresholds)
• Deciding whether a config belongs at component or app level
• Determining CMS exposure for a config property

Scope Decision

Who consumes this config?
├── Multiple libraries/packages → GLOBAL (app-level runtime config)
├── Single component only → COMPONENT-LEVEL config
└── App-wide behavior toggle → GLOBAL (app-level runtime config)

Explicitly state the scope decision and rationale, then ask the user to confirm before proceeding with implementation.

Implementation

For component-level config, use the @o3r/configuration:add-config schematic to add configuration to an existing component:

ng g @o3r/configuration:add-config --path="/path/to/the/component/class.ts"

Options:

• --useSignal — use a config signal instead of observable
• --exposeComponent — expose the component in CMS metadata (default: true)

This generates the *-config.ts file, wires up the ConfigurationObserver (or signal), and registers the component with the configuration service. Do not create these files manually.

For global (app-level) config, add properties to the existing AppRuntimeConfiguration interface — no schematic needed.

Safe-Default Discipline

Every new config flag must have a safe default that preserves current behavior when not explicitly set.

Type	Default Rule	Naming Convention
Feature toggle	false (feature OFF)	enableX, showX, allowX
URL/endpoint	'' (empty string)	Suffixed with Url
Enum/mode	Value that matches the component's current behavior (introducing the config alone must not change what the user sees)	Suffixed with Mode
Numeric threshold	Existing value or safe boundary	Descriptive noun
Label/text	Use CMS/i18n, NOT runtime config	n/a