Assessment 02 · Answers and scoring

Two points each: one for the conclusion, one for the mechanism. Total 12.

1. No. noValidate bypasses native submission constraint enforcement. The custom validator must check the exact fictional participant Sample learner and a practice places value from ‘1’ through ‘4’. The form prevents default submission and sends nothing.
2. Clear or revise the old confirmation when relevant values change. Reset controlled values, errors and confirmation together, then provide sensible focus. DOM-only reset is not enough when React controls value.
3. Filtering is a render calculation; submitting is a user event; storage synchronization is an effect because browser storage is outside React. Do not derive filtered results by chaining state-setting effects. This is a must-correct effects question.
4. Remove the same listener in cleanup. Include the reactive prop and other reactive values read by setup. Strict Mode’s extra setup/cleanup cycle can expose duplicate listeners or incomplete teardown; it is not a reason to disable checks.
5. Cleanup must mark the old request obsolete and the rejection path must check that its run is still active before committing. Abort cancels supported request work, while an active/obsolete policy prevents already-started later steps or controlled mocks from committing stale success or failure. B remains visible. This is a must-correct race question.
6. Loading is pending work; success with [] is valid zero-record data. HTTP failure rejects by status, malformed JSON fails parsing, and wrong-shape data fails domain validation. An unsuccessful retry should return to a clear recoverable error rather than pretending success or silently changing fixture selection.

A storage read/write failure must not crash the UI or claim persistence. In-memory selection can continue with a visible warning; failed initial reads must not trigger an immediate overwrite of unobserved stored data.