#usersdata | Explore Tumblr Posts and Blogs

mancdev · 8 years

Text

Using Firebase Promises

With Firebase you don't have to worry about a back-end, an API, a database or any of that stuff and with the recent addition of Cloud Functions, we can now write JS server-side code as well - all with Firebase. It's quite simply beyond awesome. I've used Firebase for over 2 1/2 years for prototyping and proof-of-concepts and in 1 case as a small part of a production app but, due to the previous lack of server-side code capabilities never a full production app built entirely on Firebase. Upon attempting to do so it quickly became clear that learning asynchronous programming the Firebase way is a prerequisite and for any serious app you have to use Firebase Promises. You simply cannot avoid it.

In this post I'll cover what you need to know to use Firebase Promises to get you writing asynchronous database apps. Knowing Promises inside and out is useful but if you know how to get them to work within Firebase for a serious production app then you can expand your knowledge from that context rather than learning them as an abstract concept up-front and then trying to apply them to Firebase. None of the videos or articles I saw when I was learning Firebase Promises took this approach so this post is an aid for those who need to get going with Firebase's Promises without getting bogged down in the detail and will hopefully help clear the path a little for others who face the same problems I did.

Up until early 2016 Firebase relied entirely on callbacks. You registered an event to listen for changes on a particular node of your database and you provided it with a callback function that got executed initially and then when changes were made to the data. Of course it was asynchronous so you never knew when it would get fired but it was simple enough to isolate the callbacks from other parts of your code. If I needed to query other data whenever the callback was triggered I would just nest the code within the original callback function. I did get to about 4 levels of nesting with one prototype but it was fine, it did the job.

However when you start developing something more serious with Firebase things start to get a little tricky. Let's say you need to get some data and based on that value query something else and then based on that value query something else and then, based on that, ask the user for some input and so on. You can't simply nest all of your application logic in a callback function - it would get messy, ugly and well it's just not the done thing.

Fortunately early in 2016 Firebase released support for Promises. Promises save us from callback nesting hell by allowing us to chain asynchronous function calls together. With Promises you can run a function which makes an asynchronous query on a Firebase node and once it gets a result back from the database it then runs your next function, again with an async Firebase event, and when it gets that result back then it runs you next query and so on to allow a neat sequence of database queries all without nesting.

Promises is a big subject on it's own but here's my attempt to explain them as simply as I can - A Promise is a mechanism which allows you to make an asynchronous call and promises to give control back to you once it is either successful or unsuccessful. If it succeeds it enables you to read the outcome and deal with it accordingly when it's done. This makes it a perfect match for Firebase, to issue a query asynchronously with a promise to execute your code once the data is retrieved.

Having attempted it myself I would offer a word of advice. Do not attempt to develop a serious app in Firebase without using Promises. Just don't do it. Callbacks will drag you down as fast as quicksand into the 7 fires of development hell - you really don't want that. Promises make working with an asynchronous database almost (and I reiterate, almost) as easy as working synchronously with data. If you've chosen Firebase as your back-end (and it's a truly beautiful thing) then it's well worth any time you spend to learn it's Promises API.

Fortunately, with all of that said, Firebase makes it's pretty straightforward to convert from using the traditional callback events to promises :

Using Callbacks

dbRef.on('value', function(snapshot) { } ) Using Promises

dbRef.on('value').then(function(snapshot) {} )

So all we're doing is wrapping our callback function within then() of a Firebase Promise rather than as the second parameter of the on or once function call. If this is all we do then fine, it will work exactly as it did with the callback although we don’t really gain anything.

Please Note : As we're now in the post-ES5 world, I'll be using arrow function syntax from hereon in.

So what is this new-fangled then() function? It's part of Promises generally and is also baked into the Firebase promise API. Basically when you use the Promise API, the then() function gets executed if the call to the Firebase on() or once() functions were successful. We can also use a different function if there was an error with the call but we won't cover it in this post.

However Promises are only really useful when they are chained. Let's say we need to look-up a user's data. We've got their email address from the log-in process and we need to find their record from the database and when we've got it we can then work out where their actual information is located in the database so we can query for their data. The image below shows the structure of the data.

First of all we have to run a query to find the user record. As we only want to run it one time to get a result and not continue to listen for changes we'll use the once() event function.

query = dbRef.child('users').orderByChild('email').equalTo(loginEmail).limitToFirst(1);

query.once('value').then(snapshot => {} )

This post isn’t about Firebase queries but I'll briefly explain what we're doing. We're looking on the users node child('users') and searching by the email property within that node orderByChild('email'), looking for a record with an email property equal to the login email equalTo(loginEmail) and making sure we only get the first record it finds limitToFirst(1). We're using the 'value' event rather than the 'child_added' event as we want it to trigger even if no results are returned from the query.

In the callback function we return the unique key from the user's record we find :

query.once('value').then(snapshot => { let userKey = ''; if (snapshot) { snaphot.forEach(childSnap => { userKey = childSnap.key; }) } return userKey; });

As we're using the 'value' event on the 'users' node, Firebase will point us to that node and we'll have to dig into it using the forEach function to get at the actual document that's been found and grab it's key. The key will then give us the id of the node we need to point to get their main data.

Our next step is to use the key that's being returned and run another query to get the user's data. However If we don't use promises we have no way of knowing when the result of our first query will come back from the database so we won't know when to call our second query. To set up our second query to only trigger when we know that the first query has returned a value we place the second query in another Firebase Promise then() function.

This is where it can get a little confusing. What does the then() function actually return and how can we get the key we return from our first callback into the second query?

The key thing to remember here is then() returns yet another Promise object. Therefore this new returned Promise provides it's own then() function that we can call to chain to the first promise. In this returned Promise we can use then() to include our second query which will only get called when the first query is done ie

query.once('value').then(snapshot => { let userKey = ''; if (snapshot) { snaphot.forEach(childSnap => { userKey = childSnap.key; }) } return userKey; }) .then();

All well and good but how can we get at the value of userKey returned out of the callback in our first promise. The answer to this is when we return a value from a callback, it is passed back to the then() function that called it. then() passes your return value from your callback to the new Promise it's returning. The new Promise then passes that value into the parameters of it's own then() function.

query.once('value').then(snapshot => { let userKey = ''; if (snapshot) { snaphot.forEach(childSnap => { userKey = childSnap.key; }) } return userKey; }) .then(userKey => { });

From within the callback function that we declare in the new then() we can read the userKey value and query the database accordingly in the knowledge that the first query has been run.

In the next query we use the userKey passed in by the second Promise to get at the database node we want, retrieve the user's data and populate it into an array eg :

.then(userKey => { let userDataRef = dbRef.child('usersdata').child(userKey); return userDataRef.on('value').then(snapshot => { let userDataList = []; if (snapshot) { snapshot.forEach(childSnap => { userDataList.push({ /*store data properties*/ }); }); } return userDataList; } });

Notice that we return the result of the new query then() function call . As we explained earlier this is another Promise so by returning a Promise from this we can chain yet another promise to call then() and add another step in the chain until the whole process is completed.

If we flatten the code we can see how values are returned from one step in the promise to the next :

query.once('value').then(snapshot => { return value1 } ) ________________________________| | .then(value1 => { return then(snapshot => { return value2 } ) } ) ____________________________________| | .then(value2 => { return then(snapshot => { return value3 } ) } )

Once you've got all of the values you need out of the data you could add another step in the promise chain to render the results to the screen etc. This is how we work with queries in Firebase particularly where multi-step queries are required.

One other important thing is to remember that other code in sequence after the promise will continue to be executed without deference to the promise chain. Therefore don't assume that promises will stop the execution of your entire app completely until a particular promise chain is done. Only the steps in the promise chain will wait and execute after each step, everything else will run in sequence in your code. Therefore if you need the chain to complete before your app moves on you should add a function call on the very last then() in the chain to continue running your app.

The wrong way to handle asynchronous execution

function GetUserData() { let userData = []; //run promise chain to perform multi-step query .then( dbQueryVals => { //last promise in the chain to get executed userData = dbQueryVals; } return userData; } userData = GetUserData(); RunApp(userData); //this is outside of the promise & so gets executed //immediately regardless of whether the queries in //the promise chain have been resolved

The right way to handle asynchronous execution

function GetUserData() { //run promise chain to perform multi-step query then(userData => { //last promise in the chain to get executed RunApp(userData); //runs the app when everything is done }); //and queries are resolved }

Alternatively you could make the GetUserData() function create and return it's own promise and chain the call to RunApp() within a then() returned from that promise. That's getting more into general promises for the scope of this post but, now you know how Firebase promises work, you can expand your knowledge of how Promises work.

If you're a budding Firebase developer or, like me, have used it before but now getting serious with building full production apps on it, I hope this helps gives you the info you need to deal with the async ways of Firebase. Good luck :)

0 notes