Porter depuis React

Vous ne repartez pas de zéro. L’essentiel d’un écran React se convertit tel qu’il est écrit : sa mise en page, ses textes, ses boutons et ses champs, ses conditions et ses listes, ses propres petits composants. Le reste est soit une courte réécriture, soit un travail qui passe dans votre application, et c’est bien là qu’il a sa place sur un ordinateur qui n’a qu’une tâche.

Mesurez d’abord

Avant de changer une ligne, demandez au Screen Compiler jusqu’où votre code va déjà. Clonez votre application à côté des deux dépôts de Des écrans issus de React, pour que le conteneur de développement la voie, et lancez le rapport de couverture sur ses sources :

cd nowayos-work # holds nowayos and screen-compiler
git clone https://example.com/your-app.git my-app
cd screen-compiler
make run ARGS="audit ../my-app/src"

Le rapport lit chaque fichier .tsx sous ce dossier et compte chaque construction qu’il y trouve : éléments, props, propriétés de style, hooks, listes, conditions, opérateurs et imports. Chacune reçoit un verdict :

• dans le sous-ensemble : elle se convertit, là où elle est utilisée comme le sous-ensemble le permet ;
• en route : elle ne se convertit pas encore, et le rapport nomme l’étape qui la convertira ;
• exclue par conception : elle ne se convertira jamais, et le rapport dit pourquoi ;
• inconnue : le Screen Compiler ne la reconnaît pas. Une construction inconnue n’est jamais comptée comme convertie.

Viennent ensuite les étapes de la route, avec la fréquence de chacune, et chaque fichier avec son résultat. Un fichier « se convertit » seulement si check l’accepte : le chiffre en haut est donc le vrai. Le rapport nomme des constructions et ne cite jamais votre code, vous pouvez donc le partager sans risque. Comme le compilateur lui-même, ne le lancez que sur du code auquel vous faites confiance.

Ce qui correspond à quoi

Les tableaux de Des écrans issus de React indiquent exactement ce que chaque composant accepte. Ils viennent des tables du Screen Compiler lui-même : ils ne peuvent donc pas s’écarter de ce qu’il accepte.

Ce qui passe dans votre application

Il n’y a pas de JavaScript sur l’appareil. Un écran est un arbre fixe que votre application pilote par des actions, des champs, des emplacements, des groupes et des commutateurs numérotés. Certaines choses restent donc exclues par conception, chacune pour une raison :

• L’état et les hooks (useState, useEffect, le contexte). L’application détient l’état et définit ce qu’un écran affiche.
• value, checked et onChange d’un champ. L’application lit et définit un champ par son id.
• Les props étalées (spread). Leur contenu n’est connu qu’à l’exécution du code.
• Les styles calculés, les valeurs de couleur et les feuilles de style globales. Un style est statique, les couleurs sont celles du thème, pour que le thème en gros caractères puisse recolorer chaque écran et que le contraste soit vérifié, et il n’y a pas de cascade.
• L’animation.
• Une liste sans maximum. Limitez-la, .slice(0, 5), pour que l’écran sache combien de lignes il peut afficher.
• Les comparaisons autres qu’une prop === une chaîne, et if ou switch dans la fonction d’un écran. Calculez la réponse dans l’application et passez-la en prop.
• Les composants venus de paquets, et les fichiers hors du dossier de l’écran. Un écran ne lit que son propre dossier et ce qu’il contient : placez vos composants à côté de lui, ./parts/header.
• Un gestionnaire qui fait plus qu’appeler une prop. onClick={() => props.onSave()} se convertit ; tout le reste est le travail de l’application.

Ce que la route apporte ensuite

Le rapport de couverture nomme ces étapes prévues quand votre code en a besoin :

• davantage de mise en page CSS : croissance flex, alignSelf, hauteurs minimale et maximale, marges intérieures sur chaque côté, et marges ;
• les éléments HTML courants, chacun selon une règle fixe ;
• les modules CSS, une classe par élément ;
• la superposition : des éléments posés les uns sur les autres ;
• les images et la saisie masquée.

Tant qu’une étape n’est pas livrée, ses constructions sont refusées plutôt que devinées. Chaque étape garde la même règle : exact, ou rien.

Lire une erreur

Une erreur donne le fichier, la ligne et la colonne, un code, ce qui ne va pas, et une ligne d’aide :

web-search.tsx:16:28: error[unknown-name]: `query` is not a prop of the component
 help: text from the application must be a prop: take it as one, function Screen({ query }) { … }

À la moindre erreur, rien n’est écrit. Les codes :

Si une construction dont vous avez besoin est en route sans être encore construite, dites-le, rapport à l’appui : il montre quelles étapes comptent le plus.