remotestorage.js
remotestorage.js copied to clipboard
remotestorage
Create `local.type` and `remote.type` to easily check which storage methods are being used.
As per conversation here: https://github.com/remotestorage/remotestorage.js/issues/789
It would be nice to let developers browse the remoteStorage object and get information about the local and remote storage targets being used.
e.g.:
remoteStorage.local.type: 'IndexedDB'
remoteStorage.remote.type: 'Remote Storage'
The second one is available as remoteStorage.backend. I couldn't find the caching backend being available as a string like that, though.
What would be the use case for an app developer? For developers it's just one devtools click on the Storage panel away. Would you want to know it from within your app code? I personally have never needed it, and in fact not having to know about storage tech is one of my favorite features of rs.js when I develop my apps. ;)
It could be helpful to developers getting familiar with the library, for one, but also there could be some apps that want to report that info in a settings page somewhere. I agree not having to know is a great feature of rs.js, but not being able to find out in the object seems like an unnecessary omission.
But that's my question: isn't it much easier to find out by just opening devtools than using some key on an object? And then you can immediately check out what it's storing and how as well.
It's just a benefit to having a clear and uncomplicated rs object, in both layout and intention. I do see the use in seeing those properties on the object itself, rather than what it's doing to the browser - I see both how it logically separates out different pieces and how they might work together. This is especially useful when debugging code changes... and regardless if someone might want to put it in their app (I think it's possible, you don't) I think it's a free feature for a well thought out rs object. Now, whether we want to add that to the existing code (which is not exactly well thought out) is a separate question. :)
Also, easier for reporting and debugging via. github with potential adopters.
Going forward, it's basically 99% IndexedDB, which is why I don't see it as important. I'm not opposed to it, just not understanding the benefit or why anyone would use it in their app. Doesn't mean it shouldn't be there, of course.
Well why don't we leave it for now and consider it if we get around to rewriting/refactoring some or all of the code? If it's a free feature we can just add it then, but no point in anyone looking into it now. Not sure what label this should have in that case.
It's fine, we can just leave it. Keeps it in the backlog on the waffle board. Thanks for clarifying.