Web Programming with JavaScript: From DOM to APIs

Module 3: The Person Enters Invalid Data

Course progress0%
Course content

Module 1

Your Program Works. Can Someone Use It?Design the Page around the TaskRender the Data, Preserve the RulesLab: Prove the Interface Preserves the Contract

Module 2

A Click Is an Intention, Not a Business RuleWhere Does the Current Order Live?Render Results without Fighting the User

Module 3

Form Values Are Not Yet Order DataA Rejection Must Explain the Next ActionLab: Make a Quote Editable without Duplicating Policy

Module 4

An Order Has States, Not Just ButtonsA Disabled Button Is Not Enforcement

Module 5

Save a Draft, Not a PromiseTwo Tabs, One Draft

Module 6

HTTP Is a Contract between Two ProgramsBuild Your Own Local HTTP LabFetch without Hiding Loading or Failure

Module 7

The Last Intention Wins, Not the Last ResponseRetry Is a Business Decision

Module 8

The Browser Is Not the AuthorityConflicts and Repeat Submissions

Module 9

Can the Person Finish without a Mouse?Readable Results and Useful Performance

Module 10

Tests That Challenge the ContractTest Time Order, Not Just Values

Module 11

Review Generated Code with Evidence

Module 12

Boundaries before More FilesLifecycle and Tooling Have a Purpose

Module 13

Final Project: The Order WorkbenchFinal Review: Can You Handle the Next Change?

Module 14

What Would a Framework Actually Own?Framework Readiness: Explain before You Adopt
90 min

Lab: Make a Quote Editable without Duplicating Policy

Integrate conversion, domain validation and rendering

By the end of this lesson

  • Integrate conversion, domain validation and rendering
  • Demonstrate normal, invalid and changed-input behavior

Mission

Extend your first browser page with an editable one-item order. The person can change the customer name/type, active status, item name, price and quantity, then calculate. The quote still uses Course 02's pricing function unchanged.

Before implementing, write an acceptance table. A premium active customer buying one 150-unit item should see 162.00 total. At 100 units there is no discount and the total is 120.00. A standard customer buying two 150-unit items pays 360.00. Zero quantity is rejected.

Build in stages

  1. Add real labels and native form controls with stable names.
  2. Implement readOrderForm using the parser and issue strategy from the previous lessons.
  3. Keep an in-memory draft and a dirty/ready/error phase.
  4. Register a single submit handler in main.js.
  5. On input, mark the quote outdated and hide the previous breakdown.
  6. On submit, parse, validate, calculate and render the outcome.
  7. Add Restore example as a type=button action that replaces the draft with a fresh copy of your initial data.

Keep values in cents inside the domain. Restoring must copy the nested items too, so editing the restored draft does not mutate the original example.

Demonstrate one complete flow

Start at 162.00. Change quantity to 2: the previous result must no longer appear current. Submit: expect 324.00 for premium or 360.00 for standard. Clear price and submit: show a price issue, not zero. Restore: return to the baseline values and calculate 162.00 again.

Do not rely exclusively on visual inspection. Call your parsing and state functions with equivalent values in a test file and compare the outcomes. Keep Course 02's domain tests as regression checks.

Counterexample

A developer adds a 10% discount directly in the form handler because it is only one line. Set the subtotal exactly at 100 units: this often exposes a missing threshold condition. Remove the duplicated calculation and use the existing quote result instead.

Independent change request

"Now add a second item." Identify the affected model, controls and rendering. A permanent item id should identify which quantity changes; an array index alone becomes unreliable after removal. Implement this extension only after the one-item flow passes. Do not rewrite pricing: it already sums valid items.

Review criteria

Customer text resembling HTML stays literal. Keyboard submission works. Error correction preserves input. Restore does not submit twice. A removed or invalid item does not leave its amount behind. No action claims to save or purchase anything yet.

Deliverable

Submit your source, acceptance table and a short recording of the ready -> dirty -> error -> ready sequence. Explain one defect your counterexample revealed. The goal is a reliable interaction, not a large number of controls.

Lesson complete?

Your progress is saved on this device.