Very Simple IndexedDB Example

IndexedDB101.js

// This works on all devices/browsers, and uses IndexedDBShim as a final fallback 
var indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB || window.shimIndexedDB;

// Open (or create) the database
var open = indexedDB.open("MyDatabase", 1);

// Create the schema
open.onupgradeneeded = function() {
    var db = open.result;
    var store = db.createObjectStore("MyObjectStore", {keyPath: "id"});
    var index = store.createIndex("NameIndex", ["name.last", "name.first"]);
};

open.onsuccess = function() {
    // Start a new transaction
    var db = open.result;
    var tx = db.transaction("MyObjectStore", "readwrite");
    var store = tx.objectStore("MyObjectStore");
    var index = store.index("NameIndex");

    // Add some data
    store.put({id: 12345, name: {first: "John", last: "Doe"}, age: 42});
    store.put({id: 67890, name: {first: "Bob", last: "Smith"}, age: 35});
    
    // Query the data
    var getJohn = store.get(12345);
    var getBob = index.get(["Smith", "Bob"]);

    getJohn.onsuccess = function() {
        console.log(getJohn.result.name.first);  // => "John"
    };

    getBob.onsuccess = function() {
        console.log(getBob.result.name.first);   // => "Bob"
    };

    // Close the db when the transaction is done
    tx.oncomplete = function() {
        db.close();
    };
}

Nice and concise example, but for others reading this, I would not recommend coding against the raw indexedDB API unless you really have to. Search for a decent wrapper library instead. Just too many pitfalls to end up in. For example, the above snippet is missing error handlers, which is okay for a demo snippet like this, but not for production code.

Performance is also a reason to use a wrapper library like dexie that can do multiple operations in a single transaction without sacrificing code readability and error handling.

Google for indexedDB wrapper libraries or similar and try finding one that is simple or advanced enough for your particular use case.

You'll probably find that these three libs stand out:

• Dexie - promise based fluent-style indexedDB wrapper with transaction support.
• localforage - simplest one - a key/value api similary to localStorage
• pouchdb - offline storage that syncs with a couchDB compatible backend.

David Fahlander, author of Dexie.

Thankyou,
A beautiful implementation of indexedDB.
This is very helpful in making offline first web application.
May you please suggest some techniques to store static files like style/css file to indexed db?

thxs a lot, easy and simple
Nice work

Nice !

Excellent example of exactly what people need to get started! thanks!

Simple and straight to the point. Thanks.

thank you very much

Thanks 👍

Thanks 👍

GREAT JOB BUDDY, WHAT dfahlander SAID, ITS TRUE, BUT IT' S A GREAT DEMO

It's a great demo.

@Shikha-shakarwar I think window.caches better fits your requirement
https://googlechrome.github.io/samples/service-worker/window-caches/

thanks for Simply example, this will help me in understanding the interaction with the database!

I am currently writing some IndexedDB code and it occurred to me I have no idea how registering the onsuccess AFTER calling the store.get() works. Is there a delay before firing the on success event? Isn't this a race condition?

Finally, 1 small page with explanation how to work it properly.

This was the best and most easy to read code and tutorial I could find. The only thing I am trying to figure out is now is trying to update a row?

thanks for these awesome snippets .. :)

awesome snippet!

great one thanks :)

thanks very readable snippet

Oh! this was supper easy to understand. Thank you!

Thanks 👍

hi I have a small challenge. can you please explain how to apply this to a situation where you are fetching data from an API? I mean the "add some data" part.

Thank you!! :D

Thanks✌️

Amazing! Thnx! :D

Thank you very much

Awesome :)

I have a comment, which is more of a question. You execute four operations against the store (two writes and two reads). The database is closed when the transaction is completed. From what I there is a high risk that the database will be closed before one of the operations is actually completed. Am I right or am I missing something?

I have a comment, which is more of a question. You execute four operations against the store (two writes and two reads). The database is closed when the transaction is completed. From what I there is a high risk that the database will be closed before one of the operations is actually completed. Am I right or am I missing something?

This one could answer your question:
https://stackoverflow.com/questions/34915581/indexeddb-when-to-close-a-connection