3.9 KiB
NFR Design Plan — Unit 1: Project Scaffold & Infrastructure
Status: Completed — NFR design patterns and logical components generated based on answers.
Plan Checklist
- Analyze NFR requirements artifacts (nfr-requirements.md, tech-stack-decisions.md)
- Identify design pattern decisions needed for performance, a11y, testing, i18n, config
- Generate context-appropriate multiple-choice questions per question-format-guide.md
- Store this plan file
- Wait for user completion of Answer tags
- Validate answers, resolve any ambiguities
- Generate nfr-design-patterns.md and logical-components.md artifacts
NFR Design Questions
Question 1
How should TanStack Router file-based routes be organized to achieve optimal code-splitting and keep the initial JS bundle as small as possible?
A) One route file per major feature (auth, dashboard, users, cms) with lazy-loaded layouts and components B) Flat structure under src/routes/ with all routes co-located, relying on Vite's automatic tree-shaking and code-splitting C) Hybrid approach: core shell and auth routes eager-loaded; feature modules (dashboard, users, cms) lazy-loaded via dynamic imports inside authenticated layout X) Other (please describe after Answer: tag below)
Question 2
What focus management and keyboard navigation pattern should be implemented for the admin UI (sidebar navigation + main content area) to satisfy the basic a11y requirement?
A) Rely entirely on browser default Tab order + shadcn/ui :focus-visible styles; add focus trap only for modals and dialogs B) Implement roving tabindex for sidebar nav items + visible focus ring; standard Tab for main content C) Full custom arrow-key navigation and type-ahead search inside the sidebar (desktop-app style) X) Other (please describe after Answer: tag below)
Question 3
How should MSW request handlers be organized to support auth flows, 401-intercept testing, and future feature mocks while keeping tests maintainable?
A) Centralized src/mocks/handlers.ts exporting domain-specific arrays (authHandlers, userHandlers, cmsHandlers) re-exported from index
B) Feature-scoped folders under src/mocks/ (e.g. auth/handlers.ts, users/handlers.ts) with barrel re-exports
C) Inline MSW handlers defined directly inside each test file for maximum isolation
X) Other (please describe after Answer: tag below)
Question 4
What strategy should be used for loading and switching between English and Dutch translations with react-i18next?
A) Eager-load both language JSON files at app bootstrap (small total size) and keep them in memory
B) Lazy-load only the active language JSON; switch language by dynamic import of the new locale file
C) Use i18next-http-backend to fetch translations from /locales/{lng}/{ns}.json on demand (no bundling)
X) Other (please describe after Answer: tag below)
Question 5
How should RFC 9457 ProblemDetails responses be transformed into user-facing feedback (toasts/banners) while keeping the implementation simple?
A) Global error interceptor in ApiClient that maps ProblemDetails to a single shadcn/ui toast (title = title or status, description = detail) B) Per-page or per-component error handling that decides toast vs. inline message based on context C) Only show toasts for network errors and 5xx; 4xx errors are handled by form validation or redirect only X) Other (please describe after Answer: tag below)
Question 6
How should Vite environment variables (VITE_API_BASE_URL and future feature flags) be typed and validated?
A) Extend vite-env.d.ts with a typed import.meta.env interface and add optional Zod validation at runtime startup
B) Use TypeScript module augmentation for import.meta.env only; no runtime validation (trust .env files)
C) Fetch a config.json at bootstrap for all non-Vite-exposed settings; keep VITE_* vars minimal
X) Other (please describe after Answer: tag below)