Accueil / Cas réels de bout en bout
Une application mobile de bout en bout
Un scaffold, la structure de départ générée automatiquement pour une application, une navigation entre écrans, un appel réseau et une correction des types signalés par erreur peuvent s'enchaîner dans une seule session de travail, avec une prévisualisation qui se met à jour sur votre propre téléphone à chaque modification.
Un scaffold, la structure de départ générée automatiquement pour une application, une navigation entre plusieurs écrans, un appel réseau vers un service et une correction des types signalés par erreur peuvent s'enchaîner dans une seule session de travail, avec une prévisualisation qui se met à jour sur votre propre téléphone à chaque modification du code.
Le trajet en cinq étapes
Le scaffold pose d'abord la structure : dossiers, écrans vides, fichier de configuration. Vient ensuite la navigation, le lien entre ces écrans, un bouton sur le premier qui ouvre le second. L'appel réseau suit : un écran demande des données à un service et les affiche dès qu'elles arrivent. Les corrections de types viennent en général d'elles mêmes à ce stade : le système de types signale un champ attendu et absent, ou une valeur textuelle utilisée là où un nombre est requis, et chaque signal se corrige avant de passer au suivant. La dernière étape n'en est pas vraiment une : c'est la vérification, à chaque étape précédente, sur la prévisualisation réelle affichée sur le téléphone.
Garder la prévisualisation ouverte
La différence entre une session productive et une session qui déraille tient à un seul choix : ouvrir la prévisualisation dès le premier écran et la laisser affichée pendant tout le trajet, plutôt que de coder plusieurs étapes puis de vérifier une seule fois à la fin. Une erreur vue immédiatement après l'avoir introduite se corrige en quelques secondes, parce que la seule modification récente en cause est évidente. La même erreur, découverte après cinq autres modifications, oblige à chercher laquelle des cinq l'a causée.
L'exemple ci dessous fabrique ses propres données, un écran de produits qui n'appelle aucun service réel, pour illustrer ce que la prévisualisation doit afficher à cette étape du trajet.
// É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");Trois produits chargés, affichés immédiatement sur l'écran de prévisualisation avant même qu'un service réseau réel soit branché. Une fois ce même écran vérifié avec des données fabriquées, remplacer la fonction par un appel réseau réel devient une correction isolée, pas une nouvelle étape à l'aveugle.
Le geste qui se répète
Ce trajet, scaffold, navigation, appel réseau, correction de types, vérification continue, se répète à chaque nouvel écran d'une application. La troisième fois qu'il se répète à l'identique mérite un traitement différent, celui que décrit automatiser sa propre pratique, pile et skill : transformer un geste répété en commande nommée plutôt que de le retaper une quatrième fois.
Le trajet d'une fonctionnalité mobile, du scaffold à la prévisualisation
Une développeuse ajoute à son application un écran qui affiche une liste de produits fabriqués localement. Elle ouvre la prévisualisation sur son téléphone et observe les trois produits s'afficher. Elle remplace ensuite la fonction qui fournit les produits par un appel réseau vers un service externe.
Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.
Ce que cela établit : Ce geste établit que l'écran affiche correctement les données quand elles ont la forme attendue, vérifié avant tout branchement réseau.
Ce que cela n’établit pas : Il n'établit pas que l'appel réseau qui vient de remplacer les données fabriquées renverra des données dans la même forme, puisque son résultat n'a pas encore été observé.
Les trois calibrages faux les plus courants
- Trop large Ce geste établit que l'application entière fonctionne désormais avec des données réelles.
- Trop étroit Ce geste n'établit rien, puisque des données fabriquées localement ne remplacent jamais un test sur le produit fini.
- À côté Ce geste montre que la prévisualisation sur téléphone se met à jour à chaque modification du code.
- Un scaffold pose la structure de départ d'une application avant que la navigation, les appels réseau et les corrections de types ne s'enchaînent dans la même session.
- La prévisualisation ouverte dès le premier écran et maintenue pendant tout le trajet permet de corriger une erreur dès son apparition, plutôt que de chercher laquelle de plusieurs modifications l'a causée.
- Un écran vérifié avec des données fabriquées localement isole la logique d'affichage de la logique réseau, et rend le branchement du service réel plus facile à corriger seul.
- Un trajet qui se répète à l'identique une troisième fois est un signal pour le transformer en commande nommée plutôt que de le refaire à la main.
Ouvrez la prévisualisation de votre application sur votre propre téléphone dès maintenant, gardez la affichée, et modifiez un seul écran pour confirmer que le changement apparaît avant d'en modifier un second.