ehoandClaude Opus 5
fc2a3c348b
RD-22 and RD-23 brought the wizard containers under the 250-line budget, so `max-lines` reports nothing. The files still read badly. Line count was never the problem. Fix three things in all three containers: 1. The member order was scrambled, and it differed per file. `registratie` declared `draftSync` in the middle of a run of `computed`s; `herregistratie` read `this.stepLabels.length` seven lines before `stepLabels` existed; the three files put the copy arrays in three different places. All three now use one nine-section order, so they compare side by side. 2. Pure logic sat in the container. Extract `digitalDocumentIds` into `upload.machine.ts` — the "digital and finished uploading" filter was written out four times, and it removes a `documentId!` assertion from both containers. Extract `diplomaMsg` into a sibling of the step files. 3. Comments carried archaeology. Drop the three RD-05 references and keep the rule. Drop "replaces sessionStorage" and the note about focus management that moved to the shell. Fix `intake`'s class comment, which claimed answers persist to sessionStorage and was contradicted 30 lines below. `phase` deliberately stays in all three: it cannot live in `domain/`, and three siblings plus three specs is a worse trade than 17 readable lines. The store ⇄ `draftSync` cycle also stays — both callbacks are deferred, so it is safe, and one comment now names it. No behaviour change. Member lists and every `private`/`protected`/`readonly` modifier are unchanged, which the showcase depends on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
29 lines
1.2 KiB
TypeScript
29 lines
1.2 KiB
TypeScript
import { DuoLookupDto } from '@registratie/contracts/duo-diplomas.dto';
|
|
import { RegistratieMsg } from '@registratie/domain/registratie-wizard.machine';
|
|
import { HANDMATIG } from './beroep.step';
|
|
|
|
/**
|
|
* Resolve the diploma that the user picked into the machine message it implies.
|
|
*
|
|
* The DUO payload maps a diploma id onto a server-derived beroep and the policy
|
|
* questions that apply to it. Reading that map is message construction, so it
|
|
* belongs beside the container, not in the beroep step. The backend stays the
|
|
* authority on both values (ADR-0001) — this function only selects them.
|
|
*
|
|
* Returns null when the id matches no known diploma. The caller then dispatches
|
|
* nothing and the wizard keeps its current state.
|
|
*/
|
|
export function diplomaMsg(data: DuoLookupDto, id: string): RegistratieMsg | null {
|
|
if (id === HANDMATIG) {
|
|
return { tag: 'KiesHandmatig', vraagIds: data.handmatig.policyQuestions.map((q) => q.id) };
|
|
}
|
|
const diploma = data.diplomas.find((d) => d.id === id);
|
|
if (!diploma) return null;
|
|
return {
|
|
tag: 'KiesDiploma',
|
|
diplomaId: diploma.id,
|
|
beroep: diploma.beroep,
|
|
vraagIds: diploma.policyQuestions.map((q) => q.id),
|
|
};
|
|
}
|