pastilhasandClaude Opus 5
0dce8fcb3c
Four bands in the order the page shows them, which is the sitemap's shape exactly: a HEADER of a photograph and a phrase, then ABOUT US, then PRODUTO with a video beside its text, then MANIFESTO. No schema change and no API change — `about_content` already carries every one of those columns and `aboutRouter` already reads and writes them. This is the screen that was missing, not the data. One save per band, the rule Home follows and for the same reason: `take()` treats an absent key as "leave it alone", so a single Save carrying every field would let a half-finished manifesto ride along with a photograph somebody meant to change. Both media slots go through MediaPicker rather than a text field. A path somebody types is a path that is wrong by one character and renders as a broken image. One picker serves both, with `picking` naming which slot asked — two would be two copies of a modal that already knows how to browse originals/. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
93 lines
4.2 KiB
TypeScript
93 lines
4.2 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 { AboutPanel } from './sections/AboutPanel';
|
|
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,
|
|
about: AboutPanel,
|
|
/*
|
|
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>
|
|
);
|
|
};
|