[EDIT: question subtilement retocquée pour plus de lisibilité...]
Bonjour,
je travaille sur la réalisation d'une lib JS qui stocke des graphes (arbres VDOM et automates par exemple) de façon linéaire (tableaux + hash index) pour facilter leur sérialisation, transfert filtrage et requête.
J'ai abordé le sujet dans plusieurs posts sur développez.com et ailleurs en anglais.. Les lien développez sont présents en bas de ce post.
La question du jour porte sur l'organisation optimale des fichiers de l'application utilisant la lib.
Les données sont organisées dans un Block Memory Pool, qui peut être initialisé au moins une fois par l'utilisateur AVANT toute utilisation, avec u,e clé alphanumérique (graine pour le générateur de nombres pseudo aléatoires sous jacent)
Dans le cas d'un virtual DOM avec une fonction "h" de création d'éléments:
Les appels successifs à "h" vont toujours écrire sur la même structure de données (blocks-memory-pool), les opérations de diff/patch l'utiliseront également (on appelle cela virtuial DOM "in-place")
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 import { createBlocksMemoryPool} from '@src/core/blocks-memory/pool' const bmp = createBlocksMemoryPool({ seed: '8_DiG1t$' }) // ATTENTION closure javascript: // bmp ne doit surtout pas etre visible à l'exterier export const h = (name, attrsd, ...children) => { return createElement(bmp, name, attrs, children) }
On peut envisager d'utiliser du JSX.
La question porte sur l'application qui va utiliser la lib, supposons une structure de projet basique:
Un exemple de ficiher index.js avec deux composants serait :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14 + root-folder/ + dist/ + app.bundle.js + test.bundle.js + node_modules/ + src/ + index.js + seed.js + todo.item.js + todo.list.js + index.html + package.json + rollup.config.js
La difficulté vient de la mécanique des imports: ceux ci étant executés en premier, avant le fichier appelant (index.js) comment s'assurrer que la lib, donc la fonction "h" a bien été amorcée avant toute utilisation dans les fichiers de components ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 // src/index.js import { mount, compo, dom } from 'domulo' // la lib import { TodoListCompo } from '@src/todo-list' import { TodoItemCompo } from '@src/todo-item' // amorçage de la lib: // // idéalement à placer ici : // // const bmp = createBlocksMemoryPool({ seed: '900dCafe' }) const TodoAppCompo = (props) => compo( h('section', { /* attrs */}, TodoListCompo, TOdoItemCommpo ) ) mount(ToodCompo, doxument.getElementById('#container')
* soit par l'import, en top position de index.js, du fichier seeds.js
* soit par l'inclusion en tête de chaque composant, et du index.js, s'il y a un composant dedans également, de seeds.js
Le hic étant que seeds.js, qui est défini par l'utilisateur, ne doive re-exporter toutes les fonctions de la lib { h, compo, mount, init ...} dans autant d'exports, et que c'est de la responsabilité de l'utilisateur de lib lib, pour que cela fonctionne correectement !!!
TL;DR {BEGIN}
Deux très longs posts et échanges sur le sujet...
La structure de données est développée ici:
https://www.developpez.net/forums/d1...bjets-memoire/
La structure de données est prête également : Object Memory Pool recyclables pour eviter les cycles intempestifs du Garbage Collector --> OK
Les clés nécessaires à la gestion de s blocs sont discutées ici :
https://www.developpez.net/forums/d1...aleatoire-mwc/
J'ai arrêteé les choix sur le générateur : clés sur 4 digitis de 64 valeurs pris sur le domaine A-Za-z + "$" + _"" + 0-9 avec générateur MWC --> OK ca marche
TL;DR {END}
merci de vos remarquers et suggestions.
A + F - E
Partager