pastilhasandClaude Opus 5
abdb519e8b
Every section had its own Save buttons — four on About, two on Home, one per record — and on a page long enough to scroll, the button you wanted was the one that had just left the screen. Now there is one, beside Publish, pinned above the scroll. The section announces whether it has unsaved changes, whether it is busy, and how to save; the bar renders that. Neither knows what the other is, which is what keeps DetailPanel a map of keys to components rather than a place that has to know what each section can do. ── What this replaces ── The per-card saves existed because the API treats an absent key as "leave it alone", so a Save carrying everything meant a half-written manifesto shipping with a photograph somebody meant to change. With one Save that is the model rather than an accident: one press writes the page you are looking at. The cost, stated plainly: there is no longer a way to commit one part of a page and leave the rest. Nothing here needed that, and if something ever does it wants its own verb rather than four buttons all called Save. ── Dirty is a comparison, not a flag ── Against what the server last returned, field by field. A flag says "something was typed" and stays true after you undo it by hand; a comparison says "this differs from what is stored", which is the question a Save button is actually answering — and it is what lets the button be dead when there is nothing to do, which is the whole value of having one. The gallery picker on Home is deliberately outside it and still writes on selection: a <select> that needs a second press to mean anything is a control people believe they have already used. Sections with nothing to save render no button rather than a dead one. A permanently disabled control invites a press and teaches that pressing does nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
72 lines
3.3 KiB
TypeScript
72 lines
3.3 KiB
TypeScript
import { createContext, useCallback, useContext, useEffect, useRef, useState, type ReactNode } from 'react';
|
|
|
|
/**
|
|
* One Save, in the panel's own bar, driven by whichever section is open.
|
|
*
|
|
* ── Why a context and not a prop ──
|
|
*
|
|
* The button lives in DetailPanel and the work lives in the section — and DetailPanel deliberately
|
|
* knows nothing about the sections beyond a map of keys to components. Threading a save handler down
|
|
* would mean every panel taking a prop it did not ask for, and DetailPanel holding a union of what
|
|
* each of them can do.
|
|
*
|
|
* So the section announces itself instead. It says whether it has unsaved changes, whether it is busy,
|
|
* and how to save; the bar renders that. Neither has to know what the other is.
|
|
*
|
|
* ── One Save replaces the per-card ones ──
|
|
*
|
|
* The panels used to save a card at a time, because the API treats an absent key as "leave it alone" —
|
|
* so a Save carrying everything meant a half-written manifesto shipping with a photograph somebody
|
|
* meant to change. With one Save that is no longer an accident, it is the model: one Save saves the
|
|
* page you are looking at, which is what a person expects from a button that says Save.
|
|
*
|
|
* What it costs is the thing worth stating: there is no longer a way to commit one part of a page and
|
|
* leave the rest. Nothing in this admin needed that, and if something ever does it wants its own verb
|
|
* rather than four buttons called the same word.
|
|
*/
|
|
|
|
export type SaveTarget = {
|
|
/** Something is edited and not yet written. The button is dead without it. */
|
|
dirty: boolean;
|
|
/** A save is in flight. Keeps a second press from starting a second one. */
|
|
busy: boolean;
|
|
save: () => void | Promise<void>;
|
|
};
|
|
|
|
const SaveTargetContext = createContext<{
|
|
target: SaveTarget | null;
|
|
announce: (target: SaveTarget | null) => void;
|
|
}>({ target: null, announce: () => {} });
|
|
|
|
export const SaveTargetProvider = ({ children }: { children: ReactNode }) => {
|
|
const [target, setTarget] = useState<SaveTarget | null>(null);
|
|
// Stable, so the effect in `useSaveTarget` is not re-run by this provider re-rendering.
|
|
const announce = useCallback((next: SaveTarget | null) => setTarget(next), []);
|
|
return <SaveTargetContext.Provider value={{ target, announce }}>{children}</SaveTargetContext.Provider>;
|
|
};
|
|
|
|
/** Read by the bar. Null when the open section has nothing to save. */
|
|
export const useSaveButton = (): SaveTarget | null => useContext(SaveTargetContext).target;
|
|
|
|
/**
|
|
* Called by a section to offer its Save.
|
|
*
|
|
* `save` is held in a ref and the effect depends only on the two booleans, so a handler rebuilt on
|
|
* every render — which it is, being an ordinary function in a component — does not re-announce on
|
|
* every render. Announcing in a loop would be a state update per render, which React stops by
|
|
* throwing rather than by being slow.
|
|
*
|
|
* The cleanup clears it, so a section that unmounts leaves no button behind pointing at a component
|
|
* that is gone.
|
|
*/
|
|
export const useSaveTarget = (dirty: boolean, busy: boolean, save: () => void | Promise<void>): void => {
|
|
const { announce } = useContext(SaveTargetContext);
|
|
const saveRef = useRef(save);
|
|
saveRef.current = save;
|
|
|
|
useEffect(() => {
|
|
announce({ dirty, busy, save: () => saveRef.current() });
|
|
return () => announce(null);
|
|
}, [dirty, busy, announce]);
|
|
};
|