-
Notifications
You must be signed in to change notification settings - Fork 72
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
Support webSQL/IndexDB for client-side persistence + Documentation #5
Comments
Sounds like a good idea! The persistence will be documented, apologies for the hole in the doc on that, I've spent a good chunk of time documenting the operators etc. Just an FYI, you can persist any collection like this:
Then when your app loads you can do this:
I am in the process of creating a todo app tutorial which has persistence. It's not linked to yet but you can see an early version of the page (unfinished) here: http://forerunnerdb.com/tutorial/todoList.html If you skip to step 7 you should see how it sets up the load() and save() calls. I'll be putting some more effort into docs this week and will investigate the storage options you mentioned as well. :) |
Use of localforage for persistence is now on the roadmap for version 1.3.0 (see dev branch for updated roadmap). |
Thanks for the quick response! I'm looking at the code and I notice that you already have support for callbacks for the save and load methods. I want to start using forerunnerDB right now. I hope you're open to pull requests. I'll try to add the documentation for the persistence as well. I'm assuming the pull request should go into the dev branch for now. And I'll try to follow the style of the other code in the repo. Eventually, it would be nice to have some contribution guidelines. |
Yes it should be pretty easy to plug in localforage, I had a quick look when assessing the difficulty from your last message and it looked like about 2 hours max including creating unit tests :)
Always, community engagement is a very good thing.
We are using ForerunnerDB in production on a site that has 6 million active users to handle data. It is a very data-intensive application and also includes realtime data updates coming from Node.js through Faye, into Forerunner and then the DOM is updated automatically.
Thanks, any help in the doc department (or any other) is most welcome!
I think if it's doc-related and relevant to the current master branch version then it can pull-request against master. If it changes code then yes, I think dev is the way forward. Just so you know, when updates are made, unit tests to give coverage to those updates need to be run and pass before the feature can make it to the master branch.
Agreed. I'll add it to the roadmap :) thanks for your time and input, it is always welcome 👍 |
I should mention that the iOS version is still an alpha product and not production ready at all. The stuff in the server folder should be considered the same way. I think I will remove those from this project and create separate ones for those going forward as they are totally optional and just bloat the download right now. |
Since ForerunnerDB has the same query language as mongoDB, simple usage is very straightforward.
However, some of the the newer features — client-side persistence with local storage aren't documented at all. It is a very important feature for me, and I would like to know how it works. Do I need to manually set-up the database each time, or does it real from the local storage automatically.
Another important factor is that local storage is synchronous and can be a performance bottleneck. It would be much better if ForerunnerDB could persist to WebSQL and IndexedDB instead. Mozilla's great LocalForage project seems like a good option to make it work with minimal changes. But it would make .persist an asynchronous operation.
Ideally, LocalForage should be an optional dependency for async storage.
Thoughts?
The text was updated successfully, but these errors were encountered: