Présentation dans xuui

Que fait Présentation dans xuui ?

Transformez le travail de la conversation en cours en une étude xuui exécutable et révisable. Le résultat est une URL locale vérifiée, une brève explication de la question de conception, et les différences qui méritent d'être examinées. Après la remise, continuez d'écouter les commentaires de la personne.

Restez dans xuui

xuui est la surface de présentation pour ce travail. Une fois qu'un design est dans xuui, continuez de le présenter là-bas.

• Lorsqu'une autre compétence ou workflow est également en jeu, utilisez sa méthode pour choisir les directions, mais construisez les directions comme des variantes xuui. Ne construisez jamais son sélecteur, un commutateur dans l'application, ou une page d'aperçu séparée.
• "Affichez-le dans la page entière", "dans le site" ou "en contexte" signifie une étude xuui plus large : rendez la page ou la disposition environnante autour du design, avec les mêmes variantes.
• Modifiez l'application réelle uniquement lorsque la personne demande d'implémenter ou de livrer une direction. Conservez l'étude, afin que le choix reste révisable.

Déterminez quoi présenter

Utilisez l'UI demandée, la référence ou le travail récent comme brief. Présentez une implémentation existante fidèlement. Lorsque le brief demande des alternatives, faites en sorte que leurs différences répondent à la question de conception ; choisissez le nombre indiqué dans le brief et les comparaisons utiles. Ne demandez que lorsque la conversation et l'espace de travail laissent le sujet flou.

Trouvez l'espace de travail d'étude à partir du projet actuel : un espace de travail installé contient xuui.studies.ts et une dépendance xuui locale. Lisez le README de cette version, docs/authoring.md, et les types exportés, ainsi qu'un enregistrement à proximité. Utilisez le CLI installé plutôt que de télécharger une alpha plus récente dans un espace de travail existant. Une copie source de xuui utilise plutôt examples/studies.ts, src/xuui/model.ts, et src/xuui/parameters.ts ; lisez CONTEXT.md là-bas. N'inférez pas l'espace de travail consommateur en remontant depuis une compétence installée.

L'alpha présente les composants React enregistrés dans un espace de travail autonome. Si un nouvel espace de travail est nécessaire, exécutez npx --package @getxuui/[email protected] xuui init <directory>, puis utilisez son installation figée. Pour un travail provenant d'une autre base de code, inspectez ses tokens, l'UI voisine, les contraintes responsives, les fournisseurs de contexte et les données. Adaptez le composant concerné et les dépendances nécessaires sans le reconcevoir silencieusement. Incluez un wrapper de contexte lorsque l'isolation déformerait la révision, et divulguez les données simulées ou le comportement backend indisponible.

Cadrez une exploration

Lorsque des alternatives sont demandées, énoncez la question de conception, nommez la variable principale, et dites ce qui reste constant. Planifiez des directions qui répondent à cette question. Commencez-les avec un contenu cohérent, un état significatif, une largeur de fenêtre et une échelle appropriées. Ne générez pas d'alternatives pour une demande de présentation fidèle d'un design existant. Laissez le brief et les comparaisons utiles déterminer le nombre.

Enregistrez l'étude

Placez le design et son adaptateur à côté de l'enregistrement de l'étude, en suivant les études existantes. Ajoutez l'étude au registre central, ou étendez l'étude existante pertinente lorsque le travail explore la même question.

• Utilisez les termes produit study, variant, canvas, layer, et guide. Enregistrez une étude avec defineStudy et listez ses variants.
• Donnez à chaque variante un ID descriptif stable et unique parmi toutes les études enregistrées. Ajoutez un nouvel ID lorsque vous faites évoluer une direction qui doit rester révisable. Conservez l'implémentation précédente ; le partage d'un composant mutable ne fige pas son historique.
• Écrivez un nom, une description et une justification utiles pour chaque variante.
• Enregistrez des composants React ordinaires. xuui fournit la navigation, le panoramique, le zoom, l'inspection, la comparaison et les commentaires ; l'étude fournit le design et les fournisseurs de contexte ou données dont il a besoin.
• Limitez le CSS de l'étude pour qu'il ne puisse pas restyler le chrome du studio ou les variantes non liées. Donnez au design des dimensions significatives ; une largeur en pourcentage sans bloc contenant dimensionné peut s'effondrer sur le canvas.
• Ajoutez data-xuui-layer-name là où le DOM seul donne un nom de calque inutile.

Exposez les états et contrôles

La barre latérale affiche les contrôles déclarés par une variante, et le réviseur commente ce qui est rendu. Choisissez le type de contrôle qui correspond au design :

• machine pour les états distincts du design et les événements qui les font passer : vide, chargement, chargé et erreur ; fermé et ouvert ; les étapes d'un formulaire ou d'un flux. Le réviseur peut accéder à n'importe quel état depuis la barre latérale et suivre les transitions en mode Play, afin que chaque état puisse être jugé et commenté. Nommez les états et événements comme le produit le fait. Rendez à partir de machine.value, et connectez les interactions réelles du design à machine.send(event), de sorte que cliquer en mode Play suive la même machine.
• state pour les valeurs indépendantes auxquelles le design réagit, comme un toggle favori ou un nombre d'éléments.
• props pour les paramètres de conception qui méritent d'être comparés, comme le texte, le rayon ou la largeur.

Lorsque le design a des états significatifs au-delà du chemin heureux, exposez-les avec une machine plutôt que de présenter un seul état. N'inventez pas d'états que le design n'a pas. N'exposez que les contrôles qui modifient le design rendu, et vérifiez que chaque état s'affiche correctement. Consultez le docs/authoring.md installé pour la forme exacte.

Limitez les modifications à l'étude demandée et à l'enregistrement nécessaire pour la présenter. Une demande de présentation n'autorise pas à reconcevoir le studio lui-même.

Terminé signifie que le design demandé s'affiche à partir d'une variante enregistrée et que ses contrôles exposés fonctionnent.

Exécutez et vérifiez

Dans un espace de travail installé, utilisez npx --no-install xuui dev ; dans une copie source, utilisez ses scripts de package. Vérifiez d'abord l'existence d'un aperçu existant et réutilisez-le lorsqu'il dessert l'espace de travail prévu. Laissez les processus non liés tranquilles. Gardez le serveur local en cours d'exécution pour le réviseur et utilisez l'origine réellement imprimée.

Ouvrez une URL en utilisant l'origine réelle du serveur et les IDs enregistrés :

• Variante ciblée : /?study=<study-id>&variant=<variant-id>
• Comparaison : la même URL avec &view=all

Vérifiez l'identité de la variante rendue, plutôt que de traiter un HTTP 200 comme une preuve : des IDs inconnus tombent par défaut sur une étude existante. Inspectez l'UI, exercez les interactions importantes en mode Play, et testez chaque contrôle exposé. Appliquez le même seuil d'utilisabilité à chaque direction : accessibilité clavier, focus de contrôle entier visible, texte lisible, mouvement réduit approprié, et contenu, états et largeurs réalistes. Exécutez les vérifications de projet pertinentes et signalez les échecs ou les vérifications indisponibles avec précision.

Utilisez un stockage de test isolé pour les vérifications de soumission. Laissez les commentaires réels du réviseur et les enregistrements soumis intacts.

Terminé signifie que le lien ouvre le design prévu, que les interactions significatives fonctionnent et que le périmètre de révision est clair.

Remettez

Retournez le lien ciblé, ainsi qu'un lien de comparaison lorsque c'est utile. Expliquez ce qu'il faut juger en quelques phrases et nommez les limitations matérielles telles que les données simulées. Le réviseur utilise Play pour les interactions, C pour les commentaires, et Submit review pour la remise. Terminez en disant que vous écoutez leur révision et qu'ils peuvent continuer à discuter entre-temps.

Pour les alternatives, ajoutez un petit tableau de ce qui a changé, quand chaque direction convient, et son coût principal. Indiquez la largeur et l'état examinés. Ne choisissez pas silencieusement un gagnant. Lorsqu'on vous demande de faire avancer un choix, vérifiez le design promu dans son contexte source et conservez son étude révisable ; préservez les anciennes implémentations et ajoutez des IDs stables pour d'autres travaux comparables.

Écoutez les retours

Après la remise, attendez la révision sans qu'on vous le demande.

• Si les outils MCP de xuui sont disponibles, appelez xuui_wait_for_review avec le studyId de l'étude. Chaque appel retourne dans les 50 secondes. Rappelez-le avec les knownReviewIds retournés jusqu'à ce qu'une révision arrive ou que la personne vous demande d'arrêter.
• S'ils ne sont pas disponibles, le serveur MCP de l'espace de travail n'est pas connecté. Proposez de le connecter, en suivant le docs/mcp.md installé, et dites si l'hôte a besoin d'un redémarrage pour le charger. En attendant, si votre hôte peut exécuter une commande en arrière-plan qui vous notifie lorsqu'elle se termine, utilisez-en une pour attendre un nouveau fichier dans .xuui/reviews/. Sinon, demandez à la personne de vous dire quand elle a soumis.

Lorsqu'une révision arrive, lisez le paquet complet, puis accusez réception avec xuui_acknowledge_review. Un accusé de réception signifie que vous l'avez lue, pas que ses demandes sont terminées. Les brouillons dans le navigateur ne sont pas des retours soumis. Agissez sur les commentaires : apportez des modifications sous forme de nouvelles variantes avec de nouveaux IDs, vérifiez-les, remettez les nouveaux liens, et écoutez à nouveau.