#fuck_jews's avatar
#fuck_jews 3 months ago
soo the problem of sorted arrays can be solved in two ways -old way: sort it in js -new way (2 grams of hash later): directly put in idb with a key like `${timestamp}:${id}` and let the underlaying idb b-tree sort it for you i just finished the idb visualizer right before Eid then an old friend handed me 2 grams of hash as Eid gift it made me rethink everything, ngl i wouldn't 've arrived to that conclusion if i didn't build it first when you build around the second approach things will be much simpler cause now there is only one source of data, the glorious idb
#fuck_jews's avatar #fuck_jews
the idea is instead of const arr = []; arr.push(item) window.Indexeddb.open(....) // save to idb manually // later, retrieve from idb manually on next session we should be able to do const fancyArr = createFancyArr({ ownerId: 'arr-123' }) fancyArr.push(item) // or insert(item) for sorted fancyArr.length // normal in-memory array length fancyArr.length_total // length of all items under 'arr-123' and now any 'arr-123' items from previous session will load to fancyArr in batches (first batch loads immediately) already implemented a simple proxy to trigger 'retrieve-next-batch' before reaching the end of loaded items There is still the tricky part where arr can be used normally like 'arr.map(item=> <ItemComponent {...item} />)' while only loading subsequent batches on that new array index access idk what to do there, maybe will intercept iterator methods and return another proxied array, maybe View quoted note →
View quoted note →