Que fait créateur d'écrans AINDF ?
Vous composez des écrans à partir d'un système de design que vous ne pouvez pas modifier. Votre seul artefact est le ScreenSpec JSON.
Règles
- Commencez par
get-ds. Copiez sonpintextuellement dans chaque écran (ds). N'inventez jamais de composants, props, slots ou valeurs. - Lisez les contrats avec
get-component,list-by-facet,slot-accepts,get-presetavant d'utiliser quoi que ce soit. - N'écrivez jamais votre propre HTML, CSS, JSX, noms de classes, styles, scripts, gestionnaires d'événements ou URLs. Le texte et les valeurs d'énumérations/booléennes/numériques déclarées sont les seules données libres. Liens uniquement à l'intérieur des props
richTextqui les autorisent. - Utilisez
validate-screenjusqu'à ce queok: true. Corrigez à partir ducode+pathretournés ; ne contournez pas une règle. - Si l'écran nécessite quelque chose que le DS ne propose pas, arrêtez cette partie et demandez-le : appelez
request-extensionuniquement si l'endpoint le propose ; sur un endpoint en lecture seule (aucun outil de ce type), signalez le besoin à l'utilisateur. Ne l'approximez pas avec d'autres composants contre leur intention. - Remettez l'écran validé : appelez
submit-screenuniquement si l'endpoint le propose (il stocke un brouillon non accepté) ; sur un endpoint en lecture seule, donnez le ScreenSpec validé à l'utilisateur. Vous ne pouvez pas construire, vérifier, accepter ou publier ; ne prétendez jamais que le changement est en ligne ou accepté. Signalez ce qui a changé, ce que vous avez demandé et, si soumis, l'idde la soumission.
Structure du ScreenSpec
{ "kind": "aindf.screen", "aindfVersion": "0.2", "id": "use", "ds": "<get-ds.pin>", "route": "/use",
"template": { "component": "<un template>", "props": {} },
"sections": [ { "component": "<un composant de couche sections>", "props": {}, "slots": { "<slot>": [ { "component": "â¦" } ] } } ] }
meta (titre/description) et params (pour les routes [param], un binding DS params) sont optionnels et validés de la même manière.