Choisir un modèle d’interface

Les possibilités de la version 0.6

La version 0.6.0 ajoute plusieurs moyens de construire la présentation d’une application C++. Un panneau simple peut être créé directement en C++. Un formulaire peut être déduit d’une description de ses champs. Une interface plus importante peut être écrite en TypeScript avec React.

Le choix dépend de la quantité de présentation à programmer et de l’endroit où l’on souhaite en conserver la description. Ces trois méthodes peuvent employer le même code métier.

Construire un panneau en C++

La page de secours embarquée contient une zone vide appelée root. Nous appellerons île une telle zone, dont la page prête le contenu au code C++.

L’appel à ui.document() donne accès au document de la connexion. L’extrait suivant, placé avant app.show(), crée un bouton et modifie son texte lors d’un clic. Les écritures sont regroupées avant leur envoi au navigateur.

Les opérations sur ce document doivent s’exécuter sur le contexte serveur : dans un callback, dans onUIStarted, ou dans une tâche WebFront. Un rechargement de la page crée un nouveau document.

app.onUIStarted([](auto ui) {
    auto doc = ui.document();
    auto root = doc.island();
    auto button = doc.element("button");
    auto label = doc.text("Click me");
    button.append(label);
    button.listen("click", [label](std::string) { label.setText("Clicked"); });
    root.append(button);
});

Décrire les champs d’un formulaire

Un descripteur rassemble le nom des champs, leurs libellés, leurs bornes et leurs fonctions d’accès. À partir de cette description, trois fonctions produisent des représentations différentes :

• forms::form() construit un formulaire modifiable.
• forms::inspector() construit une vue de lecture.
• forms::typescriptDeclaration() produit une déclaration TypeScript utilisable avec wf check.

L’exemple emploie les descripteurs disponibles en C++23. Une couche de réflexion C++26 existe séparément et est qualifiée avec GCC 16. La génération d’une déclaration ne modifie pas les types que le pont binaire sait transporter.

#include <webfront/components/forms/Form.hpp>
struct Settings { int speed{5}; bool wrap{true}; };
auto description = webfront::forms::Description<Settings>{
    .name = "Settings",
    .fields = {
        webfront::forms::field("speed", &Settings::speed, "Speed",
                              webfront::forms::Bounds{1, 10}),
        webfront::forms::field("wrap", &Settings::wrap, "Wrap")
    }
};
// Use the description with forms::form(), forms::inspector(),
// or forms::typescriptDeclaration().

Associer React et un panneau C++

Le paquet facultatif @webfront/react fournit createStore, useStore et Island. Le store transmet des instantanés de l’état C++, regroupés pour chaque navigateur. Le composant Island prête un sous-arbre vide au code C++.

La propriété de ce sous-arbre doit rester explicite. React ne doit pas modifier les nœuds que C++ y construit. Avant le démontage du composant, les deux parties doivent suivre le protocole de libération décrit dans le guide React.

Connexions et événements

La fonction app.broadcast(name, options)(...) envoie un appel aux navigateurs prêts. L’encodage est partagé. L’option maxPendingWrites permet de conserver seulement le dernier état en attente pour un navigateur trop lent ; elle convient, par exemple, à une vue de télémétrie qui n’a pas à recevoir tous les états intermédiaires. La fonction forEachUI visite les connexions prêtes.

Une valeur UI identifie l’application, la connexion et sa génération. Une ancienne valeur ne peut donc pas atteindre une connexion ultérieure qui réutiliserait le même identifiant. Elle ne doit jamais être utilisée après la destruction de l’application.

Pour écrire une suite de dialogues en C++, une tâche peut attendre un événement avec co_await node.next(...). La tâche reste possédée par WebFront.

Options CMake de la version 0.7

À partir de la version 0.7.0, les options de test et d’instrumentation portent obligatoirement le préfixe WEBFRONT_. Utilisez WEBFRONT_ENABLE_TESTING, WEBFRONT_ENABLE_FUZZING, WEBFRONT_ENABLE_COVERAGE et WEBFRONT_ENABLE_SANITIZER_*.

Les anciennes variables ENABLE_*, y compris celles présentes dans un cache existant, ne configurent plus WebFront. Lors d’une migration, indiquez explicitement les nouvelles options.

Les versions de la bibliothèque et de l’environnement de développement sont indépendantes : la bibliothèque 0.7.0 épingle l’environnement 0.6.3. Les API restent expérimentales.

# WebFront 0.7.0: use the prefixed options explicitly.
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release \
  -DWEBFRONT_EMBED_CEF=OFF -DWEBFRONT_ENABLE_TESTING=ON
cmake --build build --parallel 2
ctest --test-dir build --output-on-failure