@speles7172/config-console

The settings page, and the hook the rest of the application reads them through.

Two halves of one idea. <ConfigConsole> is what an administrator edits: every setting the application declares, grouped by category, each with the editor its type deserves. <ConfigProvider> is how the rest of the frontend acts on what they changed, decoded by the same functions the backend uses.

npm install @speles7172/config-console

React 18 or 19. Browser-only — it queries nothing itself.

The console

import { ConfigConsole } from '@speles7172/config-console';
import '@speles7172/config-console/styles.css';

// Module scope, not inline in JSX — see "Hold the transport still" below.
const transport = {
  list: () => fetch('/api/config').then((r) => r.json()),
  save: (input) => fetch('/api/config/value', { method: 'PUT', body: JSON.stringify(input) }),
  create: (draft) => fetch('/api/config', { method: 'POST', body: JSON.stringify(draft) }),
  remove: ({ key }) => fetch(`/api/config/${key}`, { method: 'DELETE' }),
};

<ConfigConsole transport={transport} theme="dark" />;

Every capability is optional and inferred: a console given no remove renders no delete button, and a transport with list alone is a read-only view of the configuration. The alternative — a button that always fails — is worse.

Back those endpoints with @speles7172/config-client; store.views() is exactly what list should return.

What it renders

A number gets a number box with the declared bounds. A boolean gets a checkbox. A date gets a date picker, a datetime gets a local date-and-time picker, a list gets an editable key/value table, and a reference gets a searchable select over the application's own records.

Every field is a @speles7172/controls control. That is not tidiness: a boolean edited here and a boolean edited on the application's own forms should be the same control.

References to your own records

const transport = {
  list: () => fetch('/api/config').then((r) => r.json()),
  options: (refType) =>
    refType === 'user'
      ? { search: (q) => fetch(`/api/options/users?${new URLSearchParams(q)}`).then((r) => r.json()) }
      : undefined,
};

Called with the definition's refType, and answers an option source or undefined. The console never learns what a user is — which is the whole of what replaced the reference implementation's hard-coded user type.

Reading the configuration everywhere else

import { ConfigProvider, useConfig, useFeatureFlag } from '@speles7172/config-console';

const load = () => fetch('/api/config/entries').then((r) => r.json());

<ConfigProvider load={load} schema={schema}>
  <App />
</ConfigProvider>;

function Invoices() {
  const config = useConfig();
  const scanning = useFeatureFlag('FEATURE_GATES', 'invoice_scan');

  return <Form dueInDays={config.number('PAYMENT_TERMS_DAYS', 30)} scanning={scanning} />;
}

Reads never suspend and never throw. While the first load is in flight, every setting reads as its declared default — which is the honest answer rather than a spinner: a feature flag has a value before the network does, and blocking a page on the configuration request is how a slow endpoint becomes a blank screen.

Styling

import '@speles7172/config-console/styles.css';

Optional — the console renders semantic HTML with configc- class names and no styling dependency. The stylesheet includes @speles7172/controls' own, because every field on the page is one of its controls; importing both is harmless.

Re-theme by overriding the custom properties on .configc. theme="dark" picks the dark palette; theme="auto" follows prefers-color-scheme, which is right only when the host does too.

Traps

Hold the transport still. The console keys its effects on the object's identity, so an object literal written inline in JSX is a new transport on every render and therefore an endless reload. Put it in a module constant or behind useMemo. Same rule every console in this repository follows.

The endpoint is the security seam, and this package applies no access control. What crosses it is a key and a value, never a table and never SQL — but the settings behind it are the ones the whole application runs on. Put every method behind whatever your application means by "administrator".

Filtering happens in the browser, deliberately. A configuration table is hundreds of rows; the whole thing arrives in one request. A network round trip between a keystroke and a filtered list would make "settings mentioning payment" slower than reading the list.

A save reloads. Showing the value the browser sent rather than the value the server stored hides every case where the far side normalises, truncates or refuses part of it.

License

MIT