Configuration

Configuration lives on one manifest, the Blueprint, addressed by dotted stone.*keys. It is assembled once before the first event and then frozen, so behaviour depends on what the manifest says, never on when a value happened to be set.

#Setting configuration

Pass options to @StoneApp (or into defineStoneApp). Keep your own settings under an app namespace so they never collide with framework or module keys.

import { StoneApp } from '@stone-js/core'

@StoneApp({
  name: 'tasks',
  // Your own namespace under stone.* is yours to use.
  tasks: { pageSize: 20, allowGuests: false }
})
export class Application {}

import { defineStoneApp } from '@stone-js/core'

export const appConfig = {
  stone: { name: 'tasks', tasks: { pageSize: 20, allowGuests: false } }
}

export const App = defineStoneApp(appConfig, [/* blueprints */])

#Reading configuration

The config store is injected like any service and read by the same dotted keys, always with a default so a missing key never surprises you.

constructor ({ config }) {
  this.pageSize = config.get('stone.tasks.pageSize', 20)
  this.allowGuests = config.get<boolean>('stone.tasks.allowGuests', false)
}

#Environment-driven config

Values that differ per deployment come from the environment, read through typed getters and folded into the manifest, so the domain never reads process.env directly.

import { getNumber } from '@stone-js/env'

export const appConfig = {
  stone: { tasks: { pageSize: getNumber('PAGE_SIZE', 20) } }
}