manifest, one table, a router and two panels. Discovery is by convention, so
this is the point at which the directory stops being a directory and becomes
something Officer can install.
The manifest holds only what a listing cannot say. One permission, grantable,
with ownerOnly on /_config — reading and editing the site is exactly what a
member might be brought in for, but the token is unrestricted write authority
over everything the public sees, so handing it over is the owner's.
db/schema.ts is ONE table and should stay that way. fofos owns its own Postgres
and its own media store; this holds a URL and a token. That is what makes the
strongest thing about this plugin true: no operation on it can destroy the
client's work, checkbox ticked or not, because none of it was ever here. A cache
would be the thin end of that.
The router mostly forwards. fofos's /api/admin already answers in the shape a
panel wants, so re-wrapping it would be a second place for the contract to drift.
Two things in it are load-bearing rather than style:
registerProxiedPrefix('/api/fofos-admin/media'). bodyParser calls parseBody on
multipart across the whole protected router, and Hono then caches the parsed
FormData — so asking for the bytes afterwards re-serialises them under a NEW
boundary while the ORIGINAL content-type header is what gets forwarded. Header
and body disagree and every upload fails with "Unexpected end of form".
Narrow to the one route: everything else is JSON that is fine to parse.
The catch-all is LAST in the file. Hono runs matching handlers in registration
order, so /* above /_config would swallow it and the settings form would
forward itself to fofos, which has no such endpoint — a 404 from a plugin that
is working perfectly.
Panels are a nav and a detail pane that never speak to each other: the nav writes
?section=, the detail pane reads it. Real <Link>s rather than the buttons
proxy-manager uses — AGENTS.md says nav items are links, and the file documenting
that pattern says not to copy the older one. <Link> and not <NavLink> because
active state here is a query parameter and NavLink compares paths, which would
light every row at once.
Which component renders which section is a MAP, not a conditional on `built`.
The first version read `built ? <MessagesPanel/> : <Planned/>`, which is correct
only while exactly one section exists — the second one finished would have
rendered Messages under its own name.
Messages is the only section built, chosen because it is one read-only route: it
proves the path from an Officer panel through this proxy to fofos and back with
nothing else able to be wrong at the same time. The other eight are in the nav,
dimmed and labelled, saying what they will do and that the old admin still edits
them. A nav that hides what is unfinished gives no sense of what the thing is for.
Typechecked against the platform — and the typechecker was verified to actually
cover plugins/ by planting an error and watching it fail, because a clean run
that does not include your files is worse than no run.
NOT yet: installed, or run against a live fofos. Nothing here has been through
the permission gate or a real request.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
103 lines
4.1 KiB
TypeScript
103 lines
4.1 KiB
TypeScript
import { useCallback, useEffect, useRef, useState } from 'react';
|
|
import { Link, useSearchParams } from 'react-router';
|
|
import { Settings } from 'lucide-react';
|
|
import { useClient } from 'hooks/useClient';
|
|
import { DEFAULT_SECTION, isSectionKey, sectionFor, type SectionKey } from './sections';
|
|
import { ConnectionPanel } from './ConnectionPanel';
|
|
import { MessagesPanel } from './MessagesPanel';
|
|
import { PlannedSection } from './PlannedSection';
|
|
import { useFofosChanged } from './channel';
|
|
|
|
/**
|
|
* The right column: whichever section the nav has selected.
|
|
*
|
|
* It reads `?section=` from the URL rather than being handed it — the two panels are siblings in a
|
|
* workspace and neither owns the other. `?config=1` renders the connection form over the top of
|
|
* whatever is selected, so settings are addressable too.
|
|
*
|
|
* ── The unconfigured check lives HERE, once ──
|
|
*
|
|
* Every section needs a connection, so every section would otherwise have to handle its absence and
|
|
* each would word it slightly differently. Asking `/status` once and rendering the connection form
|
|
* instead of any section is one answer for all nine, and it makes "not connected yet" read as a setup
|
|
* step rather than as nine broken lists.
|
|
*/
|
|
|
|
type Status = { configured: boolean; lastProbeOk: boolean | null };
|
|
|
|
/**
|
|
* Which component renders which section.
|
|
*
|
|
* A map rather than a conditional on `built`. The version of this that read
|
|
* `built ? <MessagesPanel/> : <Planned/>` was correct only while exactly one section existed — the
|
|
* second one to be finished would have rendered Messages under its own name, which is the kind of bug
|
|
* that looks like a data problem for an hour. A key with no entry here falls through to Planned, so
|
|
* marking a section `built` in sections.ts without writing its panel fails visibly rather than
|
|
* silently showing somebody else's.
|
|
*/
|
|
const PANELS: Partial<Record<SectionKey, () => React.JSX.Element>> = {
|
|
messages: MessagesPanel,
|
|
};
|
|
|
|
export const DetailPanel = () => {
|
|
const [params] = useSearchParams();
|
|
const raw = params.get('section');
|
|
const section: SectionKey = isSectionKey(raw) ? raw : DEFAULT_SECTION;
|
|
const showingConfig = params.get('config') === '1';
|
|
|
|
const client = useClient();
|
|
const clientRef = useRef(client);
|
|
clientRef.current = client;
|
|
|
|
const [configured, setConfigured] = useState<boolean | null>(null);
|
|
const [signal] = useFofosChanged();
|
|
|
|
const check = useCallback(async () => {
|
|
try {
|
|
const status = await clientRef.current.get<Status>('/fofos-admin/status');
|
|
setConfigured(status.configured);
|
|
} catch {
|
|
// Cannot tell. Render the section rather than the setup form — a transient failure must not look
|
|
// like "you have not set this up", which is a much more alarming thing to be told, and would
|
|
// invite somebody to re-enter a connection that was never the problem.
|
|
setConfigured(true);
|
|
}
|
|
}, []);
|
|
|
|
useEffect(() => {
|
|
void check();
|
|
}, [check, signal]);
|
|
|
|
if (configured === null) {
|
|
return <div className="flex size-full items-center justify-center p-6 text-sm text-muted-foreground">Loading…</div>;
|
|
}
|
|
|
|
if (showingConfig || !configured) return <ConnectionPanel />;
|
|
|
|
const current = sectionFor(section);
|
|
|
|
// Everything but `config`, so the settings link keeps the section underneath it.
|
|
const configSearch = new URLSearchParams(params);
|
|
configSearch.set('config', '1');
|
|
|
|
const Panel = current.built ? PANELS[current.key] : undefined;
|
|
|
|
return (
|
|
<div className="flex size-full flex-col overflow-hidden">
|
|
<div className="flex items-center justify-between gap-3 border-b border-border px-4 py-2">
|
|
<h2 className="truncate text-sm font-medium">{current.label}</h2>
|
|
{/* A real link, so the settings are addressable and cmd-clickable like anything else. */}
|
|
<Link
|
|
to={{ search: `?${configSearch.toString()}` }}
|
|
className="flex items-center gap-1.5 text-xs text-muted-foreground hover:text-foreground"
|
|
>
|
|
<Settings className="size-3.5" />
|
|
Connection
|
|
</Link>
|
|
</div>
|
|
|
|
<div className="min-h-0 flex-1">{Panel ? <Panel /> : <PlannedSection section={current} />}</div>
|
|
</div>
|
|
);
|
|
};
|