You're viewing the legacy docs. They are deprecated as of May 18, 2016.

JavaScript Web Guide

Retrieving Data

Data stored in a Firebase database is retrieved by attaching an asynchronous listener to a database reference. The listener will be triggered once for the initial state of the data and again anytime the data changes. This document will cover the basics of retrieving database data, how data is ordered, and how to perform simple queries on data.

We can pass an optional cancel callback to our event subscription (lines 7 - 9) that will be called if the read is ever cancelled. A read would be cancelled if the app client doesn't have permission to read from that database reference. This callback will be passed an error object indicating why the failure occurred.

If we run this code, we'll see an object containing all of our posts logged to the console. This function will be called anytime new data is added to our database reference, and we don't need to write any extra code to make this happen.

The callback function receives a DataSnapshot, which is a snapshot of the data. A snapshot is a picture of the data at a particular database reference at a single point in time. Calling val() on a snapshot returns the JavaScript object representation of the data. If no data exists at the reference's location, the snapshots value will be null.

Notice that we used the value event type in our example above, which reads the entire contents of a Firebase database reference, even if only one piece of data changed. value is one of the five different event types listed below that we can use to read data from the database.

Read Event Types

Value

The value event is used to read a static snapshot of the contents at a given database path, as they existed at the time of the read event. It is triggered once with the initial data and again every time the data changes. The event callback is passed a snapshot containing all data at that location, including child data. In our code example above, value returned all of the blog posts in our app. Everytime a new blog post is added, the callback function will return all of the posts.

Child Added

The child_added event is typically used when retrieving a list of items from the database. Unlike value which returns the entire contents of the location, child_added is triggered once for each existing child and then again every time a new child is added to the specified path. The event callback is passed a snapshot containing the new child's data. For ordering purposes, it is also passed a second argument containing the key of the previous child.

If we wanted to retrieve only the data on each new post added to our blogging app, we could use child_added:

In this example the snapshot will contain an object with an individual blog post. Because we converted our post to an object using val(), we have access to the post's author and title properties by calling author and title respectively. We also have access to the previous post ID from the second prevChildKey argument.

Child Changed

The child_changed event is triggered any time a child node is modified. This includes any
modifications to descendants of the child node. It is typically used in conjunction with child_added
and child_removed to respond to changes to a list of items. The snapshot passed to the event callback contains the updated data for the child.

We can use child_changed to read updated data on blog posts when they are edited:

// Get a reference to our posts
var ref = new Firebase("https://docs-examples.firebaseio.com/web/saving-data/fireblog/posts");
// Get the data on a post that has changed
ref.on("child_changed", function(snapshot) {
var changedPost = snapshot.val();
console.log("The updated post title is " + changedPost.title);
});

Child Removed

The child_removed event is triggered when an immediate child is removed. It is typically used in conjunction with child_added and child_changed. The snapshot passed to the event callback contains the data for the removed child.

In our blog example, we'll use child_removed to log a notification about the deleted post to the console:

// Get a reference to our posts
var ref = new Firebase("https://docs-examples.firebaseio.com/web/saving-data/fireblog/posts");
// Get the data on a post that has been removed
ref.on("child_removed", function(snapshot) {
var deletedPost = snapshot.val();
console.log("The blog post titled '" + deletedPost.title + "' has been deleted");
});

Child Moved

The child_moved event is used when working with ordered data, which is covered in the next section.

Event Guarantees

The Firebase database makes several important guarantees regarding events:

Database Event Guarantees

Events will always be triggered when local state changes.

Events will always eventually reflect the correct state of the data, even in cases where local operations or
timing cause temporary differences, such as in the temporary loss of network connection.

Writes from a single client will always be written to the server and broadcast out to other users in-order.

Value events are always triggered last and are guaranteed to contain updates from any other events which occurred
before that snapshot was taken.

Since value events are always triggered last, the following example will always work:

Reading Data Once

In some cases it may be useful for a callback to be called once and then immediately removed. We've created a helper
function to make this easy:

ref.once("value", function(data) {
// do some stuff once
});

Querying Data

With Firebase database queries, we can selectively retrieve data based on various factors. To construct a query in your database, you start by specifying how you want your data to be ordered using one of the ordering functions: orderByChild(), orderByKey(), orderByValue(), or orderByPriority(). You can then combine these with five other methods to conduct complex queries: limitToFirst(),
limitToLast(), startAt(), endAt(), and equalTo().

Since all of us at Firebase think dinosaurs are pretty cool, we'll use this database of dinosaur facts to demonstrate how you can query data in your Firebase database. Here's a snippet of the dinosaur data:

Any node which does not have the child key we're querying on will be sorted with a value of null, meaning it will come first in the ordering. For details on how data is ordered, see the How Data is Ordered section.

Queries can also be ordered by deeply nested children, rather than only children one level down. This is useful if you have deeply nested data like this:

Queries can only order by one key at a time. Calling orderByChild()
multiple times on the same query throws an error.

Using Indexes For Improved Performance

If you want to use orderByChild() on a production app, you should define the
keys you will be indexing on via the .indexOn rule in your Security and
Firebase Rules. While you are allowed to create these queries ad-hoc on the client, you
will see greatly improved performance when using .indexOn.
Read the documentation on the
.indexOn rule for more information.

Ordering by key name

We can also order nodes by their keys using the orderByKey() method. The
following example reads all dinosaurs in alphabetical order:

Ordering by value

We can order nodes by the value of their child keys using the orderByValue() method. Let's say the dinosaurs are having a dino sports competition and we're keeping track of their scores in the following format:

See the How Data is Ordered section for an explanation on how null, boolean, string, and object values are sorted when using orderByValue().

Indexing on Values for Improved Performance

If you want to use orderByValue() in a production app, you should add .value to your rules at the appropriate index. Read the documentation on the
.indexOn rule for more information.

Ordering by priority

We can explicitly order nodes by priority by calling the orderByPriority()
method. Details on priorities can be found in the API reference.

Complex Queries

Now that we've specified how your data will be ordered, we can use the limit or range methods described below to construct more complex queries.

Limit Queries

The limitToFirst() and limitToLast() queries are used to set a
maximum number of children to be synced for a given callback. If we set a limit of 100, we
will initially only receive up to 100 child_added events. If we have fewer than
100 messages stored in our database, a child_added event will fire for each
message. However, if we have over 100 messages, we will only receive a child_added
event for 100 of those messages. These will be the first 100 ordered messages if we are using
limitToFirst() or the last 100 ordered messages if we are using
limitToLast(). As items change, we will receive child_added events
for items that enter the query and child_removed events for items that leave it,
so that the total number stays at 100.

Using our dinosaur facts database and orderByChild(), we can find the two heaviest
dinosaurs:

Our child_added callback will be triggered exactly two times, unless there are
less than two dinosaurs stored in the database. It will also get fired for every new, heavier dinosaur that gets added to the database.

Similarly, we can find the two shortest dinosaurs by using limitToFirst():

Our child_added callback will be triggered exactly two times, unless there are less than two dinosaurs stored in the database. It will also get fired again if one of the first two dinosaurs is removed from the database, as a new dinosaur will now be the second shortest.

We can also conduct limit queries with orderByValue(). If we want to create a leaderboard with the top 3 highest scoring dino sports dinosaurs, we could do the following:

Range Queries

Using startAt(), endAt(), and equalTo() allows us to
choose arbitrary starting and ending points for our queries. For example, if we wanted to
find all dinosaurs that are at least three meters tall, we can combine orderByChild()
and startAt():

The \uf8ff character used in the query above is a very high code point in the
Unicode range. Because it is after most regular characters in Unicode, the query matches all values that
start with a b.

The equalTo() method allows us to filter based on exact matches. As is the case
with the other range queries, it will fire for each matching child node. For example, we can
use the following query to find all dinosaurs which are 25 meters tall:

How Data is Ordered

This section explains how your data is ordered when using each of the three ordering functions.

orderByChild

When using orderByChild(), data that contains the specified child key will be ordered as follows:

Children with a null value for the specified child key come first.

Children with a value of false for the specified child key come next. If multiple children have a value of false, they are sorted lexicographically by key.

Children with a value of true for the specified child key come next. If multiple children have a value of true, they are sorted lexicographically by key.

Children with a numeric value come next, sorted in ascending order. If multiple children have the same numerical value for the specified child node, they are sorted by key.

Strings come after numbers, and are sorted lexicographically in ascending order. If multiple children have the same value for the specified child node, they are ordered lexicographically by key.

Objects come last, and sorted lexicographically by key name in ascending order.

orderByKey

When using orderByKey() to sort your data, data will be returned in ascending order by key name as follows. Keep in mind that keys can only be strings.

Children with a key that can be parsed as a 32-bit integer come first, sorted in ascending order.

Children with a string value as their key come next, sorted lexicographically in ascending order.

orderByValue

When using orderByValue(), children will be ordered by their value. The ordering criteria is the same as in orderByChild(), except the value of the node is used instead of the value of a specified child key.

orderByPriority

When using orderByPriority() to sort your data, the ordering of children is determined by their priority and key as follows. Keep in mind that priority values can only be numbers or strings.

Number priorities are stored and ordered as IEEE 754 double-precision floating-point numbers.
Keys are always stored as strings and are treated as numeric only when they can be parsed as
a 32-bit integer.

Children with no priority (the default) come first.

Children with a number as their priority come next. They are sorted numerically by priority, small to large.

Children with a string as their priority come last. They are sorted lexicographically by priority.

Whenever two children have the same priority (including no priority), they are sorted by key. Numeric keys come first (sorted numerically), followed by the remaining keys (sorted lexicographically).