Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add localestorage support #22

Open
3 tasks
Belphemur opened this issue Aug 28, 2016 · 5 comments
Open
3 tasks

Add localestorage support #22

Belphemur opened this issue Aug 28, 2016 · 5 comments

Comments

@Belphemur
Copy link
Owner

To be able to use it in browser easily and rely on the storage mechanism there.

  • Create a storage "interface"
  • Implement driver for hard storage (current one)
  • Implement storage for LocalStorage
@ZaneHannanAU
Copy link

Currently not possible without a rework (requires('') compatibility required for current implementation).

I'm working on it though, as one with Promises.

Not published, but see https://github.com/ZaneHannanAU/db-dot-json for more information.

@Belphemur
Copy link
Owner Author

@ZaneHannanAU Great work on implementing the Promises :)

I admit I gave up on Async as it was overkill for the usage I had of the lib at the time (hence the decision to use Sync filesystem calls).

@ZaneHannanAU
Copy link

ZaneHannanAU commented May 16, 2017

@Belphemur The biggest issue with mine right now is that it doesn't work at all.

As in, not even the tests work lol


Anyway, once you go promise for one thing; everything else must become a promise.

@Belphemur
Copy link
Owner Author

@ZaneHannanAU Yep, Promises are a double edge sword. One that I didn't wanted to impose on the user.

Also at the time I started the lib, there were easily 5-6 differents promise lib...

@Drarig29
Copy link
Contributor

Drarig29 commented Jul 22, 2020

@Belphemur I think an easier solution would be to:

  • Make the file persistance optional (for example by allowing null as a database filename in the JsonDB constructor)
  • Add a public method exposing the private field named data (maybe a copy for security concerns)
  • Let the user make his own solution (either outside of the library, or by passing a save callback function) to persist data manually
  • Persisting in json files would remain the default behavior

I can do it in a PR... I need this feature 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants