Most pages outside the storefront are navigational dead ends #52
No Assignees
bermudalamb
bermudalamb
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: bermudalamb/redefined-designs#52
Reference in New Issue
Block a user
Found while reviewing the UI architecture for #51. The account page was not an isolated case — it was the general pattern.
Updated after #51 and #50 landed. Most of the original list is now fixed; what remains is smaller and more specific than when this was written.
Current state
/storefront/cart/account/login/register/forgot-password/reset-password/privacy/verify-email/account/adminWhat is left
Three pages, and they do not share a single answer:
/privacy— still the worst of them, and still a bare card. It is linked from the registration form and from the storefront footer. #50 made the registration case less damaging by opening it in a new tab, so a part-filled signup form is no longer discarded, but reaching it from the footer is still a dead end./verify-email— reached from an email, and the customer may not be signed in. Its only link is to/account, which is useless to someone who is signed out./admin— deliberately separate, with its own header. Whether it should offer a way back to the storefront at all is a judgement call rather than a defect.Root cause, revised
The original diagnosis was that the site header is written twice, in
App.tsxand again incart/Cart.tsx, so nothing makes a new page inherit it. That is still true and is still why the problem kept recurring.What has changed is that the fix for most pages turned out not to be a shared layout. #51 and #50 established a different mechanism:
AppRoutesinmain.tsxrenders the route table against a backdrop location, so a route inMODAL_ROUTESdisplays as a modal over the page the customer was already on — or over the storefront when they arrived by bookmark or email link. Those pages inherit navigation by being rendered over something that already has it, rather than by being wrapped in a shared header.So the remaining question is narrower than "extract a layout":
/privacyand/verify-emailjoinMODAL_ROUTES, or do they genuinely want to be pages with chrome? A privacy policy is a long document and arguably wants to be a real page; a modal is a poor place to read one./verify-emailis a short confirmation and would suit a modal well./adminif it is ever given a link home.Still worth deciding
/admingains a link back to the storefront, or is deliberately kept separate.App.tsxandcart/Cart.tsxshould be extracted regardless, purely to stop the two drifting.Double check the items supposedly fixed with #50. They appear to be broken still. For example,
/loginand/registerare not displaying in a modal. Those UIs are duplicated when clicking on the Favorite icon for an unknown customer.