Build a small controlled registration form with derived totals, validation and reset behavior.
A fictional workshop form collects a name and 1–4 seats. Each seat costs 15 teaching units. The displayed total is derived from seat state, not stored independently. Submitting valid data shows a local confirmation; it does not reserve real seats or transmit data.
| State or rule | Value |
|---|---|
| Initial name | empty |
| Initial seats | 1 |
| Price per seat | 15 |
| Maximum seats | 4 |
| Example seats | 3 |
Props supply values from a parent; state records values that change through interaction. Identify the minimum state needed for the form and derive the total during rendering. Redundant state can drift out of sync. Some provider examples use older class syntax; use the linked current React guidance for this functional-component exercise.
List name, seats and submission state, then identify derived values.
State model
Record your result and evidence here or in a separate file.
Total is derived from seats × 15.
Remove any state field that can be calculated from another one.
A controlled input displays a value from state and updates that state through an event handler. Numeric form input still needs careful parsing and validation. Keep labels associated with fields and use native form semantics. The interface should communicate errors without relying only on color.
Implement name and seat inputs with visible labels.
Form component
Record your result and evidence here or in a separate file.
Typing and selecting update the displayed state without uncontrolled-input warnings.
Use consistent initial values and explicit event conversion.
Validation should follow the case contract and preserve the entered data so a learner can correct it. Do not present a local mock as a server booking. A submit handler should prevent page navigation for this demonstration and show a confirmation only after the name and seat rules pass.
Add blank-name and seat-range checks plus a local-only confirmation.
Submission behavior
Record your result and evidence here or in a separate file.
Three seats show 45 units; invalid input cannot produce a success message.
Separate validation errors from the confirmation branch.
Reset is a user-facing behavior, not simply clearing the screen. Restore the initial name, one seat, 15-unit total and no confirmation. Test changing seats after an invalid submit and after a successful one. Keep the displayed result connected to the intended current or submitted state.
Run the behavior checklist and explain whether confirmation stores a snapshot.
Interaction evidence
Record your result and evidence here or in a separate file.
Reset returns the documented initial state and total remains consistent.
Decide whether a confirmation describes current input or the last submitted snapshot.
Keyboard use, labels and readable errors are part of the component’s behavior. Explain the boundary between this local form and a real booking service. The latter would need server validation, persistence and concurrency handling. Document dependencies actually used and do not claim that the local exercise implements those missing pieces.
Write a README and check keyboard order and error announcement.
Component handoff
Record your result and evidence here or in a separate file.
No network request or real reservation is implied by the confirmation.
Rename the success text to local preview if it could mislead.
Deliver the component, pure validation helper, interaction checklist and README. Demonstrate invalid submission, valid local confirmation, editing after confirmation and reset.
The total is derived consistently and local confirmation is never represented as a real booking.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
With seats=3, total is 3×15=45. Reset sets seats=1 and total becomes 15 automatically. The reference separates pure validation from the UI so the rules can be checked independently, while the actual component still needs browser interaction checks in the learner’s React environment.
This is a local component exercise, not a deployed app, payment flow or reservation backend.