Initial commit: React frontend (SLP Software) + AIDLC workflow docs
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
+68
@@ -0,0 +1,68 @@
|
||||
# Functional Design Clarification Questions — react-frontend-app
|
||||
|
||||
Please answer each question by filling in the letter choice after the `[Answer]:` tag.
|
||||
|
||||
## Question 1: Theme toggle placement and style
|
||||
Where and how should the visible theme switcher (red/purple) be placed in the UI?
|
||||
|
||||
A) A small icon/swatch button in the nav bar (next to the "Start project" CTA), showing the current theme and toggling on click
|
||||
B) A labeled two-option switch (e.g. "Rood" / "Paars" segmented control) in the nav bar
|
||||
C) A floating control (e.g. fixed corner button) separate from the nav bar
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 2: Theme data shape
|
||||
How should the two theme palettes be modeled in code?
|
||||
|
||||
A) A single TypeScript object/record per theme (e.g. `{ red: {...tokens}, purple: {...tokens} }`) mapped to CSS custom properties at runtime via a `data-theme` attribute on `<html>`/`<body>`
|
||||
B) Two separate static CSS files (one per theme) that get swapped via a `<link>` tag toggle
|
||||
C) Tailwind config with two named theme variants selected via a class on the root element (e.g. `theme-red`, `theme-purple`)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
## Question 3: Package/content data shape
|
||||
How should the static package/pricing/content data (nav links, hero copy, package cards, steps, etc.) be structured in code for this iteration?
|
||||
|
||||
A) One central static data module (e.g. `content.ts`) exporting typed constants/arrays consumed directly by components — easiest to later swap for a TanStack Query hook with the same shape
|
||||
B) Hardcoded directly inside each component (no separate data module)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 4: TanStack Router route structure for this iteration
|
||||
Given there is effectively one page right now, how should the initial route structure look?
|
||||
|
||||
A) A root route (`__root.tsx`) rendering the shared layout (nav, theme provider, footer) with a single index route (`/`) rendering the full page content — ready to add sibling routes later
|
||||
B) A single flat route with no nested layout route yet (add the root/layout split only when a second route is introduced)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 5: TanStack Query placeholder usage
|
||||
Since there's no backend yet, how should the "prepared for TanStack Query" requirement (FR-5) be reflected in this functional design?
|
||||
|
||||
A) Define one placeholder query hook (e.g. `usePackagesQuery`) that currently resolves the static data through `queryFn` (wrapped in a Promise) so the calling component already consumes it via `useQuery`, making a future real API swap a one-line change
|
||||
B) Only add the `QueryClientProvider` at the app root for now, without creating any actual query hook yet — components keep reading static data directly until a real API exists
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 6: Reduced-motion handling for the theme switch itself
|
||||
The reference design already respects `prefers-reduced-motion` for the caret blink. Should the theme-switch transition (background/color change) also respect this preference?
|
||||
|
||||
A) Yes — make the theme color transition instant (no fade) when `prefers-reduced-motion: reduce` is set, consistent with the existing caret handling
|
||||
B) No special handling needed for the theme transition — only the existing caret animation needs to respect it
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 7: Accessibility labeling for the theme switcher
|
||||
What accessible name/label should the new theme switcher control have?
|
||||
|
||||
A) `aria-label="Wissel kleurthema"` (Dutch, matching the rest of the site's language) with `aria-pressed`/`aria-checked` reflecting current state
|
||||
B) `aria-label="Toggle color theme"` (English)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
Reference in New Issue
Block a user