Using AngularJS and Firebase / AngularFire to Create a Dynamic Active Users List

I’ve been working on an AngularJS app backended by Firebase – both building some experiments at work and also incorporating the stacks in a couple of side projects. Firebase has a fairly interesting Angular library they call AngularFire, which offers a socket.io-like feature to easily sync your data between multiple clients and the server (you can read up on it a bit here and here). When paired with Angular, this allows for a “three-way data bind”, which is basically a riff off of Angular’s two-way data bind, between your model and view and expands it to your server.

Firebase has some pretty elaborate fully built apps, but as a proof of concept in how to use what I saw as the core features I put together an active users list – think of it like what you get in your Facebook sidebar. The currently logged in users get displayed, and the fact that a new user has arrived is broadcasted to the other currently logged in users. And as a bonus, I include a few extra design patterns so that you don’t have to do a lot of guess work on how to stitch it all together.

#1 – Setup your Angular application

So I will make a basic assumption that you can setup an authentication method for your application. For the sake of simplicity I will use the design pattern suggested here.

So use your Auth method, and get your user logged in. The next thing to do is setup Firebase as part of your application. You will need to look up the most recent versions of both Firebase and AngularFire and add them to your main application HTML file. I have those listed below as of this writing.

Next, you need to add Firebase to your Angular build. I also like to add my Firebase location as a constant so I don’t have to keep referring to the entire string. And that’s really all you need to have Firebase wired up.

If
currentAuth is empty and my
Session variable is empty (which I have not yet introduced),

I rebuild the
Auth and the
Session

This process is aimed not at keeping out unauthenticated users (again, I am assuming you can build that system for your application), but for handling events like reloads and revisits without a) requiring the user to log in every time and b) rebuilding your entire user profile every time the user changes the view.

So let’s look at some of the guts of
Session and
Rebuild, which then lead on to the more interesting Firebase work.

#2 – Create some factories to handle some common work

I use a factory I call
reBuilder to recreate any lost information from the last time the user was on the page. The user may still be authenticated to Firebase, but the client may need profile information or the index key of the user. In this example,
Auth is a factory that uses Firebase’s recommended method.
ActiveUsers will be addressed in the next section.

This leads us to a
Session service. I use a basic service to store some common variables. In this example, I only create Session, but in a fuller version, you would destroy, edit, etc. I’m also only storing the
userId and a key in this example, but you could clearly store as much or as little as you like there. Do keep in mind, though, that this is a client-side app and a variable called Session would probably stand out to anyone sniffing around for sensitive data. Just saying.

Queries on Firebase can be a little funky, and while they are getting better, they are still a bit of a mental loop. Essentially I am using AngularFire’s
$asArray, which includes an
$indexFor option. If the index does not exist, it can return -1. I am basically checking to see if the keys are in sync in both positions. If they happen to be out of sync, new keys will be written for this user.

Finally, I am using
$watch to sync the changes that occur with
activeusers to my model and my view. When changes do happen, the list gets updated across all clients, and those changes are broadcasted by a factory to a controller that is listening for them.

#4 – Consider clean up options for your build

I am not going to include clean up options because those are going to be really specific to the needs of your particular project. Facebook considers the user logged off when the user closes the window, so you may want to consider
onbeforeload (spec here) to do some actions to change your user’s state. Time stamps are another way to go. You will also want to consider how to clean up unused keys for when your users log back in and update them.

There are several design decisions that go into all of that but with a means of getting things started, hopefully making the back piece of the work finish out will be a few steps easier.