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 (
- 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
deleteRecord, and how they call out to things like
urlForCreateRecord and all the other
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,
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
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.
- Ember Data 2.0-Getting Started, and Basics of DS.Model
- Ember Data 2.0-Getting Data from the Server with findRecord and findAll
- Ember Data 2.0-Store Manipulation with Peek, Unload, and More
- Ember Data 2.0-Create, Save, and Destroy Records
- Ember Data 2.0-Updating Data, Tracking Changes, and Rolling Them Back
- Ember Data 2.0-Metaprogramming with DS.Model Attributes Property
- Ember Data 2.0-Model States and Flags
- Ember Data 2.0-states.js Deep Dive
- Ember Data 2.0-Relationships
- Ember Data 2.0-Metaprogramming with Relationships
- Ember Data 2.0-Overview of using Adapters and Serializers
- Ember Data 2.0-Overview of Customizing Adapters and Serializers
- Ember Data 2.0-Essential Adapter Customizations
- Ember Data 2.0-Advanced Adapter Customizations
- Ember Data 2.0-Miscellaneous Adapter Customizations
- RESTAdapter vs JSONAPIAdapter vs ActiveModelAdapter
- Introduction to Serializers
- JSON API
- Serializers-How are normalize and normalizeResponse different?
- Serializers-Extracting Attributes and IDs
- Serializers-Extracting Relationships
- Serializers-keyForAttribute and keyForRelationship