LGS Forge

Appearance

Sidebar Nav Cleanup — Design ​

Problem ​

Two issues reported against the shipped Navigation & Dashboard Restructure:

  1. Duplicate navigation. CatalogGameLayout, CatalogGameSettingsLayout, and SettingsLayout each render a SubNavTabs pill-row at the top of the page (e.g. Singles/Sealed/Sets/Settings) that exactly duplicates the same items already present as an expandable group in the left sidebar. The sidebar should be the sole navigation surface for these; the top bar is redundant.
  2. Weak visual hierarchy. Sidebar sub-items (e.g. Singles/Sealed/Sets/Settings under "Magic: The Gathering") render with the same border weight, shadow, font size, and padding as top-level items (Dashboard, Store Settings, Queue), differing only by a small left-padding offset. This makes it hard to tell at a glance which items are children of which group.

Scope ​

Presentation-layer only. No routing, API, or data changes.

Change 1: Remove duplicate top nav bars ​

SubNavTabs has exactly three consumers, all removed by this change:

  • client/src/pages/catalog/CatalogGameLayout.jsx
  • client/src/pages/catalog/CatalogGameSettingsLayout.jsx
  • client/src/pages/settings/SettingsLayout.jsx

Each drops the SubNavTabs import, its usage, and the tabs/SETTINGS_TABS array that only fed it. Each also drops the isEmbedded prop from its signature — that prop existed solely to make SubNavTabs build shop-aware links, and has no other use in these components once SubNavTabs is gone. App.jsx continues to pass isEmbedded to these components; React silently ignores the now-unconsumed prop, so no routing change is needed.

What each component keeps, unchanged:

  • CatalogGameLayout: the game-name heading (<Text as="h1">{gameInfo.name}</Text>) and <Outlet/>.
  • CatalogGameSettingsLayout: the "These settings apply to all of your enabled catalogs, not just this one." note and <Outlet/>.
  • SettingsLayout: the "Store Settings" heading and <Outlet/>.

Since this removes SubNavTabs's only consumers, client/src/components/SubNavTabs.jsx and client/src/components/SubNavTabs.test.jsx are deleted outright (dead code).

Change 2: Sidebar hierarchy — connector rail + shrink ​

In client/src/components/NavGroup.jsx, nested items (depth > 0 — covers both the 2-level Store Settings tree and the 3-level Catalog → Game → Settings tree) get additional CSS beyond the existing nav-link treatment:

  • Thinner border (2px vs. the top-level 3px)
  • Smaller box-shadow and padding
  • Smaller font-size
  • A thin vertical connector line (::before, absolutely positioned) tying the item visually back to its parent group

Top-level items (depth 0 — Dashboard, Store Settings, Magic: The Gathering, etc.) are visually unchanged. The existing depth-based left-padding (pl-4 / pl-8) stays as-is; the new treatment layers on top of it via an additional class, e.g. nav-link-nested, applied whenever depth > 0. This is CSS/class-selection only — NavGroup.jsx's recursion and event-handling logic don't change.

Approved direction: Option A (connector rail + shrink) from three visual mockups compared during design (nested-panel and plain-text-children were the alternatives, not chosen).

Test updates ​

  • CatalogGameLayout.test.jsx and CatalogGameSettingsLayout.test.jsx currently assert that the sub-nav buttons (Singles/Sealed/Sets/Settings, Pricing/Sync Settings/Metafields) render inline in the page. Those assertions are removed — the buttons no longer render there, and the sidebar's own tests (RadixShell.test.jsx, NavGroup.test.jsx) already cover that this navigation exists and works.
  • SettingsLayout.jsx has no existing test file; nothing to update there.
  • SubNavTabs.test.jsx is deleted along with the component.
  • NavGroup.test.jsx may need a new or updated assertion confirming the nested-item class/styling distinction exists at depth > 0 (exact assertion approach — checking for the new CSS class name vs. a computed-style check — left to the implementer; prefer checking for the class name since jsdom doesn't compute real layout).

Out of scope ​

  • No change to the actual navigation targets, route table, or click behavior — only presentation.
  • No change to RadixShell.jsx's nav-tree construction (buildCatalogGroup, accountGroup, etc.) — only how NavGroup renders what it's given.
  • No change to mobile/embedded behavior beyond what naturally follows from the CSS change (same treatment applies at all viewport widths).