Feature flags

An application customizes its behavior mostly through the general object of its JSON configuration (a top-level general key, or a general customJSON side-file) — read once through AppStore.general(). This page is the one place that lists every key of general.features/general.feedback and says which ones a consumer actually checks, since a name in the type is not a promise that anything reads it.

Minimal example

Opening the live editor — an imperative dialog, like every other dialog in this library.

import { Component, inject, Injector } from "@angular/core";
import { FeatureFlags } from "@sinequa/atomic-angular";

@Component({
  selector: "sample-component",
  template: `<button type="button" (click)="openFeatureFlags()">Feature flags</button>`,
})
export class SampleComponent {
  private readonly injector = inject(Injector);

  protected openFeatureFlags() {
    FeatureFlags.call(undefined, { injector: this.injector });
  }
}

How it works

FeatureFlagsDialogComponent reads AppStore.general() and lets an administrator edit it live: every edit rewrites the whole general object back onto the store through the same source it was read from (the general customJSON if the app has one, otherwise inline data.general), so unknown keys the dialog does not know about survive the round-trip. A non-administrator still gets the dialog, with an "admin only" notice instead of the editor — there is no separate access check to remember on the caller's side.

Changes apply to the current session only — nothing is persisted back to the backend configuration — which is what makes the tool suitable for testing a behavior without touching the deployment.

Options

general.features — boolean flags

general.feedback — six independent switches

Pitfalls

What's next