Settings dialog

@/components/kloq/settings is its own module because it is genuinely optional: the calendar works with no settings surface at all, and a host with its own preferences screen wants the KloqPreferences model without pulling in a dialog it will never render.

The dialog owns no settings

SettingsDialog is a value / onChange pair over a plain KloqPreferences object and nothing else — no context, no localStorage, no writes into <Kloq>. That is forced by the architecture rather than chosen: "show weekends" and "start week on" are props on the calendar, so the only honest thing a settings surface can do is report intent upward and let the host pass it back down. A dialog that secretly mutated the calendar would be a second source of truth, and the two would drift the first time the host changed a prop.

import { Kloq, type KloqView } from "@/components/kloq";
import {
  SettingsDialog,
  DEFAULT_PREFERENCES,
  type KloqPreferences,
} from "@/components/kloq/settings";

const [prefs, setPrefs] = useState<KloqPreferences>(DEFAULT_PREFERENCES);
const [open, setOpen] = useState(false);
const [view, setView] = useState<KloqView>("week");

const changePrefs = (next: KloqPreferences) => {
  if (next.showWeekends !== prefs.showWeekends)
    setView(next.showWeekends ? "week" : "workweek");
  setPrefs(next);
};

<>
  <SettingsDialog open={open} onOpenChange={setOpen}
    value={prefs} onChange={changePrefs} />
  <Kloq
    view={view}
    onViewChange={(next) => {
      setView(next);
      if (next === "week" || next === "workweek")
        setPrefs((current) => ({ ...current, showWeekends: next === "week" }));
    }}
    weekStartsOn={prefs.weekStartsOn}
    showWeekNumbers={prefs.showWeekNumbers}
    showDeclinedEvents={prefs.showDeclinedEvents}
    navigationKeys={prefs.navigationKeys}
    locale={prefs.language || undefined}
  />
</>

The KloqPreferences model

Flat and serializable on purpose: persist the whole object under one key. Every field maps to either a <Kloq> prop or a host behaviour, and nothing is optional — a settings screen with tri-state values renders switches that are neither on nor off. DEFAULT_PREFERENCES matches the calendar's own defaults.

SettingsDialogProps

Four panes — "general", "accounts", "conferencing", "notifications" (SettingsSection; defaultSection picks which opens first). Beyond the value / onChange pair, the props follow one honesty rule: a button with nothing behind it isn't rendered. Omit onAddAccount and there is no "Add calendar account" button — the package owns no OAuth flow, so a connect button that couldn't connect would be a lie.

Accounts as first-class

Accounts are the one exception to "the dialog owns nothing" — they already have a registry (registerCalendarSources), and the account rows write through it unless the host passes handlers: the same controlled/uncontrolled split as everything else. The module re-exports the grouping's helpers so a host's own settings screen can build the same rows: findAccount, defaultAccount, setDefaultAccount, disconnectAccount, providerLabel, conferencingLabel, accountDefaultCalendar, setAccountDefaultCalendar, resolveDefaultCalendar, and setAccountConferencing.

SegmentedChoice

Every "pick one of a few" control in the dialog is SegmentedChoice — a segmented control that is a real radio group: one tab stop, arrow keys move the choice, and assistive tech hears "radio, 2 of 3". It is exported for hosts building matching settings UI. For 2–5 options it is the better control: every choice is visible and it costs one click, not two.