Optimiser (memoizer ?) la mécanique du VDOM ?
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
Répondre avec citation
Partager