Series: Introduction to Ember Data 2.0

Ember Data 2.0-Miscellaneous Adapter Customizations

Published on Jan 27, 2016

In this video we go over the last of the Ember Data RESTAdapter customization methods. The miscellaneous ones that didn’t make it into the top 5 of episode 110 or the deep dive of 111.

All of them - the shouldReload set of methods, pluralization techniques, sortQueryParams, serializer, defaultSerializer, coalesceFindRequests, findMany, groupRecordsForFindMany, and generateIdForRecord.



  • shouldReload set of methods together decide when to check for updates from the server- before returning the current cache value, after returning current cache value, or never.
  • pluralization techniques are how you add unconventional pluralizations (Ember.Inflector.inflector.irregular('taco', 'tacqi'))
  • sortQueryParams changes how the query params are sorted in the request
  • serializer proxies to the serializer's serialize method.
  • defaultSerializer is for people creating addons who want to specify which serializer to default to.
  • coalesceFindRequests says whether to delegate many find requests to findMany at a time, to save # of network requests. Default true.
  • findMany finds many specific records based on the IDs given.
  • groupRecordsForFindMany is used to determine how to group the IDs given to findMany
  • generateIdForRecord generates a (hopefully) unique ID for the record, should you (unwisely) want to generate those cliest-side.


Two episodes ago, we looked at the most common ways to customize the RESTAdapter, and by extension the JSONAPIAdapter. In the last episode, we looked at some of the core methods like buildURL, or the private method ajax, and what those do and how those are called by things like createRecord and deleteRecord, and how they call out to things like urlForCreateRecord and all the other urlFor methods.

In this episode, we’re looking at the other miscellaneous methods that we can customize, such as the shouldReload methods, sorting query params, and others.

We’ll start with the shouldReload methods. So we have four of them, shouldBackgroundReloadAll, shouldBackgroundReloadRecord, shouldReloadAll, and shouldReloadRecord. Now all in record are the modifiers that do pretty much what you think they should. ‘All’ is when you’re finding an array, all of a certain type, and ‘record’ is when you’re finding just one record.

But what’s the difference between ‘reload’ and ‘background reload’? So the reload methods, they check basically to see whether it should reload every time a record is requested. And so if it’s true, then it will always go back and reload the record and it will wait while it’s doing that. If it’s false, then it will return immediately if it has a cached record.

If I was renaming this, I would rename it ignoresCacheRecord, and I would rename this ignoresCacheAll, because that’s essentially what you’re deciding, is whether it’s going to ignore the cache.

The ‘background reload’ is basically asking whether it reloads at all. So if you have true for ignoresCache, then it’s always going to reload, even before it returns something. But here it’s asking, okay, after we’ve returned what’s in the cache, should we go in the background and reload something?

Generally, your answer to this is going to be yes, we should stay up-to-date with the server. I’m not really sure of a situation where we'd want to return false. If you can think of one, please tell me in the comments because that’s interesting.

Now moving on to our next miscellaneous methods. Next, we have serialize, which it just proxies to the serializer’s serialize method, so not much to see here in the default. You can overwrite it or overwrite it and call super if you want it to do more stuff. And then we have defaultSerializer which is more for people who are making add-ons, and if you specify your defaultSerializer, then it’ll automatically do that without the user having to go in and overwrite their application serializer for each one.

An important customization you can do that isn’t directly a method on the adapter is inflections. So you can make a word have an irregular pluralization or an uncountable pluralization. And this is important because when you’re remember pathForType, it calls pluralize. So it’s important that you get the verbs the same as they are on the server. I’ve gotten this to work mostly in our app, so it’s changing it from taco... the plural was previously tacos, just adding an ‘s’, and now it’s tacqi, but there’s an interaction somewhere here where it messes up one of the other models. So somewhere in our app we’ve customized something that broke this. Hopefully that won’t happen in your app.

So back to our methods. We have sortQueryParams which as you’ve noticed, you might’ve noticed, I’ve added some query params to our query, and by default, it sorts them in alphabetical order. However, we can change that. The documentation has a great example of a way that we can change it, so we’ll go ahead and just copy that, and we’ll see that it’s sorting it in reverse alphabetical order. And of course it’s not just alphabetical order of the keys or reverse alphabetical order of the keys. You could do it by the value, by several other things.

The next three come in a trio. The first and one you’re most likely to overwrite is coalesceFindRequests. It is false by default in the RESTAdapter, but if you turn it on to true, then it will group together your findRecord requests and do those in a findMany. And so if you want to find user with an id of 3, user with an id of 5, user with an id of 6, if this is false it will be three separate calls, if it’s true it’s just going to be one call, and that’s obviously better for your load times.

If you decide to turn this to true, then they’re going to be grouped in different ways using groupRecordsForFindMany, and you can decide how those are going to be grouped together based on what your server can handle. And then eventually, it’s going to call findMany.

Finally, the last one we’re going to go over today is generateIdForRecord. And this won’t be used very often. It’s only going to be used if you’re generating the id on the client’s side. And typically what happens is you send your record to the server, and then the server gives it an id, and then when it’s sent back, the client gets that id, and that’s really good because if it’s generated on the client, there’s a much greater chance of there being an id collision with other users. But there could be situations where you need it and generateIdForRecord will help you out in those situations.

Alright. In the past three episodes, we’ve gone over I believe all of these, and hopefully that will help you when you’re trying to make your own adapter or customize the RESTAdapter.

In the final episode on adapters, we’re going to go over the differences between the RESTAdapter and the JSONAPIAdapter. I’ll see you then.

Introduction to Ember Data 2.0

Subscribe to our mailing list