//! Settings, described rather than built.
//!
//! <!-- wiki: quasi-overview -->
//!
//! # The shape
//!
//! - `GET /settings` — Appearance.
//! - `GET /settings/{section}` — one section.
//! - `POST /settings/config/{key}` — write one config key, under `value`.
//!
//! The section is an address rather than module state, per decision 2. Unlike
//! the projects filters and the weekly review's week it needs no carrying: a
//! write answers with the section it happened in, and the handler knows which
//! that is from the key.
//!
//! Appearance, Notifications and Planning & Review are `user_config` keys: rows
//! in a table this app owns, declared as a closed set in
//! [`crate::config_key::CONFIG`]. So the whole of this screen's writing is one
//! route, `POST /settings/config/{key}`, refused by the same `ensure_known` the
//! Tauri command is refused by. A screen that is a key/value editor should read
//! as one.
//!
//! Email, Sync, Sharing and About are sections of their own; see [`email`],
//! [`sync`], [`sharing`] and [`about`]. Import & Export is a screen of its own
//! at `/data`; see [`Section::at`].
//!
//! # A host fact belongs on `AppState`
//!
//! A route handler is `fn(&AppState, Request)`, so a section reading the host
//! rather than the app has nothing to read. The general answer is not quasi's
//! to give: `S` is the app's own state, and a host fact a described screen
//! needs is a host fact the app resolves at startup and holds. The theme search
//! path is
//! [`AppState::theme_dirs`](crate::state::AppState::theme_dirs); the version
//! and the platform are held the same way.
//!
//! What does not yield to it is a fact that is only true at the moment it is
//! asked, such as whether biometry is enrolled. That is filed. A save dialog is
//! not one of them: the route answers with the file and the host puts it
//! somewhere, so the control never asks.
//!
//! The admin half of sharing stays host-bound. The member half is here, because
//! being added to a group takes no write from the person being added.

// Handlers take their request by value because `quasi_router::Handler` is a
// plain `fn(&S, Request)` pointer, so the signature is the router's and not a
// choice made here. Same allow, for the same reason, as quasi-axum's tests.
#![allow(clippy::needless_pass_by_value)]

use std::collections::HashMap;

use quasi_declare::declare;
use quasi_notifs::pane;
use quasi_router::layout::{Contrast, ThemeVariant};
use quasi_router::screen::{Choice, ThemeChoice};
use quasi_router::{Action, Node, RegionKind, Response, RouteError, Router, Slot};

use crate::notifs::NOTIFS;

use crate::commands::{all_config, write_config};
use crate::state::AppState;

pub(crate) mod about;
pub(crate) mod email;
pub(crate) mod sharing;
pub(crate) mod sync;

#[cfg(test)]
mod tests;

/// The region a section's contents answer at.
///
/// Named once because several things aim at it: the screen that builds it, and
/// every section that answers itself back after a write.
const SECTION_REGION: &str = "settings-content";

/// A section of the screen: its address, its heading, and the keys it writes.
struct Section {
    /// The last path segment, and what the sidebar sends.
    slug: &'static str,
    /// What the section is called.
    title: &'static str,
    /// Where the row goes, when that is not a section of this screen.
    ///
    /// `None` for the ordinary case, which is `/settings/{slug}` and a pane
    /// this module draws.
    ///
    /// `Some` is a row that navigates away, and Import & Export is the one: it
    /// is [`super::data`], a whole screen at `/data`. Serving `/data` under
    /// `/settings/data` instead would move a finished screen for the sake of
    /// the sidebar's shape.
    ///
    /// What it costs: the sidebar belongs to this screen, so following such a
    /// row leaves it behind and `/data` draws its own band and no nav.
    ///
    /// Two consequences hold wherever this is read. A row that leaves is never
    /// [`Row::current`], because this screen is not showing it. And
    /// [`section_of`] does not answer for one, so `/settings/data` is a 404
    /// rather than Appearance drawn under somebody else's name.
    at: Option<&'static str>,
}

/// The sections that are described, in the sidebar's order.
///
/// A section that cannot be drawn is absent rather than disabled: a control
/// that is drawn and does nothing is worse than a control that is not drawn.
const SECTIONS: [Section; 8] = [
    Section {
        slug: "appearance",
        title: "Appearance",
        at: None,
    },
    Section {
        slug: "notifications",
        title: "Notifications",
        at: None,
    },
    Section {
        slug: "planning",
        title: "Planning & Review",
        at: None,
    },
    // See `email`: the account is app data; only the OAuth handshake is
    // host-bound.
    Section {
        slug: "email",
        title: "Email",
        at: None,
    },
    // Described in full as `super::data` and not a section of this screen; see
    // `Section::at`.
    Section {
        slug: "data",
        title: "Import & Export",
        at: Some("/data"),
    },
    // Host facts, held on `AppState` at startup. See `about`.
    Section {
        slug: "about",
        title: "About",
        at: None,
    },
    // Local per command, whatever the file's await count suggests; see `sync`.
    Section {
        slug: "sync",
        title: "Sync",
        at: None,
    },
    // Reads the local group directory synckit writes down. See `sharing`.
    Section {
        slug: "sharing",
        title: "Sharing",
        at: None,
    },
];

/// What the app falls back to when a key has never been written.
///
/// Stated once here rather than at each read. The JS states each of these
/// inline at its own call site — `|| 'system'`, `|| '15'`, `|| '9'` — which is
/// how `event_lead_minutes` came to have its default written in three places.
fn default_for(key: &str) -> &'static str {
    match key {
        "theme" => "system",
        "event_lead_minutes" => "15",
        "work_start_hour" => "9",
        "work_end_hour" => "17",
        // Both nudges are on unless someone turned them off, which is what the
        // JS's `!== 'disabled'` says the long way round.
        _ => "enabled",
    }
}

/// The value a key currently holds.
fn value_of<'a>(config: &'a HashMap<String, String>, key: &str) -> &'a str {
    config.get(key).map_or_else(
        || {
            // Borrowed from a `'static`, which outlives `'a`.
            default_for(key)
        },
        String::as_str,
    )
}

declare! {
    /// A select over a fixed set of values, holding the one in force.
    ///
    /// It writes as soon as it changes and stands on its own: [`Field::writes`]
    /// on a field in a panel, which is what finding `14612ed8` was closed for
    /// and what this screen is the first consumer of. The JS says the same
    /// thing with `data-change` on a bare `<select>` with no form around it;
    /// wrapping these in a [`Node::Form`] would describe a submit button that
    /// does not exist.
    shape choice_field(
        config: &HashMap<String, String>,
        key: &'static str,
        label: &str,
        choices: Vec<Choice>,
    ) -> Field;

    field Select key label {
        options choices;
        value value_of(config, key);
        writes Action::post("/settings/config/{key}");
    }
}

/// The themes on offer, in the order the resolver read them out.
///
/// A supplier because the mapping is a closure. It hands back [`ThemeChoice`],
/// which is not a vocabulary type, so it costs the population nothing.
///
/// # Nothing here sorts, and nothing here groups
///
/// [`makeover::theme_options`] returns the list already ordered by variant and
/// then by measured contrast, which is the order the renderer reads the groups
/// out of. Re-sorting here would be this app deciding a question it cannot see
/// the inputs to, and it is the duplication that put three different orders in
/// three apps in the first place.
///
/// The list is read through [`AppState::theme_dirs`], which is the whole reason
/// the Appearance section exists at all — see the module header.
fn theme_choices(app: &AppState) -> Vec<ThemeChoice> {
    makeover::theme_options(&app.theme_dirs)
        .into_iter()
        .map(|theme| {
            ThemeChoice::new(
                theme.id,
                theme.name,
                variant_of(theme.variant),
                tier_of(theme.contrast),
            )
        })
        .collect()
}

declare! {
    /// The theme picker.
    ///
    /// A described theme picker rather than a select of grouped options:
    /// [`Field::theme`]'s kind, whose entries carry their variant and their
    /// measured contrast tier as values rather than as prose. The grouping
    /// comes back, and the tier arrives with it — a fact this app never had,
    /// because deriving it means resolving every theme's colours and this
    /// screen only ever had the names.
    ///
    /// `makeover::FOLLOW` rather than a literal: the sentinel this app stores
    /// is the one the crate that resolves it reads back, and spelling it here
    /// is how the two drift.
    shape theme_field(app: &AppState, config: &HashMap<String, String>) -> Field;

    field Theme "theme" "Theme" {
        themes theme_choices(app);
        following Choice::new(makeover::FOLLOW, "Follow System");
        value value_of(config, "theme");
        writes Action::post("/settings/config/theme");
    }
}

/// `makeover`'s variant as the description layer's own.
///
/// The seam the layering costs, and it is three arms. `makeover-layout` takes
/// no dependencies by charter, so it cannot name `makeover::Variant`, and a
/// renderer that groups a picker needs the groups as values. Exhaustive rather
/// than wildcarded on purpose: a fourth ambient mode should stop the build here
/// rather than quietly file itself under dark.
fn variant_of(variant: makeover::Variant) -> ThemeVariant {
    match variant {
        makeover::Variant::Light => ThemeVariant::Light,
        makeover::Variant::Dark => ThemeVariant::Dark,
        makeover::Variant::HighContrast => ThemeVariant::HighContrast,
    }
}

/// `makeover`'s measured tier as the description layer's own.
///
/// [`variant_of`]'s twin, for its reason and with its exhaustiveness.
fn tier_of(tier: makeover::ContrastTier) -> Contrast {
    match tier {
        makeover::ContrastTier::Low => Contrast::Low,
        makeover::ContrastTier::Standard => Contrast::Standard,
        makeover::ContrastTier::High => Contrast::High,
    }
}

declare! {
    /// Appearance.
    ///
    /// # The second finding
    ///
    /// **Import and Export are absent because a file dialog is not an
    /// address.** `themes.importTheme` opens a native open-dialog and
    /// `themes.exportTheme` a native save-dialog, and both then call a command
    /// with the path the user picked. `FieldKind::File` covers picking a file
    /// to *submit*, which is the import half and would work here if the write
    /// route existed; the export half is a control that asks the host where to
    /// put something and then acts, and nothing in the vocabulary names that.
    ///
    /// Left out rather than dangled, to the standard the contacts port set.
    /// Filed on quasicoherent alongside the About section's host facts, because
    /// it is the same finding wearing different clothes: the description can
    /// say what to do and cannot reach what the host knows.
    ///
    /// # There is no hint any more, because there is nothing left to apologise for
    ///
    /// There was one, and it said a named theme took effect the next time
    /// GoingsOn started. That was true while the sheet held one theme and the
    /// document linked it once. It holds every theme now, keyed by a root
    /// attribute (`super::theming`), and picking one sets the attribute, so
    /// every choice on this control lands at once and none of them is worth
    /// explaining.
    ///
    /// Deleted rather than reworded. The remaining sentence would have said
    /// that Follow System follows the system, which the option's own label
    /// says.
    shape appearance(app: &AppState, config: &HashMap<String, String>) -> Vec<Node>;

    section "Appearance";
    include theme_field(app, config);
}

/// The lead times the Events tab indicator offers.
///
/// The default is marked in the label because the control cannot otherwise say
/// which value it would hold if nobody had chosen. The JS marks the same one
/// the same way.
fn lead_choices() -> Vec<Choice> {
    [5, 10, 15, 30, 60]
        .into_iter()
        .map(|minutes| {
            let label = if minutes == 60 {
                "1 hour".to_owned()
            } else {
                format!("{minutes} minutes")
            };
            let label = if minutes == 15 {
                format!("{label} (default)")
            } else {
                label
            };
            Choice::new(minutes.to_string(), label)
        })
        .collect()
}

declare! {
    /// Notifications.
    ///
    /// Two halves, and the point of the section is that they are two.
    ///
    /// The first is generated: [`quasi_notifs::pane`] emits a control per
    /// declared kind straight from [`NOTIFS`], so adding a kind adds its
    /// settings and there is no list here to keep in step. That replaced a
    /// hand-built section, which is what task `07830eb5` was for. Every
    /// generated control writes to one route under its own key, and the
    /// section heading the generator emits per category is why nothing is
    /// added around it: "Reminders" is the category GoingsOn declared.
    ///
    /// The shipped JavaScript screen renders the same half from the same
    /// registry, over [`crate::commands::list_notification_kinds`], because
    /// this screen is behind the `quasi` feature and a pane nobody can reach is
    /// not somewhere onboarding can point (`b6c634fb`). It writes the same
    /// generated keys, so the flip deletes it rather than migrating it.
    ///
    /// The second is `event_lead_minutes`, which stays hand-written because it
    /// is not a notification setting at all: it colours a dot on the Events
    /// tab. It sat alone under this heading before the generated half arrived,
    /// and the risk the adoption had to avoid was folding it into the
    /// event-reminder kind by name-similarity. Generated keys are dotted and
    /// this one is not, so they cannot collide in the store; what they could
    /// still do is read alike in the pane, which is what the sub-heading and
    /// the hint are for.
    ///
    /// It sat in a shape of its own while this one had to `extend` a second
    /// list onto its own; a panel says both halves in one body, so that shape
    /// is gone.
    shape notifications(config: &HashMap<String, String>) -> Vec<Node>;

    section "Notifications";
    include pane::pane(&NOTIFS, config, &Action::post("/settings/notifications"));

    section "Events tab";
    field Select "event_lead_minutes" "Event indicator lead time" {
        options lead_choices();
        value value_of(config, "event_lead_minutes");
        hint "How far in advance the Events tab dot turns yellow. This is the \
              indicator, not a notification.";
        writes Action::post("/settings/config/event_lead_minutes");
    }
}

/// Every hour of the day, as the clock writes it.
///
/// Twelve-hour with AM and PM. A description that emitted `09:00` would be
/// answering a question about the user's locale that nothing here asked.
fn hour_choices() -> Vec<Choice> {
    (0..24)
        .map(|hour| {
            let label = match hour {
                0 => "12:00 AM".to_owned(),
                1..=11 => format!("{hour}:00 AM"),
                12 => "12:00 PM".to_owned(),
                _ => format!("{}:00 PM", hour - 12),
            };
            Choice::new(hour.to_string(), label)
        })
        .collect()
}

/// Whether a switch of this kind is on.
fn on_off() -> Vec<Choice> {
    vec![
        Choice::new("enabled", "Enabled (default)"),
        Choice::new("disabled", "Disabled"),
    ]
}

declare! {
    /// Planning and review.
    ///
    /// **Two controls answering one question are two controls.** Work hours is
    /// a start and an end, and the description has one label per field, so it
    /// says "Work day starts" and "Work day ends" rather than pairing them into
    /// a row. A group of fields inside a form is furniture, which the
    /// vocabulary declines to state.
    shape planning(config: &HashMap<String, String>) -> Vec<Node>;

    section "Planning & Review";

    include choice_field(config, "work_start_hour", "Work day starts", hour_choices())
        .hint("Controls when plan and review nudge dots appear.");
    include choice_field(config, "work_end_hour", "Work day ends", hour_choices());
    include choice_field(config, "plan_nudges", "Plan nudges", on_off());
    include choice_field(config, "review_nudges", "Review nudges", on_off());
}

/// The section under this slug, or 404.
///
/// A row that navigates away is in [`SECTIONS`] for the sidebar's sake and is
/// not a section of this screen, so it does not answer here. Without that,
/// `/settings/data` would fall through [`screen`]'s match and draw Appearance
/// under the Import & Export heading.
fn section_of(slug: &str) -> Result<&'static Section, RouteError> {
    SECTIONS
        .iter()
        .find(|section| section.at.is_none() && section.slug == slug)
        .ok_or_else(|| RouteError::not_found("no such settings section"))
}

/// Which section a config key belongs to, so a write can answer with it.
///
/// A match on the key rather than a param the control carries: the section a
/// setting sits in is a fact about the setting, and threading it through every
/// action would be the screen telling the handler something the handler already
/// knows. An unknown key never reaches here — [`write_config`] refuses it first.
fn section_for_key(key: &str) -> &'static str {
    match key {
        "event_lead_minutes" => "notifications",
        "work_start_hour" | "work_end_hour" | "plan_nudges" | "review_nudges" => "planning",
        _ => "appearance",
    }
}

/// Where a sidebar row leads.
///
/// A section of this screen is `/settings/{slug}`; a row that navigates away
/// carries its own address. See [`Section::at`].
fn section_path(section: &Section) -> String {
    section
        .at
        .map_or_else(|| format!("/settings/{}", section.slug), ToOwned::to_owned)
}

/// Whether this row is the one the pane is showing.
///
/// `current` and not `selected`: this is the app's own pointer at what the pane
/// is showing rather than a tick the reader made. A row that leaves is never
/// current; see [`Section::at`].
fn is_showing(item: &Section, section: &Section) -> bool {
    item.at.is_none() && item.slug == section.slug
}

/// The section the screen is showing, and the body it draws.
struct Showing {
    section: &'static Section,
    body: Vec<Node>,
}

/// The section under this slug, and the body it draws.
///
/// The read is the handler's, which is what converting this screen meant: four
/// of the seven sections read the database or the sync client, two of them
/// fallibly, and a description says what is on the screen rather than fetching
/// it.
fn read(state: &AppState, slug: &str) -> Result<Showing, RouteError> {
    let section = section_of(slug)?;
    let config = all_config(state).map_err(|error| RouteError::internal(error.to_string()))?;
    let body = match section.slug {
        "notifications" => notifications(&config),
        "planning" => planning(&config),
        "email" => email::pane(&email::accounts(state)?),
        "about" => about::pane(state),
        "sync" => sync::pane(state),
        "sharing" => sharing::sharing_pane(&sharing::read(state)?),
        _ => appearance(state, &config),
    };
    Ok(Showing { section, body })
}

declare! {
    /// The whole screen, showing one section.
    ///
    /// `Sidebar` for what it is named for: the sidebar is the section nav.
    pub(super) shape screen(section: &Section, body: Vec<Node>) -> Screen;

    screen sidebar_content "Settings" {
        at_place super::shell::SETTINGS;

        region "settings-nav" as Sidebar {
            list {
                for item in SECTIONS.iter() {
                    row item.title {
                        current is_showing(item, section);
                        activate to get section_path(item);
                    }
                }
            }
        }

        region SECTION_REGION as Pane {
            extend body;
        }
    }
}

/// One section, drawn and answered with.
pub(super) fn showing(state: &AppState, slug: &str) -> Result<Response, RouteError> {
    let showing = read(state, slug)?;
    Ok(screen(showing.section, showing.body).into())
}

/// Appearance, which is where the screen opens.
fn index(state: &AppState, _request: quasi_router::Request) -> Result<Response, RouteError> {
    showing(state, "appearance")
}

/// Turn the launch-time update check on or off.
///
/// Its own route rather than a `user_config` key, because the value is not in
/// the database: `preferences.json` is read before a connection exists, which
/// is what `commands::preferences` is for. See [`about`].
fn set_update_check(
    state: &AppState,
    request: quasi_router::Request,
) -> Result<Response, RouteError> {
    let on = request.payload.get(about::UPDATE_CHECK).unwrap_or_default() != "disabled";
    let said = about::write(state, on)?;
    Ok(Response::fragment(
        SECTION_REGION,
        Node::Region(Slot::new(SECTION_REGION, RegionKind::Pane).extend(about::pane(state))),
    )
    .toast(quasi_router::layout::Tone::Success, said))
}

/// The Sync section, answered back after a write to it.
///
/// Its own three routes rather than arms of the config writer, because these
/// are `sync_state` rows read by the sync engine rather than `user_config`
/// keys. See [`sync`].
fn sync_pane(state: &AppState, said: String) -> Result<Response, RouteError> {
    Ok(Response::fragment(
        SECTION_REGION,
        Node::Region(Slot::new(SECTION_REGION, RegionKind::Pane).extend(sync::pane(state))),
    )
    .toast(quasi_router::layout::Tone::Success, said))
}

/// The Sharing pane, re-read, with a word about what just happened.
///
/// Whole-pane rather than a narrower region, because every one of these writes
/// lands in the queue list and one of them lands in the group list too.
fn sharing_pane(state: &AppState, said: &str) -> Result<Response, RouteError> {
    Ok(Response::fragment(
        SECTION_REGION,
        Node::Region(
            Slot::new(SECTION_REGION, RegionKind::Pane)
                .extend(sharing::sharing_pane(&sharing::read(state)?)),
        ),
    )
    .toast(quasi_router::layout::Tone::Success, said))
}

/// Queue a new group.
fn queue_group(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::create_group(state, &request)?;
    sharing_pane(state, said)
}

/// Queue an add-member.
fn queue_member(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::add_member(state, &request)?;
    sharing_pane(state, said)
}

/// Take a queued admin write back out.
fn cancel_queued(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::cancel(state, &request)?;
    sharing_pane(state, said)
}

/// Queue a fresh invite code.
fn queue_invite(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::create_invite(state, &request)?;
    sharing_pane(state, said)
}

/// Queue a revoke, from the group's list or from the confirmations section.
fn queue_revoke(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::revoke_invite(state, &request)?;
    sharing_pane(state, said)
}

/// Queue a confirm: admit the holder of the key on this invitation.
fn queue_confirm(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::confirm_invite(state, &request)?;
    sharing_pane(state, said)
}

/// Queue a read of what a pasted code leads to.
fn queue_preview(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::preview_invite(state, &request)?;
    sharing_pane(state, said)
}

/// Queue an accept of the code this device is holding an answer about.
fn queue_accept(state: &AppState, _request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::accept_invite(state)?;
    sharing_pane(state, said)
}

/// Forget the previewed code. Local, so nothing is queued.
fn drop_preview(state: &AppState, _request: quasi_router::Request) -> Result<Response, RouteError> {
    let said = sharing::dismiss_preview(state)?;
    sharing_pane(state, said)
}

/// Turn automatic syncing on or off.
fn set_sync_auto(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let on = request.payload.get(sync::AUTO_SYNC).unwrap_or_default() != "disabled";
    let said = sync::set_auto(state, on)?;
    sync_pane(state, said.to_owned())
}

/// Set how often the scheduler syncs.
fn set_sync_interval(
    state: &AppState,
    request: quasi_router::Request,
) -> Result<Response, RouteError> {
    let minutes = request
        .payload
        .get(sync::INTERVAL)
        .unwrap_or_default()
        .parse()
        .unwrap_or(5);
    let said = sync::set_interval(state, minutes)?;
    sync_pane(state, said)
}

/// Forget the stored token and stop syncing.
fn disconnect_sync(
    state: &AppState,
    _request: quasi_router::Request,
) -> Result<Response, RouteError> {
    let said = sync::disconnect(state)?;
    sync_pane(state, said.to_owned())
}

/// One section.
fn section(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let slug = request
        .captures
        .get("section")
        .ok_or_else(|| RouteError::not_found("no section"))?;
    showing(state, slug)
}

/// Write one config key.
///
/// One route for every control on the screen, because every control on the
/// screen writes one `user_config` row. The closed set is [`write_config`]'s to
/// enforce, so a key the spec does not declare is refused here exactly as it is
/// refused through the command, and the screen does not carry a second list of
/// what it is willing to name.
///
/// A refusal is an [`Internal`](quasi_router::Class::Internal) rather than the
/// field carrying its own error, and rather than the 400 that is not there to
/// reach for. `RouteError` has four classes and none of them is "the caller
/// asked for something malformed", which is a real gap in general and the right
/// answer here: every value this route can receive was put on the control by
/// this screen, so an undeclared key or a missing value is a bug in the
/// description and not in what the user chose. `Field::error` is for the other
/// case, which this screen does not have — nothing here is typed.
fn set(state: &AppState, request: quasi_router::Request) -> Result<Response, RouteError> {
    let key = request
        .captures
        .get("key")
        .ok_or_else(|| RouteError::not_found("no config key"))?
        .to_owned();
    let value = request
        .payload
        .get(Node::SELECTED)
        .ok_or_else(|| RouteError::internal("the control sent no value"))?;

    write_config(state, &key, value).map_err(|error| RouteError::internal(error.to_string()))?;

    // Answer with the section the setting lives in, re-read, for the reason
    // every other port re-reads: the write is the database's to confirm.
    showing(state, section_for_key(&key))
}

/// Write whatever the generated notifications pane sent.
///
/// One route for the whole pane rather than one per key, because that is the
/// shape [`quasi_notifs::pane`] emits: every generated control carries the same
/// write action and sends its value under its own generated key, so the handler
/// reads a name it never had to be told. The hand-written half of the section
/// keeps [`set`], since its key is in the path.
///
/// A checkbox that is off sends nothing at all -- that is how HTML submits one,
/// and the description follows it -- so a key the payload does not carry is a
/// key the reader just turned off. Iterating the registry rather than the
/// payload is what makes that readable: every declared toggle is written on
/// every post, as `true` or as `false`, so a stored value is never the absence
/// of one.
fn set_notifications(
    state: &AppState,
    request: quasi_router::Request,
) -> Result<Response, RouteError> {
    for kind in NOTIFS.kinds() {
        let key = quasi_notifs::config::enabled_key(kind.id);
        let on = request
            .payload
            .get(key.as_str())
            .is_some_and(|v| v == "true");
        write_config(state, &key, &on.to_string())
            .map_err(|error| RouteError::internal(error.to_string()))?;

        // A knob is a value rather than a presence, so an absent one was not
        // sent and is left alone. No kind declares one today; this is here so
        // that adding one to the registry needs no change to this route, which
        // is the whole promise of the generated pane.
        for knob in kind.options {
            let key = quasi_notifs::config::knob_key(kind.id, knob.id);
            if let Some(value) = request.payload.get(key.as_str()) {
                write_config(state, &key, value)
                    .map_err(|error| RouteError::internal(error.to_string()))?;
            }
        }
    }

    showing(state, "notifications")
}

/// The settings screen's routes.
#[must_use]
pub fn routes(router: Router<AppState>) -> Router<AppState> {
    let router = router
        .get("/settings", index)
        .post("/settings/config/{key}", set)
        .post("/settings/notifications", set_notifications);
    // Above the section capture, so `email` and `about` are literals rather
    // than section names that happen to match.
    let router = email::routes(router)
        .post("/settings/about/update-check", set_update_check)
        .post("/settings/sync/auto", set_sync_auto)
        .post("/settings/sync/interval", set_sync_interval)
        .post("/settings/sync/disconnect", disconnect_sync)
        // Every one of these is a local insert. What talks to the server is
        // `group_queue`'s drainer; see `sharing`.
        .post("/settings/sharing/groups", queue_group)
        .post("/settings/sharing/members", queue_member)
        .post("/settings/sharing/queue/{id}/cancel", cancel_queued)
        // Unlike `email` and `about` above, these need no ordering care: the
        // literals are four segments and the captured pair is six, so nothing
        // here can swallow anything else. Grouped for reading, not for
        // precedence.
        .post("/settings/sharing/invites/preview", queue_preview)
        .post("/settings/sharing/invites/accept", queue_accept)
        .post("/settings/sharing/invites/dismiss", drop_preview)
        .post("/settings/sharing/invites", queue_invite)
        .post(
            "/settings/sharing/invites/{group_id}/{invitation_id}/revoke",
            queue_revoke,
        )
        .post(
            "/settings/sharing/invites/{group_id}/{invitation_id}/confirm",
            queue_confirm,
        );
    router.get("/settings/{section}", section)
}