1cb7c109e7
Lab provider profiles (coach, filmer, editor, photographer, builder) are addressable events with a fixed per-type `d` identifier, so re-publishing REPLACES the existing profile. Unlike BecomeSkaterPage — which pre-fills from the existing profile so re-submitting edits rather than clobbers — these five forms start blank and reconstruct nothing. A returning provider who opened the form again and submitted would silently wipe every field they'd previously set (bio, rate, spots, contact, links) down to whatever they happened to retype. Rather than fragile per-page reconstruction of the mixed services/skills tag sets (high regression risk), added a small honest guardrail: - New ExistingLabProfileNotice component: appears only when the current user already has a profile of that type (looked up via useLabProfile by their pubkey + the known identifier). It states plainly that publishing will REPLACE the current profile and links to view the existing one first. - Wired into all five Become* pages with the correct identifier/label. Also confirmed (not a bug): all five navigate to /coach/:pubkey/:identifier after publish — CoachDetailPage is a generic Lab-profile renderer that resolves any type by the distinct `d` identifier, so this is correct despite the name. Investigation of the shared submit handlers found them otherwise consistent and well-formed; left untouched. Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
60 lines
2.4 KiB
TypeScript
60 lines
2.4 KiB
TypeScript
import { Link } from 'react-router-dom';
|
|
import { AlertTriangle, Eye } from 'lucide-react';
|
|
import { Button } from '@/components/ui/button';
|
|
import { useCurrentUser } from '@/hooks/useCurrentUser';
|
|
import { useLabProfile } from '@/hooks/useLabProfiles';
|
|
|
|
/**
|
|
* Lab provider profiles (coach, filmer, editor, photographer, builder…) are
|
|
* addressable events keyed by a fixed `d` identifier per type
|
|
* (e.g. "coach-profile"). That means re-publishing REPLACES the existing one.
|
|
*
|
|
* The "Become a …" forms start blank and don't reconstruct prior state, so a
|
|
* returning provider who submits again would silently wipe every field they'd
|
|
* set before (bio, rate, spots, contact…). This notice makes that consequence
|
|
* explicit: it appears only when the current user already has a profile of this
|
|
* type, warns that submitting will overwrite it, and links them to view it.
|
|
*/
|
|
export function ExistingLabProfileNotice({
|
|
identifier,
|
|
label,
|
|
}: {
|
|
/** The fixed `d` identifier for this Lab profile type, e.g. "coach-profile". */
|
|
identifier: string;
|
|
/** Human label for the profile type, e.g. "coach". */
|
|
label: string;
|
|
}) {
|
|
const { user } = useCurrentUser();
|
|
const { data: existing } = useLabProfile(identifier, user?.pubkey);
|
|
|
|
if (!user || !existing) return null;
|
|
|
|
return (
|
|
<div className="rounded-lg border-2 border-amber-500/40 bg-amber-500/5 p-4">
|
|
<div className="flex items-start gap-3">
|
|
<AlertTriangle className="mt-0.5 h-5 w-5 shrink-0 text-amber-400" />
|
|
<div className="flex-1 space-y-2">
|
|
<p className="text-sm font-bold text-amber-300">
|
|
You already have a {label} profile
|
|
</p>
|
|
<p className="text-xs text-gray-400">
|
|
Publishing this form <span className="font-semibold text-amber-300">replaces</span> your
|
|
current {label} profile — anything you don't re-enter here will be lost. Review your
|
|
existing profile first so you don't drop details you already set.
|
|
</p>
|
|
<Button
|
|
asChild
|
|
variant="outline"
|
|
size="sm"
|
|
className="border-amber-500/40 text-amber-300 hover:bg-amber-500/10"
|
|
>
|
|
<Link to={`/coach/${user.pubkey}/${identifier}`}>
|
|
<Eye className="mr-1.5 h-3.5 w-3.5" />
|
|
View current {label} profile
|
|
</Link>
|
|
</Button>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
);
|
|
}
|