Fix #455: edit navigates to profile #472

Merged
crueber merged 1 commit from fix/issue-455 into main 2026-09-13 17:53:01 +00:00
Owner

Closes #455 (follow-up to #442).\n\nEdit profile on the repositories/organizations tabs flipped the shared signal but never left the tab — the form rendered above the list while the tab bar still highlighted the list tab. The sidebar button (new openEditor in web/src/pages/Repos.jsx) now routes to /{owner} from non-profile tabs, where OwnerTabs derives Profile as active, with the form open. The profile-view click is unchanged (no navigation).\n\nLaw-12 correction to the issue's architecture note: 'navigation alone is sufficient' is wrong — the three owner routes are sibling Route components, so OwnerPage remounts on tab navigation and a component-local signal would reset. The edit-open state is now a module-scope per-owner signal (getEditingOwner, the Notifications unreadCount / lib/store theme shape), so the form survives the remount and never leaks across owners.\n\nGates byte-identical (button can_edit && !editing; form editing && can_edit; #420 bio hide-while-editing profile-only). No backend change; no new deps (useNavigate joins the existing solid-router import).\n\nTests: new web/test/unit/owner-profile-edit-navigates-455.test.js (6 tests, owner-links-445 precedent); owner-profile-edit-all-views-442.test.js updated to the module-scope opener. Full web suite 977 pass / 0 fail; vite + esbuild builds green; smoke tests 3/3 pass against a scratch-built server. No browser drive (per task: shared daemon blocks loopback).

Closes #455 (follow-up to #442).\n\nEdit profile on the repositories/organizations tabs flipped the shared signal but never left the tab — the form rendered above the list while the tab bar still highlighted the list tab. The sidebar button (new `openEditor` in `web/src/pages/Repos.jsx`) now routes to `/{owner}` from non-profile tabs, where OwnerTabs derives Profile as active, with the form open. The profile-view click is unchanged (no navigation).\n\nLaw-12 correction to the issue's architecture note: 'navigation alone is sufficient' is wrong — the three owner routes are sibling Route components, so OwnerPage remounts on tab navigation and a component-local signal would reset. The edit-open state is now a module-scope per-owner signal (`getEditingOwner`, the Notifications unreadCount / lib/store theme shape), so the form survives the remount and never leaks across owners.\n\nGates byte-identical (button `can_edit && !editing`; form `editing && can_edit`; #420 bio hide-while-editing profile-only). No backend change; no new deps (useNavigate joins the existing solid-router import).\n\nTests: new `web/test/unit/owner-profile-edit-navigates-455.test.js` (6 tests, owner-links-445 precedent); `owner-profile-edit-all-views-442.test.js` updated to the module-scope opener. Full web suite 977 pass / 0 fail; vite + esbuild builds green; smoke tests 3/3 pass against a scratch-built server. No browser drive (per task: shared daemon blocks loopback).
Sidebar Edit profile on the repositories/organizations tabs set the shared
signal but never left the tab. The button now routes to /{owner} from
non-profile tabs (Profile derives active there) with the form open; the
profile-view click is unchanged (no navigation).

Decision appended in code comments (law 12): the issue's 'navigation alone
is sufficient' note was wrong — the three owner routes are sibling Route
components, so OwnerPage remounts on tab navigation and a component-local
signal would reset. The edit-open state is a module-scope per-owner signal
(the Notifications unreadCount / lib/store theme shape). Gates
byte-identical (button/form/#420); no backend change; no new deps.
Sign in to join this conversation.
No description provided.