I don't think so. Your API seems to be synchronous, where all modern IndexedDB/WebSQL/etc APIs use promises. The reason they do this is that in modern browsers storage often runs on a separate thread and/or use sqlite and you don't really want to stop-your-js-world when the rendez-vouz and sqlite processing can take 100s of milliseconds on mobile devices.
This really is one (of many!) of the ugly parts of modern JS development. Newly designed APIs will probably gravitate towards using Promises (because these also support sync backends - the other way around: not so much).
But, hell, it feels stupid having to allocate a closure to memory (and decorate your code with indentation and an additional function if you don't transpile using await) every time you just want to get your session token from storage.
Duh, of course! Sorry, 3am and not too sharp in the nut at the time :)
I'm genuinely interested in supporting every needed use case. Off the top of my head, I could see e.g get returning a promise in some cases, or passing an optional callback to get, or having a get.async... Either way - I'll have it in the back of my head and see what can be done.
If you open an issue on GitHub we can continue there. Cheers!
This really is one (of many!) of the ugly parts of modern JS development. Newly designed APIs will probably gravitate towards using Promises (because these also support sync backends - the other way around: not so much).
But, hell, it feels stupid having to allocate a closure to memory (and decorate your code with indentation and an additional function if you don't transpile using await) every time you just want to get your session token from storage.