localforage / localforage Goto Github PK

There should be an error bubbled up to the developer when the quota of whatever driver they're using is reached.

I myself like to use Bower to install and manage client side dependencies. Basically, it means creating a bower.json file in the root and registering the git repo to bower registry. Also, it is encouraged to use semver tags in the git repo.

Full instructions here: http://bower.io/#defining-a-package

Is this something you'd consider useful? Is somebody already working on this? Should I?

sessionStorage has some beneficial features for which there is no real IndexedDB equivalent (I happen to use it in TogetherJS). It would be nice if you could specifically get a sessionStorage-backed database.

I noticed that localForage.getItem only returns a value if it is successful but never if there is an error. Generally I would expect the following behaviour:

localForage.getItem(itemKey, function (err, value) {
  if (err) {
    console.error('error: ', err);
  } else {
    console.log('value: ', value);
  }
});

Although localStorage doesn't return callbacks, it seems like the indexedDB part should at least return something if it were to go wrong so that users can handle the result accordingly.

The callback on main.js get's executed, before the default db (asyncstorage) get's extended on to localforage, causing error of undefined function setItem on object lf on mainjs.

lf.setItem(key, value, function() {

I made it work by adding a hack to return back a promise object on to main.js, which get's resolved after the default db get's extended, allowing me access to the extended localforage obj.

in localforage.js ->

//line number : 1480
var localForagePromise = new Promise(function(resolve, reject) {
      localForage.setDriver(storageLibrary).then(function(lf) {
        resolve(lf);
      });
 });

and then in main.js ->

define(function() {
  require(['../dist/localforage'], function(promise) {
    promise.then(getLocalForage);
  });
});

Run example from https://github.com/mozilla/localForage/blob/master/examples/index.html

In console window you will find

Saved: What we save offline (index):15
Result of reading unknown_key null (index):24
Read: null (index):18

Test on jsfiddle - http://jsfiddle.net/3hNth/1/

AFAIK, there is no storage abstraction library that gracefully deals with IndexedDB suddenly being available when it wasn't before; thus, end users of an app that use such a library find all their data "lost" when they update to a browser version that has IndexedDB. Fixing this in localForage would not only be great for end users, it would help set this library apart from the competition.

PhantomJS seems to not like:

var db = window.openDatabase(DB_NAME, DB_VERSION, STORE_NAME, DB_SIZE);

And throws:

SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent.

Putting that in a try catch and exiting early (as if !window.openDatabase happened) seems to prevent localforage from being defined. Problem for using this lib in a project that has unit tests being run through PhantomJS.

Note: PhantomJS is being run by grunt-contrib-jasmine in this instance.

There should be a way to force quality, async storage with no localStorage fallback.

Sometimes it's written as localForage and some other times it's localforage (including the name of the repository!).

Is this an accident? Or is there a reason for this? Can we fix it before everyone starts using it and people in Linux or using case sensitive file systems get errors? :-)

As discussed in #55 and #14, we need a way to propagate errors to the users, and I'd rather something reusable like callbacks than a node.js-style err first value passed to a sole callback. This also prevents us from modifying our method signatures in a backwards-incompatible way, which I like.

The callbacks to getItem(...) etc. contain the result value as first argument. If the method call fails, there is no way to get hold of this information from just using the callback.

Therefore, I propose to change the signature of the callbacks to be:

  callback(error, value)

similar to the style used in node.js.

We're sometimes publishing some of our web apps also as packaged Chrome Apps. In these cases, it would be awesome if this layer would also support the chrome.storage.sync API:

http://developer.chrome.com/extensions/storage.html

Here is a quick example of a storage handling script that supports both chrome.storage and localStorage: https://github.com/noflo/noflo-ui/blob/master/elements/noflo-account.html#L21

Hello.

Do you have any plans to add the encryption support? It's not quite safe to store some sensitive data as is. I think it is better to have a built-in encryption support rather that adding 3-d party bicycle.

Just wrap

    // Initialize localStorage and create a variable to use throughout the code.
    var localStorage = window.localStorage;

into

   try{
     var localStorage = window.localStorage;
   }catch(e){ return; }

For poor souls without IndexedDB

Currently localstorage doesn't support serializing and deserializing of objects with functions. since calling toString (or toJson, not sure.. ) destructs the original object. If localForage ( a great lib already!) would support that - It would be great!

When taking a first look at the "Browser Support" section on the main Readme.md file, it looks like the localForage library supports only IE10+. However, closer reading points out that IE10+ is supported if the developer wants to use an async storage solution.

To avoid this confusion, it might be good to add numbers for sync storage behind the async browser version numbers, e.g:

• IE (10+) (Sync version: 8+)

Related to #29, maybe we could have a custom build procedure for nerds that let them skip including the polyfill or certain drivers.

I am trying to write some examples for the library but the first thing I encountered is that it requires require.js and that's not mentioned in the README file. So my simple example:

<!doctype html>
<html>
    <head>
        <meta charset="utf8" />
        <title>Simple localForage example</title>
    </head>
    <body>
        <script src="../lib/localforage.js"></script>
        <script>
            var key = 'STORE_KEY';
            var value = 'What we save offline';

            localForage.setItem(key, value, function() {
                console.log('Saved!');
            });
        </script>
    </body>
</html>

fails:

15:37:41.241 ReferenceError: define is not defined localforage.js:5
15:37:41.247 ReferenceError: localForage is not defined index.html:13

I see three options here:

a) build a dist/localForage.js file with require's build tool
b) add the usual if amd / module.exports / something clause at the end of the file + tell people to include asyncStorage.js before localForage.js
c) do b but build dist ourselves so that it includes asyncStorage.js somehow wrapped in a closure so that it doesn't end up in window accidentally. The end result is a framework agnostic library that everyone can use.

The easiest option for users is c and it's the one I vote for.
Other opinions? :)

Not sure why this exists: https://github.com/mozilla/localforage/blob/65ac30452533f4af1feabf8acc973ed33dba4396/src/localforage.js#L2

The readme says it better, and isn't backbone-only.

I'd love to not checkin built artifacts, which I consider the .dist.js version to be. Is there some simple service that does this from GitHub services? Or should I write one? I'd do that.

To be clear, I'd be cool with it adding it to the gh-pages branch; I just loathe leaving a build from master inside the actual master branch.

It would be cool to be able to increment values and perform types of atomic operations. Can this be done without sacrificing the current API? Or by enabling an ADVANCED_MODE or some such?

After doing some performance measurements on my app I notice I suffer a lot from doing this:

localForage.getItem('all_ids', function(ids) {
    _.each(ids, function(id) {
        localForage.get(id, function(value) {
            ...
        });
    })
})

This is causing a lot of excess work for the browser if the list is long (e.g. 1,000+).

I know the localStorage spec doesn't have support getItems() but in most cases IndexDB is supported and it appears to have low level support for getting multiple keys which could hopefully reduce the overhead in total.

For the localStorage fallback, this would be trivial to wrap up with a for loop of kinds.

Noticed you have a package.json but that the module isn't on npm. Would be great to have it on there so people can use it with Browserify.

The quickest way would be to add a "browser" field to package.json pointing to the dist file and then doing a npm publish (might also have to add a line like module.exports = localForage)

Beyond that, localForage could use 'node.js-style' requires (instead of just concating all the files). And as a bonus, http://ci.testling.com/ could be used to automatically test a huge range of browsers. I'd be down to help with this if you're interested.

If you're not familiar, here's an intro to Browserify: http://blakeembrey.com/articles/introduction-to-browserify/

It would be nice to have promises returned from the getter/setter. Promises are the future!

They also aren't really incompatible with callbacks, you can do both.

Users should have the option, should they really want, to force a particular backend driver. In particular saying "don't fallback to localStorage as I have to store blobs/large data" would be nice.

I think Backbone adapters shouldn't modify the original sync function since it can be a important source of incompatibilities with other libs. It could just provide the sync function to be used on the selected models and collections (or manually overriding the default function if we want to).

Here's an example of a better approach IMO:

var LocalModel = Backbone.Model.extend({
  sync: Backbone.localforage.sync,
  offlineStore: new Backbone.localforage.Store('name')
});

Any ideas?

The backbone driver should have some tests!

Tremendous memory savings can be had for certain use cases by storing Blobs as Blobs. This is able to be done with Firefox's IndexedDB.

When storing and retrieving Blobs, it would be nice if localForage automatically converted between Blobs and Objects/JSON as necessary. In compatible browsers, it would not be necessary to have similar versions of the same data in memory.

Safari and Mobile Safari both disallow third party cookies by default. Unfortunately, they also treat WebSQL as a cookie-like storage mechanism and thus disallow it when in a cross-origin IFRAME.

Load this in Safari or Mobile Safari to see the error: http://jsfiddle.net/exogen/nBCGD/

If you don't see the error, it's likely because you've changed the default setting of disallowing third-party cookies. But here it is:

SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent.

It's particularly bad as the localForage library doesn't even finish running due to the exception. So if your page is running inside an IFRAME, and the parent window is on a different domain, any JS in the frame that runs after localForage will likely break.

a suggestion to rewrite localForage as prototype-based api
for example, when localForage is used by more than one lib on an app, there can some problems, and using key/clear functions can modifie the data of the other lib as they use the same database/namespace
i started rewriting the drivers and localforage.js files at https://github.com/lejenome/localForage/tree/prototype

It appears that the Backbone sync property isn´t being overwritten properly for me. When saving it requests that I need provide an url, which obviously shouldn´t be the case. Any idea how to fix this?

This is not an issue with my code the provided example doesn´t seem to work either for me.

Running Chrome on Ubuntu (ElementaryOS)

In my usecase, I want to store ArrayBuffers using localForage. At the moment localForage converts the input to a string using JSON.stringify when using the WebSQL and localStorage backends. For binary data, I think it is more reasonable to convert the input array to base64 string and then store it in the WebSQL/localStorage data base.

How does the idea to store the data in base64 encoding sound to you? Would you accept a PR that implements this feature?

PS: Issues that might be related to this: #28

Including a prefix on keys (or probably a database name for IndexedDB) can be a nice bit of isolation, and is probably relatively easy at this level. This would probably mean some storage factory.

.key(n) is kind of weird for localStorage too, but somehow we have it. Getting a simple list of keys seems far preferential. Also if you are doing things async there's lots of ways that .key(n) can go wrong (even with sync), if you do any kind of modification of the storage while iterating.

It might be nice to keep it to make code easier to translate, but still offer a nicer .keys() method.

This will likely be crazy slow and possibly just a fun experiment, but it would be neat if we could store a few small blobs in localStorage.

Allow to use localForage in Node.js environment.

localForage example code.

example code return a Reference error :
when i try with
localForage.getItem('....
localForage.setItem('....
it return
ReferenceError: localForage is not defined
localforage.getItem('....
localforage.setItem('....
is working.

Assuming a developer wants to store the string:

str = "'__lfsc__:hello world";

in localForage/WebSQL driver, the string can be saved BUT it cannot be read out. This is, as the marker makes the WebSQL driver think the content is serialized and tries to pass hello world to the JSON.parse(...) method - which fails.

An easy fix is to prefix all strings stored in the WebSQL driver and not just the ones that serialized:

// Marker used here:
//   s: ^= String
//   o: ^= Object
localforage.setItem('foo') // -> gets stored as "s:foo" << string
localforage.setItem({hello: "world"}) // -> gets stored as 'o:{"hello":"world"}'

If you look at the 'onerror' handler, you'll see that IndexedDB errors are being "handled" but the reject handler isn't being called. WebSQL and LocalStorage seem to be calling it, I'm just curious why IndexedDB isn't.

These should probably be published to gh-pages.

In FF v27.0.1 occurs error:

asyncStorage: can't open database: InvalidStateError
InvalidStateError

in this code:

var openreq = indexedDB.open(DBNAME, DBVERSION);

In Chrome v32.0.1700.107 m everything works fine.
Could you help me?

I use angularLocalStorage because it makes synching scope data to the LocalStorage a oneliner:

storage.bind($scope,'data');

Would be awesome to have this for LocalForage, too.

I was thinking maybe we should have a Backbone example too, but I'm not sure about how to provide it. Just in the examples folder with the whole Backbone thing so it's just open and play?

Help, @tofumatt!

It would be awesome for this library to add namespacing as a core concept from the start. This would mean other libraries could be built that depend on localForage and do so in a way that avoids collisions/conflicts.

See https://github.com/joelarson4/LSNS for my train of thought.

I seem to be having a problem using the minified localforage.min.js as a dependency in my app. The file is getting loaded and eval'd fine, but in my module it is undefined.

define(["localforage.min"], function(lf) {
    console.log(lf); // => undefined
});

It works fine with the un-minified version, however

define(["localforage"], function(lf) {
    console.log(lf); // => Object { INDEXEDDB="asyncStorage", LOCALSTORAGE="localStorageWrapper", WEBSQL="webSQLStorage", more...} main.js (line 3)
});

Hi,

I'm looking for a way to store huge files (possibly > 1 Go) on the browser. I had a look at the FileSystem API (implemented in Chrome) and FileHandle API (implemented in Firefox). Though both these APIs have very similar goals, there is no polyfill to unify their usage.

Is storing big files in the scope of LocalForage? If so, I'd love to help working on drivers for these. As a bonus, you'd get a nice quota manager (see #31) and blob storage (#28, #30, #40) for free!

seen https://github.com/maxogden/level.js?

Perhaps you could consider some collaboration here or at least a mention in the readme since these are basically the same api except that level-js conforms to an interface that allows it to work with much of the existing leveldb ecosystem.