118 lines
6.0 KiB
Markdown
118 lines
6.0 KiB
Markdown
# Requirements Clarification Questions — React Frontend
|
|
|
|
Please answer each question by filling in the letter choice after the `[Answer]:` tag.
|
|
|
|
## Question 1: Scope of this first iteration
|
|
The request says "start with setting up a static website, but as React". What should be included in this first delivery?
|
|
|
|
A) Only the landing page content that is already in the reference designs (nav, hero, pakketten, werkwijze, over, contact, footer), rebuilt 1-on-1 as React components
|
|
B) The reference page content, plus routing scaffolding (TanStack Router) even though there is only one route today
|
|
C) The reference page content, plus a full project skeleton including TanStack Router AND TanStack Query wired up (even though there is no data-fetching need yet)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|
|
|
|
## Question 2: Tooling / build setup
|
|
Which React tooling stack should be used to set up the project?
|
|
|
|
A) Vite + React + TypeScript (fast dev server, widely used with TanStack)
|
|
B) Vite + React (JavaScript, no TypeScript)
|
|
C) Next.js (React framework with built-in routing — note: overlaps with TanStack Router, so would need a decision on which router to use)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
## Question 3: Styling approach
|
|
The reference designs use hand-written CSS with CSS custom properties (`:root { --bg; --accent; ... }`) for theming. How should styling be implemented in React?
|
|
|
|
A) Keep plain CSS (CSS Modules or global CSS) using the same CSS custom properties, so the color palette stays swappable exactly like the reference
|
|
B) Move to CSS-in-JS (e.g. styled-components / vanilla-extract)
|
|
C) Move to a utility CSS framework (e.g. Tailwind CSS), re-implementing the visuals with utility classes
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|
|
|
|
## Question 4: Color theme switching mechanism
|
|
You want red as the default/primary theme, with the purple theme selectable as an addition to the reference designs. How should the user select the theme?
|
|
|
|
A) A visible UI toggle/switcher on the site (e.g. in the nav) that lets visitors switch between "Rood" and "Paars" at runtime
|
|
B) Only a developer-facing mechanism for now (e.g. a config value or environment variable) — no visible UI control yet, visible switcher can be a later iteration
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
## Question 5: Theme persistence
|
|
If a visible theme switcher is added (Question 4 = A), should the chosen theme be remembered between visits?
|
|
|
|
A) Yes — persist the choice in the browser (e.g. localStorage) so it's remembered on return visits
|
|
B) No — theme resets to red (default) on every page load/visit
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
## Question 6: Content fidelity vs. placeholders
|
|
The reference designs contain real Dutch marketing copy (package prices, e-mail address `info@slpsoftware.nl`, etc.). Should this content be copied 1-on-1?
|
|
|
|
A) Yes — copy all text, prices, and contact details 1-on-1 exactly as in the reference HTML
|
|
B) Copy the structure/layout 1-on-1, but replace specific business content (prices, e-mail) with placeholders to be finalized later
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A, this will be replaced with data fetching later, but for now use the data from the designs
|
|
|
|
## Question 7: Interactivity already present in the reference
|
|
The reference HTML has a couple of small interactive/dynamic bits (a blinking caret animation in the hero code line, `:hover`/`:focus-visible` states, smooth scroll anchor links). Should these be preserved as-is?
|
|
|
|
A) Yes — preserve all existing visual micro-interactions exactly (blinking caret, hover states, smooth scroll)
|
|
B) Preserve hover/focus states, but drop the blinking caret animation
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
## Question 8: Target deployment / hosting
|
|
Is there a specific hosting target already in mind for this static React site (relevant later for build output configuration)?
|
|
|
|
A) Not decided yet — keep the build generic (static output, deployable anywhere)
|
|
B) Static hosting / CDN (e.g. Netlify, Vercel, Cloudflare Pages, GitHub Pages)
|
|
C) Traditional web host via FTP/manual upload (as hinted by the `demo-setup` / on-premises style deployment)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|
|
|
|
## Question 9: Browser/device support baseline
|
|
What is the minimum browser/device support baseline for this site?
|
|
|
|
A) Modern evergreen browsers only (latest Chrome, Firefox, Edge, Safari) — matches the reference's use of modern CSS (backdrop-filter, clamp, etc.)
|
|
B) Broader legacy support required (older browsers, e.g. older Safari/IE-adjacent) with graceful degradation
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
## Question: Security Extensions
|
|
Should security extension rules be enforced for this project?
|
|
|
|
A) Yes — enforce all SECURITY rules as blocking constraints (recommended for production-grade applications)
|
|
B) No — skip all SECURITY rules (suitable for PoCs, prototypes, and experimental projects, or for a marketing-only static site with no backend/user data)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
## Question: Property-Based Testing Extension
|
|
Should property-based testing (PBT) rules be enforced for this project?
|
|
|
|
A) Yes — enforce all PBT rules as blocking constraints
|
|
B) Partial — enforce PBT rules only for pure functions and serialization round-trips
|
|
C) No — skip all PBT rules (suitable for this kind of largely static, UI-only marketing site with no significant business logic)
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|
|
|
|
## Question: Operations Phase
|
|
Should this feature go through the Operations phase after Construction (setting up deployment and monitoring)?
|
|
|
|
A) Yes — run the Operations phase after Construction (deployment + monitoring setup)
|
|
B) No — stop after Build and Test (deployment/monitoring are out of scope for this feature)
|
|
C) Not sure yet — ask me again after the Construction phase
|
|
X) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|