Les layouts sont le squelette d'une application web. L'approche de FLIN utilise un placeholder {children} dans les fichiers de layout. Le contenu de la page remplit l'espace au milieu. Simple en concept. Mais l'implémentation a révélé une cascade de bugs dans le rendu, la surveillance de fichiers, la sélection de layout et la gestion d'URL qui a pris la Session 250 entière à résoudre.
La cause racine était architecturale : le pipeline de rendu n'avait aucun concept d'enveloppement par layout. La correction a nécessité des changements dans quatre couches du système : le registre de layouts, le moteur de rendu, l'API de la bibliothèque et le serveur HTTP.
Nous avons aussi implémenté le support multi-layouts avec une syntaxe de déclaration (layout = "auth"), corrigé le rechargement à chaud pour les fichiers de layout, et géré un bug d'URL où :// était mal interprété par le lexer.
La leçon clé : les fonctionnalités qui sont « un seul concept pour le développeur » touchent souvent chaque couche du système. L'enveloppement de layout a nécessité des changements dans le lexer, le moteur de rendu, l'API de la bibliothèque, le serveur HTTP et le surveillant de fichiers. Une fonctionnalité qui est un concept pour le développeur est cinq changements pour le framework.
Ceci est la partie 163 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.
Navigation de la série : - [162] La correction de persistance qui a pris 3 sessions - [163] Le bug d'enveloppement des enfants dans les layouts (vous êtes ici) - [164] Correction de la résolution des fonctions de bibliothèque