search

remotestorage / remotestorage.js

⬡ JavaScript client library for integrating remoteStorage in apps
https://remotestoragejs.readthedocs.io
MIT License
2.32k stars 141 forks source link

Create `local.type` and `remote.type` to easily check which storage methods are being used. #799

Open silverbucket opened 10 years ago

silverbucket commented 10 years ago

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'

raucao commented 8 years ago

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. ;)

silverbucket commented 8 years ago

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.

raucao commented 8 years ago

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.

silverbucket commented 8 years ago

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. :)

silverbucket commented 8 years ago

Also, easier for reporting and debugging via. github with potential adopters.

raucao commented 8 years ago

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.

silverbucket commented 8 years ago

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.

raucao commented 8 years ago

It's fine, we can just leave it. Keeps it in the backlog on the waffle board. Thanks for clarifying.