Skip to content
ConversionIQ Docs

Account – Components

Route

Section titled “Route”
  • Path: /account/components
  • Parent: README.md
  • Status: Internal-only component registry and inspection page

Purpose

Section titled “Purpose”

Provide a centralized internal surface for:

  • browsing shared and reusable UI components
  • comparing similar implementations across the app
  • inspecting states and variations
  • tracing components back to real usage locations
  • identifying consolidation opportunities

This page is temporary and development-focused, but it should be structured so it can mature into a longer-lived internal governance tool.

Section titled “Navigation”
  • Entry appears in the authenticated shell footer nav as Components
  • This page is not part of the primary left navigation
  • Breadcrumbs: Account > Components

Layout structure

Section titled “Layout structure”
  • Application shell (persistent)
  • Top section
    • Page title: Components
    • Lightweight internal-use description
    • Summary metadata such as registry counts / scope cues
    • Filter controls for narrowing the registry
  • Registry body
    • Grouped sections for:
      • Shared UI primitives
      • App-level reusable patterns
      • Consolidation candidates / duplicate implementations
  • Registry item card
    • Component name
    • Category / status
    • Short purpose description
    • Example states / variations
    • Subtle traceability hints (route or usage references)
  • Comparison areas
    • Side-by-side presentations for visually similar implementations when review/consolidation is needed

Traceability requirements

Section titled “Traceability requirements”

Each registry item should expose developer-friendly hints without turning the page into a raw code browser:

  • route-level usage references
  • optional identifier or pattern hints
  • canonical vs review-needed status

Avoid cluttering the page with verbose file-system details in the primary UI.

Implementation notes

Section titled “Implementation notes”
  • Start with curated registry metadata rather than a fully automated discovery system
  • Prefer extensible data-driven grouping over a rigid page layout
  • Reuse shared app primitives and patterns where possible
  • Prioritize components and patterns that are actively used across the current product over demo-only or speculative entries
  • Treat the page as a high-signal registry of the app’s current UI language: shared primitives, reusable app patterns, and areas that still need consolidation
  • Prefer live or near-live previews that match shipped behavior over abstract placeholder cards when the real pattern is stable enough to demonstrate
  • The page is not a Storybook replacement

Coverage priorities

Section titled “Coverage priorities”

The first implementation passes should focus on the most visible and most repeated building blocks currently used across the authenticated product, including:

  • shared primitives such as tables, badges, switches, popovers, dropdown menus, tooltips, hover cards, sheets, and toggle groups
  • reusable app patterns such as page top sections, list toolbars, filter controls, pagination, and the account shell frame
  • route-specific patterns that have become stable product conventions, such as the workspace detail header / top section

Registry growth should remain curated. The goal is not to mirror every file under src/components/ui, but the page should represent the major components and patterns that define the current web app experience.

Non-goals

Section titled “Non-goals”
  • full component playground tooling
  • exhaustive runtime state simulation
  • design-system documentation parity