Configuration keys
Every key of AppGlobalConfig — what reads it, what it defaults to, and the three that nothing reads at all.
The same object shape whether you pass it to createAtomicClient() or to setGlobalConfig(). Every key is
optional. Configuration is the guide; this is the list.
Identity of the backend
Prop
Type
Authentication
Prop
Type
These three are not settable on a client
AtomicClientConfig excludes useCredentials, useSSO and useSAML on purpose: they are getters defined on
globalConfig alone, so a client has nowhere to put them. Pass an AuthMode.
auth — the authentication knobs
Prop
Type
Behaviour
Prop
Type
Keys nothing reads
Present in the type, accepted by setGlobalConfig, and never consulted by any code path in the library. Listed
because their names suggest otherwise.
| Key | What its name suggests | Reality |
|---|---|---|
loginPath | Where to redirect an unauthenticated user | Defaults to /login and is read by nothing. Routing is yours; use recoverFromUnauthorized or the unauthorized event. |
logLevel | The logger's verbosity | Not read. Set the level with configureLogger({ level }). |
createRoutes | The library declares routes | Not read. Defaults to false and stays inert either way. |
Your own keys
The type is generic, so application keys are first-class rather than tolerated:
import { globalConfig } from "@sinequa/atomic";
import type { AppGlobalConfig } from "@sinequa/atomic";
type MyConfig = AppGlobalConfig<{ featureFlags: string[] }>;
const flags = (globalConfig as Partial<MyConfig>).featureFlags ?? [];Unknown keys read back as unknown rather than any — deliberately. They used to be any, which disabled type
checking on the whole object, and that is how a key nobody ever read survived in there for years.