3 ms·
"since they’re not implementing the useful but dangerous part which is what people actually want." I want it like this. There are lots of use cases for a file
by hutzlibu 5y ago
"since they’re not implementing the useful but dangerous part which is what people actually want."
I want it like this. There are lots of use cases for a file system to store user data locally in a safe way.
Even though it all can be also done with indexedDB, too - it makes this task incredibly more complicated. I did basically this, implement a file system on top of indexedDB - but with great pain.
and I did, because there was no other option - but only with great unnecessary pain.
- chrismorgan 5y agoI haven’t tried, but I think a minimal polyfill of exactly this atop IndexedDB might take 300–400 hundred lines of code (and I’d be interested in the difference in performance characteristics, especially on large “files”, and with different types of edit strategies). A mildly simplified but close enough to feature-complete form of it could probably be done in under 200 lines, though I doubt 100 is attainable honestly (IndexedDB is comparatively verbose). It’s not that this is nothing, but I think it is and will be being fairly heavily oversold by some people.
- hutzlibu 5y agoWell, by now you can probably find some ready avaiable solutions, that would save you time. But having it native, would get you also native debugging tools, where you just could see the data in a common file explorer. What I have instead now, are tons of abstract dbs and object stores, when all I want to see are folders, pictures and text. Which is why I made a node server, which after sync, gets me actual files I can easily debug and store and edit. But this does not work locally anymore then and the structure is unnecessarily complicated.