2.0 KiB
NFR Design Questions — Unit 3: frontend-cms-page
Please answer each question by filling in the letter after the [Answer]: tag.
If none of the options match, choose the last option (Other) and describe your preference.
Question 1
Where should the Zod form schemas for AddCmsInstanceDialog and SetStatusDialog live?
Context: src/lib/schemas/auth.ts holds shared auth schemas (used by LoginPage, SetupPage, InviteCompletePage, and tested in auth.test.ts). InviteUserDialog defines its schema inline.
A) Inline in each component file — addInstanceSchema defined inside AddCmsInstanceDialog.tsx, setStatusSchema inside SetStatusDialog.tsx. Pragmatic: each schema is single-use and lives next to the form that uses it. Consistent with InviteUserDialog.tsx pattern.
B) Centralised in src/lib/schemas/cms.ts — Both schemas exported from a single module, tested separately in src/lib/schemas/cms.test.ts. Consistent with the auth.ts pattern; schemas are independently testable.
C) Other (please describe after [Answer]: tag below)
[Answer]: C, I want all schemas to live in the src/lib/schemas folder. Do it also for schemas that are inlin or otherwise not in that directory to make it consistent and easy to find.
Question 2
How should hook-level API errors be surfaced to the component?
Context: TanStack Query exposes mutation.error on the mutation object. Two approaches are used in this project:
A) mutation.error prop — component reads mutation.error directly and passes { message: mutation.error.message } to FormErrorBanner. Pattern used by InviteUserDialog (inviteUser.error). No extra state.
B) Local useState<string | null>(null) — component owns a serverError string, set in the mutation onError callback. Pattern used by LoginPage. Allows custom i18n error messages per status code (e.g. 409 Conflict → "Name already in use").
C) Other (please describe after [Answer]: tag below)
[Answer]: B, also make it consistent accross the projects if possible.