Salut! Aujourd'hui, je souhaite vous présenter le fruit de mes mois de travail de nuit et de week-end, conçu pour améliorer l'expérience de gestion de contenu et apporter des fonctionnalités supplémentaires au monde du développement d'applications Flutter - un nouveau type de CMS.
Nous parlons de Nanc - N ot A N ormal C MS. Pourquoi ce n'est "pas normal" et ce que vous pouvez en faire, vous le découvrirez après avoir lu cet article.
L'article contiendra non seulement de la théorie mais aussi de la "pratique" - vous pourrez jouer dans le bac à sable Nanc. Afin de montrer au public les capacités de Nanc, deux applications de démonstration ont été créées : une application cliente qui imite n'importe quelle application Flutter et une autre qui donne une idée de ce qu'une application Nanc basée sur Flutter peut faire - Nanc CMS prédéfini. Et l'application Nanc CMS, qui est un CMS préconfiguré avec une couche supplémentaire de logique implémentée pour synchroniser l'application cliente avec le CMS.
À la fin de la plupart des blocs logiques du texte, vous trouverez une vidéo YouTube avec un exemple d'utilisation/de démonstration de certains aspects de Nanc.
Introduction
À propos du CMS
Types de modèles
Éditeur
Des champs
Applications Flutter dynamiques
Applications de démonstration Nanc
Quelle est la suite / Postfaces
Donc. Nanc est un CMS indépendant du backend qui ne tire pas son propre backend. Comment ça marche? Nanc propose d'implémenter des interfaces de services réseau, qui ont actuellement 6 méthodes mais en auront environ 10 au moment de la sortie. Est-ce beaucoup ou un peu ? Par exemple, il a fallu 170 lignes de code pour implémenter l'API pour l'application de démonstration. Ces méthodes sont responsables de tout le travail de Nanc avec votre backend existant. L'implémentation doit être écrite en Dart (le langage de développement de Flutter également). À l'avenir, Nanc viendra avec des implémentations prêtes de ces interfaces pour certaines options backend - Firebase, Supabase, SQLite local/réseau et les implémentations génériques de REST et GraphQL (peut-être autre chose ?) et vous n'aurez pas à penser à cette implémentation à tout ou devra le faire, mais juste un peu.
Un modèle dans Nanc est une description structurelle d'une entité que vous souhaitez contrôler avec Nanc. Un modèle contient un nom d'entité, divers paramètres visuels et une description des champs.
Une collection est une entité qui peut avoir plusieurs instances. Une liste d'utilisateurs, de livres et de critiques sont de bons exemples de modèles de type Collection dans Nanc.
Si vous êtes familier avec les bases de données relationnelles, un exemple de collection dans Nanc serait presque n'importe quelle table de votre base de données.
Un solo (modèle) est une entité qui existe dans une seule instance. Par exemple - Feature Toggles ou une configuration de quelque chose, ou... "L'écran principal d'une application mobile". De manière générale, les modèles Solo sont conçus pour augmenter la convivialité, n'étant qu'une projection de votre base de données. Et un modèle Solo pourrait facilement être n'importe quelle table de votre base de données avec un seul enregistrement. Mais pour le moment, l'implémentation de cette classe de modèles nécessite que l'enregistrement de ce modèle (ligne dans la base de données) ait un id
égal à l' id
du modèle lui-même.
final Model landingPage = Model( name: 'Landing page', /// ? id in format [toSnakeCase(name)] will be set automatically, if omitted // id: 'landing_page', isCollection: false, icon: IconPackNames.flu_document_page_break_regular, fields: [ ...
Nanc peut être configuré de plusieurs façons : par code, via l'interface Nanc elle-même, et une combinaison de ces options.
Quand je dis "configuration", je veux dire tout d'abord décrire la structure de vos modèles. Prenons un exemple simple, le modèle Feature, qui est une entité décrivant les fonctionnalités d'un produit. Cette entité contient les champs suivants :
Et l'implémentation en tant que configuration code-first sera la suivante :
import 'package:fields/fields.dart'; import 'package:icons/icons.dart'; import 'package:model/model.dart'; final Model feature = Model( name: 'Feature', icon: IconPackNames.flu_ribbon_star_filled, fields: [ [ IdField(width: 200), StringField(name: 'Title', maxLines: 1, isRequired: true, width: 400), ], [ IconField(name: 'Image', isRequired: true), ], [ StringField(name: 'Description', isRequired: true, showInList: true), ], ], );
En décrivant un tel modèle et en l'utilisant dans Nanc CMS, toutes les opérations CRUD de ce modèle deviennent disponibles.
Nous pourrions créer exactement le même modèle de fonctionnalité (appelons-le une variante de fonctionnalité) via l'interface Nanc. Et (considérant que tout le travail préparatoire à l'utilisation de Nanc est fait) - lorsque vous créez un modèle dans Nanc, vous créez immédiatement une table dans la base de données, et l'ensemble du CRUD sera également à votre disposition immédiatement.
En outre, vous pouvez choisir le moyen le plus sûr de ne rien créer dans la base de données lorsque vous créez un modèle via l'interface Nanc. Et créez indépendamment une table dans votre base de données, puis, sous celle-ci, créez un modèle dans Nanc. Au fait, c'est ce que vous devez faire si vous décrivez la configuration en code - les nouvelles tables n'apparaîtront pas dans votre base de données à partir de là.
Cette option devient disponible lorsque vous avez une configuration Code-first et que vous décidez de la modifier via l'interface Nanc. Dans ce cas, toutes les modifications ultérieures apportées à ce modèle ne seront possibles que via l'interface, et les modifications apportées au modèle de code d'origine seront ignorées. La seule façon de revenir à Code-first est de "réinitialiser" le modèle, auquel cas toutes les modifications apportées à la structure du modèle via l'interface seront effacées et la configuration Code-first sera à nouveau utilisée. Aucune donnée n'est affectée par cette réinitialisation. Cela n'affecte que la structure du modèle.
Voyons maintenant quels types de champs sont actuellement pris en charge par Nanc.
BoolField vous permet de contrôler le type de données bool
et de personnaliser la valeur par défaut.
ColorField vous fournit un sélecteur de couleurs pratique qui vous permet de choisir une couleur immédiatement dans Nanc. Il vous donne également la possibilité d'apporter des modifications manuellement, en modifiant le code AHEX. AHEX est une couleur HEX classique (par exemple, #10A0CF
), mais avec une valeur de transparence supplémentaire spécifiée en premier. Dans ce cas, cette couleur serait similaire à la couleur #FF10A0CF
( FF
est 100% d'opacité - la couleur est complètement opaque). Et voici à quoi ressemblerait la même couleur avec une opacité de 50 % : #7F10A0CF
.
DateField est responsable du contrôle de la date et de l'heure (les deux valeurs à la fois, des valeurs distinctes pour la date et l'heure seront implémentées ultérieurement). DateField contient deux paramètres booléens qui permettent de modifier le comportement de ce champ en en faisant un horodatage de création d'entité et un horodatage de changement.
DynamicField, d'une part, est un champ très simple, mais d'autre part, il inclut toute la complexité des autres champs. Au départ, vous ne pouvez configurer que l'apparence de ce champ (à quoi il ressemblera dans l'interface Nanc - la couleur et l'icône qui l'accompagne). Après cela, ce champ peut contenir toutes les valeurs disponibles dans Nanc, y compris lui-même. Qu'est-ce que cela signifie? Essentiellement, DynamicField est un JSON typé avec la capacité de positionner les champs dans l'ordre en lui-même.
EnumField est un champ permettant de sélectionner une valeur parmi plusieurs valeurs. La règle à suivre lors de la sélection d'un EnumField est que si vous avez une liste finale de valeurs à sélectionner qui n'est pas stockée dans une table de base de données distincte, choisissez Enum. Sinon, choisissez SelectorField, qui est décrit plus en détail ci-dessous. TODO : pour le moment, ce champ ne peut être configuré que via CodeConfig, la configuration via l'interface n'est pas élaborée.
HeaderField n'est pas vraiment un champ, mais un rehausseur visuel pour votre modèle dans Nanc. Vous pouvez utiliser ce non- champ pour définir un en-tête commun pour un groupe de champs associés ou pour distinguer les champs de modèle les uns des autres en utilisant HeaderField comme délimiteur.
IconField vous donne la possibilité de sélectionner une icône (classe IconData
) à partir d'un ensemble prédéfini d'icônes. Il y en a actuellement environ 25 000, et cet ensemble comprend les icônes suivantes :
Si nécessaire, d'autres icônes peuvent être ajoutées à l'ensemble de livraison de base, et dans un avenir pas trop lointain, il y aura également une option pour utiliser vos propres icônes.
On pourrait se demander : « Les icônes sont là, les couleurs sont là, mais les polices ? Si vous l'avez fait, vous pouvez trouver la réponse dans la documentation du widget Texte . La réponse courte est que toutes les polices de Google Fonts sont à votre disposition.
IdField est un champ si simple mais si important. Chaque modèle géré par Nanc doit avoir au moins un champ de type Id. Actuellement, seul le type d'ID de chaîne est pris en charge (il peut s'agir de n'importe quelle chaîne unique au sein d'une entité). Il est également prévu d'ajouter la prise en charge du type numérique, qui, cependant, peut être implémenté dès maintenant simplement en transformant les données de champ en type numérique dans l'implémentation de l'API.
MultiSelectorField est un champ assez complexe qui est responsable de la mise en œuvre d'une relation relationnelle plusieurs-à-plusieurs ou plusieurs-à-un. Il existe trois modes d'utilisation de ce champ. Passons en revue chacun d'eux plus en détail. TODO : pour le moment, ce champ ne peut être configuré que via CodeConfig, la configuration via l'interface n'est pas élaborée.
Ce mode vous donne la possibilité de stocker directement l' id
des entités associées dans l'entité parent. Par exemple - nous avons deux modèles - Reader et Book. Dans ce mode, les livres pris par le lecteur seront comptabilisés comme des identifiants stockés dans le champ Modèle de lecteur. Par exemple comme ceci :
/// user table { id: 'UUID', name: 'String', books: [ 'UUID', 'UUID' // ... ] }
Ci-dessus, un exemple de structure de table exprimée à l'aide de la syntaxe JSON5.
L'inconvénient de ce mode est l'intégrité limitée des données. Si vous n'implémentez pas la suppression automatique des ID de livre obsolètes (supprimés) du champ Lecteur books
, vous obtiendrez des erreurs.
Le mode classique de fourniture de relations du monde SQL. Lorsque vous utilisez ce mode, vous stockez les relations d'entité dans une table séparée et garantissez l'intégrité des données à 100 %. La structure suivante est un exemple de ce mode :
[ /// user table { id: 'UUID', name: 'String' }, /// book table { id: 'UUID', title: 'String' }, /// user_books_relations table { user_id: 'UUID', book_id: 'UUID' } ]
À la 7ème seconde, vous pouvez voir une légère secousse et si vous regardez attentivement, vous pouvez remarquer que l'url de la page a changé - c'est ainsi que j'ai essayé de masquer le bogue : en mode troisième table, les données sont enregistrées dans la page parent uniquement si elle a déjà été enregistré 🤷🏼
Généralement similaire à Array of ids, sauf que l'enregistrement parent ne stocke pas les identifiants, mais l'objet entier (sous forme de structure plate, sans entités associées possibles de l'enregistrement imbriqué). Il présente le même inconvénient que Array of ids, mais en a un supplémentaire - une utilisation accrue du stockage. Cependant il existe (du moins pour le moment) un domaine d'application de ce mode, et il est très important. Mais nous en reparlerons un peu plus tard.
Je m'avance dans la vidéo, montrant ScreenField, on y reviendra
En général, il y a une idée de rendre virtuels les modes "non canoniques" - afin qu'ils fonctionnent d'une manière ou d'une autre via la troisième table, et les données nécessaires sont chargées lors de l'édition de la page (si nécessaire).
NumberField stocke les nombres - aussi simple que cela.
SelectorField est similaire à MultiSelectorField (comme vous pouvez le deviner d'après leurs noms), mais un peu plus simple - la relation ici est un-à-un ou un-à-plusieurs, et il existe deux modes. TODO : pour le moment, ce champ ne peut être configuré que via CodeConfig, la configuration via l'interface n'est pas élaborée.
Une forme courante de fourniture de lien SQL, où le champ d'enregistrement parent stocke l'ID de l'enregistrement lié. Prenons le Reader comme exemple. Qu'est-ce? Tout d'abord c'est une personne, et qu'est-ce qu'une personne a ? C'est exact! La ville de naissance (que notre bibliothèque, pour une raison quelconque, voulait également connaître).
/// user table { id: 'UUID', name: 'String', birth_place_id: 'UUID' }
Très similaire au tableau d'objets de MultiSelectorField, mais nous stockerons une seule valeur associée dans le champ de l'enregistrement parent. Les inconvénients sont les mêmes, les avantages seront également décrits un peu ci-dessous.
StringField stocke des chaînes. Ce champ a un paramètre personnel responsable de la commodité de l'édition dans Nanc - le paramètre limitant la hauteur maximale du champ modifiable. Si votre texte sera grand - il est logique de ne pas le spécifier du tout, alors le champ s'ajustera à la hauteur du texte. Si limité à large - vous pouvez spécifier une hauteur de champ explicite (en lignes) et il en sera toujours ainsi. Et enfin, pour les chaînes courtes, vous pouvez le définir sur une ligne, puis le champ ne s'agrandira pas, peu importe combien vous y écrivez par la suite.
StructureField vous permet de stocker un tableau de structures typées dans les enregistrements de modèle. Vous spécifiez le type de données à stocker et pouvez le gérer facilement et simplement. Les types disponibles pour les champs de structure sont absolument tout. Ainsi, vous pouvez facilement créer une "répétition de champ de structure dynamique". TODO : Seuls les champs "plats" peuvent être ajoutés à StructureField dans la démo.
ScreenField est un champ qui permet d'écrire toute une application en Flutter, directement dans Nanc ! Avec ScreenField, vous pouvez décrire l'interface d'un seul écran, le mettre à jour comme vous le souhaitez et le faire à tout moment en quelques minutes - sans l'attente fastidieuse et angoissante des avis d'Apple et de Google.
Décomposons ce type de champ (et en fait toute une ramification fonctionnelle distincte de Nanc) un peu plus en détail.
Avec ScreenField, vous pouvez vraiment créer une interface de presque n'importe quelle complexité directement dans votre navigateur (et votre IDE), puis - sans faire de publication de stock - mettre à jour l'écran correspondant dans votre application. Si vous avez besoin de vérifier rapidement des hypothèses, c'est une excellente fonctionnalité. Cette fonctionnalité est idéale pour les pages relativement simples (en termes de logique) de votre application, qui doivent cependant changer assez souvent. À l'avenir, cette fonctionnalité sera étendue à un état où vous pourrez vraiment créer tout ce que vous voulez sans aucune restriction.
Voyons maintenant tous les aspects de la création d'écrans dynamiques avec Nanc.
Il y a beaucoup de widgets dans Flutter. Beaucoup d'entre eux. Qu'est-ce qu'un widget ? C'est une brique de fonctionnalité à partir de laquelle vous assemblez votre application. Cela peut être uniquement visuel ou logique - avec un certain comportement à l'intérieur. Nanc fournit une liste complète de widgets implémentés que vous pouvez utiliser pour créer votre interface utilisateur. Mais plus il y a de possibilités, plus il est difficile de les connaître... Ainsi, l'éditeur d'écran de Nanc vous donne accès à une documentation interactive où vous pouvez découvrir quels widgets sont actuellement implémentés, quels paramètres et propriétés configurables ils ont, et, directement dans la documentation, voyez comment ils affectent l'apparence de l'interface que vous créez.
Nanc permet de créer une interface en temps réel, mais surtout - il permet de le faire très facilement et rapidement (il a fallu un peu plus de 2 heures pour interfacer une application de démonstration). Mais la question se pose - comment créer l'interface utilisateur elle-même ? Il n'y a pas de syntaxe exotique pour décrire l'UI dans Nanc, ni de solutions "trop" simples, comme du long JSON, qui vous feront détester créer des interfaces dans Nanc.
Le résultat de la recherche de la meilleure solution est une syntaxe XML simple et directe. Tous les widgets Flutter standard ont exactement les mêmes noms, mais sous forme XML. Par exemple, le widget SizedBox
dans Nanc serait <sizedBox>...</sizedBox>
, et cette règle s'applique à tous les widgets sans exception. Si le widget a une propriété complexe, il aura le même nom (ou plus simple) que XML, avec le préfixe prop
. Par exemple - le widget Container
a une propriété complexe boxDecoration
, qui a ses propres propriétés internes. Ainsi, ce bien à Nanc aura le look suivant : <prop:decoration>...</prop:decoration>
. Cette règle s'applique à toutes les propriétés complexes. Et le dernier aspect est que les arguments qui sont relativement simples sont des paramètres de balise XML. Prenons le même SizedBox
comme exemple :
<sizedBox width="50" height="50"> ... </sizedBox>
Pour certains widgets, des arguments supplémentaires sont implémentés pour simplifier l'écriture du code, et pour SizedBox
c'est l'argument ize
qui définit à la fois width
et height
.
Tout ce qui est écrit ici se trouve dans la documentation en ligne, donc si vous oubliez quelque chose ou si vous voulez savoir quelque chose, référez-vous-y et trouvez-y des réponses à toutes vos questions.
Implémenter la prise en charge du nouveau widget - une question de 10 minutes à quelques heures. À ce stade, presque tous les widgets de base sont implémentés, dont vous pouvez créer une interface complexe avec logique. Avec le temps, tous les widgets disponibles dans Flutter seront implémentés dans Nanc, et vous pourrez vraiment tout faire. Mais ce n'est pas tout. Vous pouvez facilement et simplement implémenter vos propres widgets et les utiliser dans Nanc avec une ou deux lignes de code XML. Par exemple - il n'y a pas de widget dans la bibliothèque Flutter standard qui vous permet d'afficher facilement le curseur du carrousel avec des images. Vous devrez écrire vous-même une implémentation ou utiliser une solution open source comme celle-ci . Et, après avoir implémenté ce dont vous avez besoin, vous pouvez très facilement intégrer votre widget dans Nanc et l'utiliser.
Nanc offre plus que la simple possibilité de convertir du code XML en une interface dans Flutter. Nanc fournit des capacités de création de modèles et d'écriture logique. Rendu d'élément conditionnel, dessin de boucle, gestion du tap - c'est déjà dans la version 0.0.1
actuelle de Nanc.
Jusqu'à présent, la partie logique est assez simple - elle prend en charge l'interaction via les taps et la gestion des événements dans votre code `.dart' écrit à l'avance - mais finalement cette partie de Nanc s'étendra considérablement, vous permettant d'écrire la logique dans Dart directement dans le navigateur et faites-le fonctionner également dans votre application.
L'approche de gestion des clics des utilisateurs est la suivante : vous pouvez définir une liste d'"actions" que l'utilisateur peut effectuer dans votre application. Par exemple - ouvrez l'écran de l'application interne, cliquez sur le lien externe, affichez SnackBar, ouvrez une fenêtre modale et bien d'autres choses, et créez à l'avance un gestionnaire pour de telles actions. Et puis utilisez cette action comme bon vous semble dans Nanc. Pour plus d'informations sur la gestion des événements, consultez la documentation du widget InkWell
dans Nanc.
Nanc a un éditeur XML intégré, mais ce n'est pas très pratique. Il n'est pas (encore) consultable, il n'est pas très rapide avec beaucoup de code et il n'a pas d'auto-complétion. Comment vivre avec ? Par exemple - laissez l'utilisateur utiliser son IDE préféré et regardez les changements dans Nanc en temps réel. Laisse moi te montrer comment.
Et voici le Web (avec lequel vous devez jouer):
À l'avenir, la prise en charge de la saisie semi-automatique sera ajoutée, peut-être dans un avenir lointain... J'ai essayé d'approfondir XML Schema, j'ai passé plusieurs jours, mais jusqu'à présent, je n'ai pas pu 🤷🏼
Par ailleurs, je voudrais mentionner les performances (interface de dessin à partir de XML sur les appareils mobiles). En bref, il est identique aux performances de Flutter lui-même, sans aucune surcharge. Pour le moment, "l'écran" est une liste de widgets rendue paresseusement (SliverList), créée de manière asynchrone. Plus tard, cette implémentation sera affinée pour commencer à rendre les widgets de manière asynchrone, mais à son tour, le temps nécessaire pour afficher le contenu sera donc égal au temps nécessaire pour rendre le tout premier widget décrit dans le XML.
Pour démontrer les capacités, un ensemble public d'applications de démonstration a été créé pour montrer ce qui peut être réalisé avec Nanc dès maintenant. Il s'agit d'une application cliente sur Android et sur le Web (ce dernier joue aussi provisoirement le rôle d'une application iOS). Ainsi que l'application Nanc CMS. En savoir plus à leur sujet ci-dessous.
Client est une application de démonstration client qui utilise une seule bibliothèque de l'écosystème nanc. Cette bibliothèque vous permet de convertir XML en une interface d'application dans Flutter. Cette application n'a qu'un seul écran, entièrement créé dans Nanc, et elle peut être mise à jour à volonté et à tout moment sans réserves. En bas à droite, il y a un bouton avec une icône de connexion - il est responsable de la connexion à demo-CMS . Plus d'informations sur ce que cette "connexion" sera ci-dessous.
Admin est une application de démonstration Nanc-CMS, avec une couche de logique supplémentaire implémentée, qui offre la possibilité de se synchroniser avec les clients (plus d'informations sur la connexion ci-dessous). Dans l'application de démonstration Nanc-CMS, le navigateur de l'utilisateur lui-même et son localStorage agissent comme le "backend". Tout ce que vous ajoutez ou modifiez est stocké uniquement dans votre navigateur. Dans Nanc-CMS, vous pouvez modifier / créer / supprimer des données liées aux modèles existants (vous les verrez), et - vous pouvez créer vos propres modèles via l'interface et faire de même avec eux.
En tant que représentation SQL des modèles de données utilisés dans la création de cette démo, vous pouvez être guidé par la capture d'écran suivante :
Cette section concerne uniquement la logique de la "démo" dans les applications client et CMS. Et il a été mis en œuvre pour simuler l'expérience d'interaction avec Nanc et le processus de mise à jour du client. Mais avant tout.
Dans un projet de production réel, vous pouvez utiliser Nanc de la manière suivante : déployer une application Nanc CMS statique quelque part, avec des services API implémentés. Il communiquerait avec votre backend et vous utiliseriez Nanc à votre guise. Votre application contient une bibliothèque de l'écosystème nanc qui vous permet de rendre l'interface. Vous avez fait une mise à jour - l'application a chargé un nouveau code à partir de votre backend, mis à jour - tout le monde est content et satisfait.
Pour montrer ce modèle en action, la même chose est mise en œuvre, mais de manière simplifiée :
Nanc CMS existe en tant que statique, allongé sur les pages github et vous pouvez l'utiliser comme "dans la vraie vie", mais votre navigateur agit comme le backend. C'est-à-dire que les API ont été implémentées de manière à "aller sur le réseau" - dans le navigateur localStorage. Avec cette partie, nous avons terminé, mais il reste une application mobile, qui doit en quelque sorte vous montrer le processus de "mise à jour".
Eh bien, c'est là qu'intervient la "connexion". En bref, vous pouvez établir une connexion directe entre n'importe quelle application de démonstration client Nanc et n'importe quelle application de démonstration Nanc CMS. Pour ce faire, vous devez cliquer sur le bouton en bas à droite avec l'icône du code QR dans le CMS. Dans la fenêtre modale qui apparaît, vous verrez le code QR. Ensuite, vous avez deux chaises - vous pouvez scanner ce code avec l'application client mobile (ou navigateur) en appuyant sur le bouton similaire en bas à droite, puis la connexion sera établie automatiquement. Ou vous pouvez cliquer sur le code QR et les données nécessaires à la connexion seront copiées dans le presse-papiers. Ensuite, vous devrez coller ces données dans le champ de saisie de l'application mobile et vous connecter en appuyant sur le bouton. Lorsque la connexion est établie, vous vous comprendrez. Après cela, vous pouvez faire ce que vous voulez avec la Landing Page existante et voir les changements en temps réel (après enregistrement) - dans l'application mobile.
Mais vous n'êtes pas limité à la Landing Page . Vous pouvez créer de nouveaux modèles directement dans le navigateur, les remplir de contenu et si vos modèles auront un champ pour la description de l'interface (type Écran) - alors lorsque vous enregistrez ces entités, vous verrez également le résultat dans l'application - le l'écran du nouveau modèle remplacera l'écran de l'application existante. Le seul point est que puisque l'application cliente ne sait pas quel type de champ est votre enregistrement nouvellement créé, elle a des identificateurs possibles prescrits, qui devraient être des ScreenFields.
Donc, si vous souhaitez créer un écran entièrement à partir de rien et l'afficher dans l'application, utilisez un élément de la liste suivante comme valeur IdField :
Si vous cassez quelque chose - réinitialisez simplement les données admin.nanc.io (Chrome : F12 -> Application -> Application -> Stockage -> Effacer les données du site), eh bien, lorsque vous rouvrez l'application cliente, elle chargera toujours le code d'écran réel créé pour cette démo. (Le code de votre navigateur ne sera chargé que si vous vous connectez)
Et enfin, un petit exemple de création d'une nouvelle page d'un nouveau modèle contenant un ScreenField et de son rendu dans l'application :
La démo publique est prête. L'article d'introduction est écrit. Plans futurs pour Nanc - pour compléter l'intégrité fonctionnelle de l'approche de l'interface de création de modèle, permettant de configurer tous les champs - Enum, Selector et MultiSelector. Correction de bogues connus, comme la modification de la position des éléments dans StructureField. Puis "bla bla bla", puis "tel et tel". Le carnet de commandes sera suffisant pour le prochain semestre au moins, mais le modèle supplémentaire d'expansion des fonctionnalités sera basé sur les besoins des clients, donc si vous avez des idées/critiques/bogues trouvés (et il y en a beaucoup) /autre chose - veuillez remplir le formulaire dont le lien est disponible dans l'application de démonstration client.
Si vous êtes intéressé par les fonctionnalités de Nanc et que vous êtes intéressé par la coopération, remplissez également le formulaire et nous en parlerons certainement.