AngularJS IndexedDB Demo

Over the past few months I’ve had a series of articles (Part 1, Part 2, Part 3) discussing IndexedDB. In the last article I built a full, if rather simple, application that let you write notes. (I’m a sucker for note taking applications.) When I built the application, I intentionally did not use a framework. I tried to write nice, clear code of course, but I wanted to avoid anything that wasn’t 100% necessary to demonstrate the application and IndexedDB. In the perspective of an article, I think this was the right decision to make. I wanted my readers to focus on the feature and not anything else. But I thought this would be an excellent opportunity to try AngularJS again.

For the most part, this conversion worked perfectly. This may sound lame, but I found myself grinning as I built this application. I’m a firm believer that if something makes you happy then it is probably good for you. ๐Ÿ˜‰

I still find myself a bit… not confused… but slowed down by the module system and dependency injection. These are both things I grasp in general, but in AngularJS they feel a bit awkward to me. It feels like something I’ll never be able to code from memory, but will need to reference older applications to remind me. I’m not saying they are wrong of course, they just don’t feel natural to me yet.

On the flip side, the binding support is incredible. I love working with HTML templates and $scope. It feels incredibly powerful. Heck, being able to add an input field and use it as a filter in approximately 30 seconds was mind blowing.

One issue I ran into and I’m not convinced I created the best solution for was the async nature of IndexedDB’s database open logic. AngularJS has a promises library built in and it works incredibly well for my application in general. But I needed the entire application to be bootstrapped to an async call for database startup. I got around that with two things that felt a bit like a hack.

First, my home view (get all notes) ran a call to an init function to ensure the db was already open. So consider this init():

function init() {
		var deferred = $q.defer();

		if(setUp) {
			return deferred.promise;
		var openRequest ="indexeddb_angular",1);
		openRequest.onerror = function(e) {
			console.log("Error opening db");

		openRequest.onupgradeneeded = function(e) {
			var thisDb =;
			var objectStore;
			//Create Note OS
			if(!thisDb.objectStoreNames.contains("note")) {
				objectStore = thisDb.createObjectStore("note", { keyPath: "id", autoIncrement:true });
				objectStore.createIndex("titlelc", "titlelc", { unique: false });
				objectStore.createIndex("tags","tags", {unique:false,multiEntry:true});

		openRequest.onsuccess = function(e) {
			db =;
			db.onerror = function(event) {
				// Generic error handler for all errors targeted at this database's
				// requests!
				deferred.reject("Database error: " +;

		return deferred.promise;

This logic is similar to what I had in the non-framework app but I’ve made use of promises and a flag to remember when I’ve already opened the database. This lets me then tie to init() in my getNotes logic.

	function getNotes() {
		var deferred = $q.defer();
		init().then(function() {

			var result = [];

			var handleResult = function(event) {  
				var cursor =;
				if (cursor) {
					result.push({key:cursor.key, title:cursor.value.title, updated:cursor.value.updated});
			var transaction = db.transaction(["note"], "readonly");  
			var objectStore = transaction.objectStore("note");
            objectStore.openCursor().onsuccess = handleResult;

			transaction.oncomplete = function(event) {
		return deferred.promise;

All of this worked ok – but I ran into an issue on the other pages of my application. If for example you bookmarked the edit link for a note, you would run into an error. I could have applied the same fix in my service layer (run init first), but it just felt wrong. So instead I did this in my app.js:

$rootScope.$on("$routeChangeStart", function(event,currentRoute, previousRoute){
		if(!persistanceService.ready() && $location.path() != '/home') {


The ready call was simply a wrapper to the flag variable. So yeah, this worked for me, but I still think there is (probably) a nicer solution. Anyway, if you want to check it out, just hit the Demo link below. I want to give a shoutout to Sharon DiOrio for giving me a lot of help/tips/support while I built this app.

p.s. I assume this is obvious, but I’m not really offering this up as a “Best Practices” AngularJS application. I assume I could have done about every part better. ๐Ÿ˜‰

  • Krishna

    Very nice tutorial. Makes for a great starter app as well. Thanks much!

    • crazy people

      Shut up you fucking black indians

  • crazy people

    limao !! wanna rascala ! mind it !!

  • am2605

    As always, just what I needed Ray. Thanks for sharing – your site is invaluable to me!

    • http://www.raymondcamdencom/ Raymond Camden

      You are most welcome.

  • Stephen Cooper

    Brilliant, thanks for sharing.

    I’d read your other three posts before finding this. Promises make working with indexedDB so much easier. Shame we still have to support browsers that wont be ES6 compliant, at least Angular helps there.

    There were a couple of hiccups i noticed though. Your indexedDB service doesn’t always reject the promise in some of its requests, the getNote for example. Meaning if the read failed the caller’s catch wont be called (Unless it throws an exception if you don’t register an onerror handler, which angular will catch). Also in the save method, the add you save the getTime() of a date object whereas in the put your store the date object itself. Does indexdDB store the actual date object, or a string like localStorage?

    Also on a side note of angular the methods where you call init first (getNotes for example) you don’t need to create a new defered promise, simply return the promise chain you created after the init function and your controller can continue chaining the promises.

    • http://www.raymondcamdencom/ Raymond Camden

      Yeah, I kinda get lazy w/ error handling – and I really shouldn’t.

      “Also in the save method, the add you save the getTime() of a date object whereas in the put your store the date object itself. Does indexdDB store the actual date object, or a string like localStorage?”

      I honestly don’t remember, but it smells like a bug in the put section. It should be consistent.

      Good point on the init thing too!