You already have the difficult part started
In Course 02's final project, you built a small order program. It validates records, calculates prices and reports failures. Its rules have tests. Now someone says:
"I want to see the order in a page instead of reading the console."
This request starts our web course. We will use the same small program, not introduce an unrelated application or a large SaaS. The situations in this course are teaching scenarios, not invented accounts of client projects.
Pause before reading: What does "see the order" mean? Write three questions that could change the page you build. Then describe one thing that should stay unchanged from Course 02.
What you bring from Course 02
You should already be able to explain a function's inputs and result, validate an order, run its assertions and split responsibilities between JavaScript files. Revisit why we split code and named imports and exports if those steps are unclear.
A course module is a group of lessons. A JavaScript module is a file with explicit imports and exports. The shared word does not make them the same concept.
| Already introduced in Course 02 | How Course 03 uses or extends it |
|---|---|
| Functions, objects and validation | Keep the existing order rules behind the interface |
| JavaScript modules and relative imports | Reuse the domain files in a browser page |
| Node and package.json with type set to module | Keep running .js domain files and tests in Node |
| Assertions and asynchronous functions | Test interactions and handle HTTP success and failure |
We introduce HTML, the DOM, forms, browser state and HTTP progressively. Later, the local HTTP lab explains npm scripts before asking you to use them. You do not need to know a framework or package installation workflow to begin.
Readiness check: run your Course 02 order tests and explain which file owns the discount decision. If either step is unclear, return to that project before adding the interface.
How to use the time estimates
The lesson durations estimate active study: reading, implementing the requested increment, checking results and reviewing mistakes. They are not reading times or measured learner averages. Their current total is about 28 hours, including the labs and final project. The course range of 30 to 40 hours adds an indicative allowance for setup, debugging and revision; it has not been validated with a learner cohort.
The final project assembles the increments you build along the way; its estimate assumes those checkpoints already work. Optional extensions can take additional time. Use the estimates to plan sessions, not as deadlines or a measure of ability. Move on when you can explain and verify the behavior.
Investigate the task behind the screen
Questions such as "Should the page be blue?" do not establish what the person needs. Ask instead:
- Is the person checking a quote, editing a draft or confirming a sale?
- Which amounts must they understand before making a decision?
- What must happen if the order cannot be quoted?
- Does seeing a quote mean anything has been saved or purchased?
For this first module, confirm a small scope: review an order, vary its example inputs and understand its calculated quote. Build the first view yourself, then vary the customer, item, price and quantity in your sample data to test the scenarios. There is no payment or server persistence yet. A quote is a calculation, not a completed purchase.
These boundaries matter. A button labeled "Confirm purchase" would promise behavior the program does not implement. Begin with a clear quote display; add controls only when you can define and implement their behavior.
Carry forward the existing contract
If you completed Course 02's changed-threshold exercise, use your saved baseline or restore its strict comparison before starting here. The experimental inclusive threshold belongs to a separate policy version. Check the exact-threshold test before adding HTML.
Keep the Course 02 exercise policies:
| Decision | Confirmed behavior |
|---|---|
| Amount representation | Integer cents; 100 cents per exercise unit |
| Item quantity | Positive whole number |
| Customer | Active, with standard or premium type |
| Premium discount | 10% only when subtotal is strictly above 10,000 cents |
| Rounding | Round discount, then tax, to the nearest cent |
| Exercise tax | 20% of the discounted subtotal |
| Invalid record | Reject the quote with an explanation |
These are fictional pricing policies, not legal or tax guidance. The interface must explain the result without creating a second version of the pricing formula.
Separate three kinds of decisions
Business rule: an inactive customer cannot receive a quote in this exercise.
Presentation decision: show an explanatory message instead of an amount when a quote is unavailable.
Technical mechanism: replace the appropriate DOM content with that message.
The DOM is the browser's object representation of the document. It lets JavaScript interact with page elements; it should not become the only place where a business rule exists.
Write behavior before markup
For an active premium customer with a subtotal of 15,000 cents, display subtotal 150.00, discount 15.00, tax 27.00 and total 162.00 exercise units. Explain the components, not just the final amount.
For an inactive customer, display that the quote is unavailable. Do not show 0.00: zero is a valid amount, not a failure state. Do not leave a previous successful total visible beside the error.
For exactly 10,000 cents, a premium customer receives no discount. This boundary must remain correct after adding the page.
Challenge the first proposal
A proposed design contains only a large total and a green "Success" badge. What does success mean: calculated, saved, approved or paid?
Review
The label is ambiguous. Use wording such as "Calculated quote" and name the displayed amounts. A clear screen states what happened without implying operations outside its scope. More visual polish cannot repair an unclear promise.
Independent exercise: a new request
The person asks: "Can I cancel from this page too?" Write the questions you need before adding a button. Include at least one question about state and one about failure.
Correction and reasoning
Ask which states allow cancellation, who is allowed to act, whether cancellation changes inventory, where the change is saved and what happens if saving fails. A draft and a delivered order need not follow the same policy. Do not invent those answers. We will model transitions explicitly in a later module.
Keep your decision journal
Record the original request, confirmed scope, unresolved questions and three acceptance examples. The evidence you collect now will guide HTML, rendering and tests. Our routine remains: understand, question, decide, implement, verify, revise.
Check your understanding
- Why reuse the tested calculation instead of rewriting it in a click handler?
- Why is an unavailable total different from a zero total?
- Does displaying a quote prove the order was saved?
Answers
- One pricing policy should have one authoritative implementation, with tests independent of the interface.
- Zero is a valid numeric result; unavailable means no approved result exists.
- No. Display and persistence are separate responsibilities, and this version only displays a calculation.