Quleques questions sur les VDOM :

- comment s'appelle le pattern d'imbrication des appels d'une fonction render/h ? est-ce de la récursion ?

- serait-il possible de stocker dans une structure d' object pool unique les différents appels à render/h ?

- faire les opérations de diff/patch vers le DOM à partir d'une seule instance de cette structure (in-place) et ce pour minimiser lmes cycles du garbage collector ?

Quelques tests que j'ai mené me font dire que c'est possible. Je n'ai pas encore trouvé comment implémenter la version mémoizée de render/h !

- Qu'en pensez vous ?

NOTES (TLDR)

La structure de blocs contiendrait des blocs de la forme:

- UID = clé sur 4 digits (64 valeurs) lisible par l'humain
- parentUID = '0000' // même format que l'UID
- nextUID, prevUID, firstChildUID, lastChildUID // encore des UIDs
- childRank = 0 // entier
- kind = TAG | TEXT | ATTR | CODE...
- name
- value

et un pool de la forme :

- list: [BLOCKS]
- lookup: mapping < UID => BLOCK >
- released: [ BLOCK ]

l'idée estr d'utiliser la map de lookup pour adresser un block en temps constant, et les listes pour les opérations groupées sur un type de block donné ;

list.filter(b => b.kind === 'TAG').map(b => {...})

Les UIDs seraient générés de façon pseudo aléatoire avec un Générateur Congruentiel Linéaire pour ne pas avoir à utiliser Math.random() et garantir la pureté des fonctions, indispensable pour les opéations de mémoization...

Les dernières idée sont qu'une forme sérialisée "applatie" de l'arbre VDOM :

- permettrait de le stocker facilement dans un registre clé/valeur tels que le localStorage (par exemple pour faire évoluer les versions d'une app hybride)
- serait plus lisible pour le débogage
- économiserait des cucles de GC
- pourrait faciliter les diff/patch ops, et même au prix de 4 octets par clé de bloc, gagnerait de la place au long terme quand on fait des "time-travel" de l'application