Un prompt peut-il remplacer Draftbit ?

Construis un éditeur visuel pour écrans React Native dont la seule sortie est du code source lisible. Il n’y a pas de runtime, pas d’interpréteur et pas de format propriétaire au moment du build.

Ensemble de composants, fixe et petit : Screen, ScrollView, View avec mise en page flex, Text, Image, Button, TextInput, Switch, Picker, FlatList, Card, Tabs et un navigateur du bas. Chacun a un schéma de props déclaré — l’éditeur n’expose que les props qui existent sur le composant qu’il va produire.

Canevas : un arbre d’écran à gauche, un canevas au milieu rendant aux dimensions d’un téléphone, et un panneau de props à droite. La mise en page est flexbox uniquement : direction, justify, align, gap, padding, flex. Pas de positionnement absolu, parce que le code produit doit rester lisible et un canevas qui permet de glisser n’importe où produit du code que personne ne peut maintenir.

Thème : un fichier de tokens pour les couleurs, l’échelle typographique et l’espacement. Les composants référencent des tokens, et le code produit les importe depuis un module de thème unique.

Liaison de données : définis une source de données comme un endpoint REST avec une réponse d’exemple collée. L’éditeur dérive la forme depuis l’exemple et propose ses champs pour la liaison aux props des composants. Un FlatList se lie à un champ tableau et son template d’élément se lie à la forme de l’élément. Produis un hook de fetch typé par source de données ; ne produis pas de client générique qui cache ce qui se passe.

Production de code, qui est tout l’intérêt :

- Un fichier par écran, nommé d’après l’écran, avec les composants dans l’ordre où ils apparaissent dans l’arbre.
- De vrais noms de composants et de vraies props, formatés avec Prettier — la sortie doit ressembler à du code qu’une personne a écrit.
- Les styles produits comme un bloc StyleSheet.create au bas de chaque fichier, avec des noms dérivés du rôle de l’élément plutôt que des identifiants générés.
- Un projet Expo complet : package.json, config d’application, câblage de navigation, module de thème, hooks de données. Lancer la commande documentée doit le démarrer sur un simulateur.
- La réexportation doit être non destructive : produis dans un répertoire que l’éditeur possède, et laisse intact tout fichier que le développeur a ajouté ou édité en dehors. Documente qu’une fois que tu édites le code produit, l’aller-retour est à sens unique.

Stockage : le design en JSON dans le dépôt du projet, pour qu’il soit diffable.

Hors périmètre : les builds cloud, la signature de code, la soumission aux stores, l’aperçu en direct sur appareil, une marketplace de composants, et tout service hébergé ou compte. Précise dans le README que faire arriver l’application sur un appareil est le travail de l’utilisateur et représente la moitié la plus grande de la livraison d’une application mobile.