WebFront C++23Tome II / CHAPITRE 01
Pour comprendre et contribuer
Pour aller plus loin
Nous avons appris à utiliser WebFront. Regardons maintenant ce qui se passe de l’autre côté de ses fonctions.
Conventions de notation
Les noms de fonctions, types, commandes, options et fichiers sont composés en chasse fixe, par exemple describe, wf test ou main.cpp. L’italique introduit un terme lors de sa définition. Les blocs de code donnent les extraits à saisir ; le texte qui les précède précise leur emplacement et leurs prérequis.
- Application C++
- Cœur HTTP / WebSocket
- Pont et page du navigateur
Le frontend ouvre la page ; le fournisseur de ressources alimente HTTP. Les appels du pont circulent dans les deux sens.
Passer de l’exemple à l’implémentation
Lorsque nous écrivons app.show(), une page s’ouvre et notre programme peut recevoir des appels du navigateur. Cette ligne est commode précisément parce qu’elle nous laisse ignorer beaucoup de travail. Pour comprendre WebFront, nous allons reprendre ce travail, une opération à la fois.
Ce second tome s’adresse à vous si vous voulez savoir ce qui se passe derrière un appel, retrouver la cause d’un comportement inattendu ou modifier le framework. Nous nous servirons des exemples du premier tome comme de petits programmes à examiner.
Une certaine familiarité avec le C++ et les durées de vie sera utile. Les notions propres au navigateur seront introduites à mesure que nous en aurons besoin.
Ouvrons la page
Commençons par ouvrir l’application. Le navigateur demande une page, puis les scripts et les autres ressources dont elle a besoin. Le serveur C++ répond à ces demandes HTTP. Une connexion WebSocket permet ensuite à la page et au programme de continuer à échanger sans recharger le document à chaque appel.
Nous rencontrons déjà deux parties du système : le cœur C++ et le code qui s’exécute dans le navigateur. Pendant le développement, une troisième partie fournit le terminal, le compilateur TypeScript et les outils de test. Cet environnement est chargé à la demande ; une application distribuée peut s’en passer.
Pour retrouver ces parties dans le dépôt, nous suivrons les ressources et les messages qu’elles s’échangent. Cela nous donnera une raison de visiter chaque fichier.
Trouver son chemin dans le code
Une première lecture de WebFront.hpp peut donner l’impression que tout arrive à la fois : templates, connexions, callbacks et tâches asynchrones. Il n’est pas nécessaire de tout comprendre avant de continuer. Choisissons plutôt une opération connue, par exemple le clic qui demande une génération du Jeu de la vie.
Nous pouvons suivre son message depuis JavaScript jusqu’à la fonction C++, puis revenir avec le résultat. À chaque étape, cherchons qui conserve les données et ce qui permet de passer à l’étape suivante. Si la fenêtre se ferme pendant l’attente, il faudra aussi comprendre ce qu’il advient de ces données.
Les chapitres suivent ce même fil : construire les objets, faire circuler un appel, puis terminer proprement ce qui est encore en cours.
Lire les documents avec l’implémentation
Il est plus agréable de suivre une explication lorsque les liens conduisent toujours au même code. Ceux de ce tome visent donc la révision 056d0c8, datée du 5 novembre 2026. Les exemples du premier tome restent fondés sur la version 0.7.0. La révision étudiée ici contient aussi du travail qui n’a pas encore fait l’objet d’une release.
Les guides décrivent les interfaces en détail. Les décisions d’architecture, ou ADR, racontent pourquoi une solution a été choisie et quelles autres possibilités ont été examinées. Nous y reviendrons lorsque ce choix aidera à comprendre le code.
Une ADR peut également décrire une proposition. Son statut compte donc autant que son texte : pour savoir ce que fait la révision étudiée, nous confronterons le document à l’implémentation et aux tests.
Vérifier sa compréhension