A mobile application from end to end
A scaffold, the starting structure automatically generated for an application, navigation between screens, a network call and a correction of the types flagged by errors can all be chained within a single work session, with a preview that updates on your own phone at every change.
A scaffold, the starting structure automatically generated for an application, navigation between several screens, a network call to a service and a correction of the types flagged by errors can all be chained within a single work session, with a preview that updates on your own phone at every change to the code.
The path in five steps
The scaffold first lays down the structure: folders, empty screens, a configuration file. Navigation comes next, the link between these screens, a button on the first that opens the second. The network call follows: a screen requests data from a service and displays it as soon as it arrives. Type corrections generally come on their own at this stage: the type system flags a field that is expected but missing, or a text value used where a number is required, and each signal is corrected before moving to the next. The last step is not really one: it is verification, at every previous step, on the actual preview displayed on the phone.
Keeping the preview open
The difference between a productive session and one that goes off the rails comes down to a single choice: opening the preview from the first screen and keeping it displayed throughout the path, rather than coding several steps and checking only once at the end. An error seen immediately after it is introduced is corrected within seconds, because the only recent change responsible is obvious. The same error, discovered after five other changes, forces a search for which of the five caused it.
The example below fabricates its own data, a products screen that calls no real service, to illustrate what the preview should display at this stage of the path.
// Écran Produits, données fabriquées localement pour cet exemple
const produits = [
{ id: 1, nom: "Etui", prix: 12 },
{ id: 2, nom: "Support", prix: 18 },
{ id: 3, nom: "Cable", prix: 9 }
];
function chargerProduits() {
return produits;
}
console.log(chargerProduits().length, "produits charges");
Three products loaded, displayed immediately on the preview screen even before a real network service is connected. Once this same screen has been checked with fabricated data, replacing the function with a real network call becomes an isolated correction, not a new step made blind.
The move that repeats itself
This path, scaffold, navigation, network call, type correction, continuous verification, repeats itself for every new screen of an application. The third time it repeats identically deserves different treatment, the one described in automating your own practice, stack and skill: turning a repeated move into a named command rather than typing it out a fourth time.
The path of a mobile feature, from scaffold to preview
A developer adds a screen to her application that displays a list of locally fabricated products. She opens the preview on her phone and watches the three products appear. She then replaces the function that supplies the products with a network call to an external service.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: This move establishes that the screen correctly displays the data when it has the expected shape, checked before any network connection.
What this does not establish: It does not establish that the network call which has just replaced the fabricated data will return data in the same shape, since its result has not yet been observed.
The three most common miscalibrations
- Too broad This move establishes that the entire application now works with real data.
- Too narrow This move establishes nothing, since locally fabricated data never replaces a test on the finished product.
- Beside the point This move shows that the phone preview updates with every change to the code.
- A scaffold lays down an application's starting structure before navigation, network calls and type corrections are chained within the same session.
- A preview opened from the first screen and kept open throughout the path allows an error to be corrected as soon as it appears, rather than having to search which of several changes caused it.
- A screen checked with locally fabricated data isolates display logic from network logic, and makes connecting the real service easier to correct on its own.
- A path repeated identically a third time is a signal to turn it into a named command rather than redoing it by hand.
Open your application's preview on your own phone right now, keep it displayed, and change a single screen to confirm the change appears before changing a second one.