Three sections, one panel, configured — the same split the site's API already makes. Each is a titled record with an ordered list of media hanging off it, and the only real differences are what the title is called and which extra fields the record carries. The htmx admin had three screens and that was defensible there, because each carried its own markup as well. There is no markup to differ here, so three panels would be three places to fix one ordering bug. The `fields` list in records.ts is the FORM for what the server allows, not a second authority over it. What may actually be written is decided by `valuesFrom` in the site's sections.ts, per section, as an allowlist — a key added here that the server does not accept is an input that silently saves nothing. Which record is open lives in `?record=<id>` beside `?section=`, per docs/navigation-audit.md, and the detail is loaded from that id rather than carried over from the list. That is what makes a typed or reloaded URL work, and it is guarded against a slow response for a record nobody is looking at any more overwriting a fast one for the record they opened next. Ordering sends every id in the order it should be, so two items cannot claim one position. Media is added one path at a time because the server appends, and a parallel add would land in whatever order the requests happened to finish. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
91 lines
4.1 KiB
TypeScript
91 lines
4.1 KiB
TypeScript
import { useSearchParams } from 'react-router';
|
|
import { DEFAULT_SECTION, isSectionKey, sectionFor, sectionOpen, type SectionKey } from './sections';
|
|
import { AdministrationPanel } from './AdministrationPanel';
|
|
import { MediaPanel } from './MediaPanel';
|
|
import { HomePanel } from './sections/HomePanel';
|
|
import { GalleriesPanel } from './sections/GalleriesPanel';
|
|
import { RecordsPanel } from './sections/RecordsPanel';
|
|
import { COLLABS_CONFIG, DROPS_CONFIG, GALLERY_CONFIG } from './sections/records';
|
|
import { MessagesPanel } from './MessagesPanel';
|
|
import { PlannedSection } from './PlannedSection';
|
|
import { useReady } from './useReady';
|
|
|
|
/**
|
|
* 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.
|
|
*
|
|
* ── There used to be a `?config=1` ──
|
|
*
|
|
* The connection form was an overlay reached from a link in this header, because it was not one of the
|
|
* sections. Now it IS one — Administration — so the overlay is gone and so is the link. A second route
|
|
* to the same screen is a second thing to keep correct, and the two disagreed the moment a section was
|
|
* selected underneath a form that covered it.
|
|
*
|
|
* ── Not ready means Administration, whatever the URL says ──
|
|
*
|
|
* The gate is `useReady`, shared with the nav so the two cannot disagree. Enforced HERE and not only
|
|
* there, because the nav can only decline to offer a link — `?section=gallery` typed into the address
|
|
* bar, or a bookmark from before the connection was forgotten, arrives without going through it. A
|
|
* nav that hides a door is a courtesy; this is the lock.
|
|
*/
|
|
|
|
/**
|
|
* 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>> = {
|
|
home: HomePanel,
|
|
/*
|
|
Three sections, one panel, configured — the same split the site's API already makes between
|
|
`records.ts` and `sections.ts`. See web/sections/records.ts for what each one carries.
|
|
*/
|
|
gallery: () => <RecordsPanel config={GALLERY_CONFIG} />,
|
|
drops: () => <RecordsPanel config={DROPS_CONFIG} />,
|
|
collabs: () => <RecordsPanel config={COLLABS_CONFIG} />,
|
|
galleries: GalleriesPanel,
|
|
messages: MessagesPanel,
|
|
administration: AdministrationPanel,
|
|
media: MediaPanel,
|
|
};
|
|
|
|
export const DetailPanel = () => {
|
|
const [params] = useSearchParams();
|
|
const raw = params.get('section');
|
|
const selected: SectionKey = isSectionKey(raw) ? raw : DEFAULT_SECTION;
|
|
|
|
const { ready, rootSet, loading } = useReady();
|
|
|
|
if (loading) {
|
|
return <div className="flex size-full items-center justify-center p-6 text-sm text-muted-foreground">Loading…</div>;
|
|
}
|
|
|
|
/*
|
|
Not ready, so Administration regardless of what the URL asked for. The header then NAMES it, which
|
|
is the part the old overlay could not do: the form used to appear under whichever row happened to
|
|
be highlighted, so it read as that section being broken rather than as one step not done yet.
|
|
*/
|
|
/*
|
|
A section that cannot be opened sends you to Administration, because that is where every requirement
|
|
is satisfied. Asked per section rather than by one flag: Media is reachable the moment a root
|
|
location exists, long before fofos is connected.
|
|
*/
|
|
const wanted = sectionFor(selected);
|
|
const current = sectionOpen(wanted, { ready, rootSet }) ? wanted : sectionFor('administration');
|
|
|
|
const Panel = current.built ? PANELS[current.key] : undefined;
|
|
|
|
return (
|
|
<div className="flex size-full flex-col overflow-hidden">
|
|
<div className="min-h-0 flex-1">{Panel ? <Panel /> : <PlannedSection section={current} />}</div>
|
|
</div>
|
|
);
|
|
};
|