Getting Data Into Your App

Ember.js gives you the tools you need to keep your models synchronized with your UI. That’s great, but how do you get data into your models in the first place?

To recap, Ember.js pages have a lifecycle that is designed to make it easy to keep your data and URL in sync.

• When the user loads the application, Ember looks at the URL and invokes the model hooks in the Routes specified by your router definition.

• Ember then renders the templates for those routes, hooking up the model to the template.

• When a template uses {{link-to 'route'}}, Ember automatically generates a URL from the router definition.

• When the user clicks on the link, Ember renders the template for the route specified in the link-to. If any models were specified ({{link-to 'post' post}}), Ember will hook up the specified model to the template it renders.
• Also, when the user clicks on the link, Ember will update the URL.

Insert Diagram Here

As far as Ember is concerned, you can return any JavaScript object from the model hook, including a plain JavaScript object, so you can work with raw JSON requests to your server if you want.

In practice, you will probably want more structure in your model layer, and Ember Data provides additional features that may help you:

• Model objects that can contain additional computed properties and methods, rather than working directly with Plain Old JavaScript Objects.
• A built-in cache so that you can avoid making additional Ajax requests if the data you need is already available in memory.
• Flags on each model that you can use to determine whether a record is loading, saving, dirty, newly created, deleted, and more. You can use these flags to control the UI. For example, you may want to show some UI (a spinner) when a record is saving, or disable editing when it’s saving.
• Automatic, efficient filters on your models that you can use to build live arrays that match conditions on each record. For example, you could build a live array that contained only Person records whose last name was “Lannister” or whose isSaving flag was true. The arrays are updated incrementally only when the properties change.
• Support for several different kinds of relationships. Relationships can be populated with an Array of IDs, a URL, or determined lazily based on information in the parent model.
• When relationships are specified by ID, avoiding additional fetches from the server for records that are already loaded.
• Support for saving records, and tracking what exactly has changed on your model object.
• Support for rolling back changes that the user made since the last fetch or save. This makes it easy to implement cancel buttons, for example.
• A well-defined separation between your model objects, how they are fetched from the server, how they are converted into the form expected by your application, and how they are saved back to the server.

In addition to these features, Ember Data comes with built-in support for REST-like APIs. If your server’s API is close to the API that the RESTAdapter expects, you can avoid having to write explicit Ajax code and serialization/deserialization logic.

Some features of the RESTAdapter:

• Automatically builds URLs for you based on the name of your model class.
• Automatically makes Ajax requests to the built URL, ensuring that the right headers are present and any data is serialized correctly.
• Handles payloads that contain multiple records at a time, so you can make a single HTTP request and get back multiple records.
• Handles server responses that embed models inside of other models.
• Handles “sideloading”—returning a normalized payload with all records grouped by type instead of embedded. This allows you to avoid duplicating records that are referenced by multiple other records (such as the author of a blog post—sideloading allows you to include the author of multiple posts one time in the payload).
• Allows pushing data embedded in the HTML using the same structure as your server’s normal Ajax responses as an initial payload (to improve performance).

Additionally, by using any Adapter (either by making your own Ajax requests or using the built-in REST Adapter), you can prototype your application using the Fixture Adapter and upgrade your models to use the server when you’re ready.

You can also make these decisions on a model-by-model basis. You might have some models using raw Ajax in the model hook, some models using the raw Adapter API, some models using the REST Adapter, and newer parts of your application on fixtures.

The rest of the guides in this section walk you through how to use each of these techniques, and go into more detail about when each one is appropriate.