- name
- Ada
- places
- 4
- delivery
- Not sent
Start with a task people recognise.
A training organiser needs names, a number of places and a clear confirmation. A fixed document can collect some answers. An application can also explain what is missing, calculate a preview and adapt the next section to the answers. The useful question is what should happen while the person is filling it in.
Our story is a registration workflow. The screens and figures in this tour are explanatory snapshots. Working examples are linked at the end of each chapter; the complete registration-to-PDF service is a project you would build.
Give each part one responsibility.
Source describes fields, labels and behavior. A Data Bag holds the registration values. The browser runtime renders the Source and connects it to Data. A field and a confirmation can read the same name without your application copying text from one DOM element to another.
This separation becomes more useful as the form grows: the name is application data whether it came from typing, a restored file or a response. What matters to the view is the Data path.
Watch the same story develop.
First we connect one field to a name. Then we calculate a total, explain rejected edits, request a new block of interface and decide how the completed data leave the browser. Each step adds a capability because the workflow needs it.
You can follow the whole tour without installing anything. If a particular feature catches your attention, its deeper explanation stays on this website.
Before you continue
If the name appears in three places, where should it be stored?
Reveal the explanation
In one Data path. Each view can read that path; the application does not need three independently maintained copies.
Try the working example and read the full contract
KEEP EXPLORING