Skip to main content

Deserialization in Ember Data (CLI edition May 2015)


I was working on a side project to learn Ember JS recently and hit a major roadblock with deserializing data from a REST API. I have a model that looks like this:


Ember therefore expects a JSON payload that looks like this:
However, the API (from Kimono) actually returns a payload with the people array embedded within a results array:
I spent hours trying to figure out how to use the deserialize methods to extract the people array from the results array. What frustrated me was that I couldn't really find any examples of how to use the deserialize methods. Maybe it's super basic for most people but I'm an Ember noob and couldn't figure it out for ages.
To help you avoid my teeth gnashing, here's the code I wrote for my serializer.
To explain what's going on here, we have to override a few methods: extractSingle (if there's only one person returned), extractArray (if you used findAll) and normalizeHash (used by both of the two previous methods).
extractSingle and extractArray are frustratingly simple. To look at them, you'd think it took me 5 minutes to write the code not 4 hours hahaha! Hopefully you'll find it super easy to write deserializers now.
The key things to note are that you can delete elements from the payload, e.g. delete payload.results; In this case, I completely overrode the payload as the only thing that I needed was the people array.
Something else to be mindful of is that if the API has different variable names to your model, you can add a new variable name to the hash (e.g. hash.fullName = hash.name;) and then delete the old variables.
It does seem to be relatively important to clean up unused variable names because otherwise Ember warns you about variables that aren't found in the model. It won't break your application but it does make your console messier than it needs to be.
Hope this little guide helps! Let me know if you have any questions.

Comments

Popular posts from this blog

Getting current time in a specified timezone using Deluge script

Recently I was working on a custom function for Zoho CRM which required me to get the current time in a specified timezone. I assumed that zoho.currenttime would give me the time based on the timezone chosen in the organisation settings but discovered that it always gives it to you in PST. The Zoho Partner team gave me this snippet to solve the problem: current_time_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", "Australia/Sydney").toTime("yyyy-MM-dd'T'HH:mm:ss"); If you need the current date, do: current_date_in_timezone = zoho.currenttime.toString("yyyy-MM-dd'T'HH:mm:ss", timezone).toDate(); To figure out what you can put in for the timezone part, refer to https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

searchRecords with multiple criteria in Zoho CRM API

NB: this blog post is no longer relevant as API v2 lets you use searchRecords with multiple criteria :) I discovered something really cool tucked away in the Zoho CRM forums today. For the history, check out this thread . In summary, the searchRecords API task in Zoho CRM is impossible to use if you have multiple criteria and in general it's pretty annoying to get the single criterion right. In the forum thread, Zoho Support advised that you can actually use getRecords with a view name. This feature is not documented on the getRecords page at all but I can confirm it works:D This is really, really cool. It's going to make my life as a Zoho dev much easier! Instead of having to do something really inefficient and ugly like: leadRecords = zoho.crm.searchRecords("Leads","(Created Time|<|" + yesterday_date +")",fromIndex,toIndex); for each ele in leadRecords { lead_source = ele.get("Lead Source"); createTime=(ele.g

Debugging Deluge script in Zoho Creator/Zoho CRM

Deluge is a powerful language that simplifies a ton of things, e.g. database lookups. But I have to say, it's very painful to debug. Interpreting longish scripts takes ages, error messages are obtuse if they exist at all and even the hints in the IDE don't always help (ever tried using containsIgnoreCase based on the auto-complete suggestion?). Here are my tips for debugging code when it's not working. 1. Split your code up into small custom functions. Nothing's more painful than waiting 30 seconds for a really long (say 1000 lines) HTML page to save and only then get feedback on a syntax error. I've got a few apps that are like this and it's not fun to work with at all. I haven't seen any improvements in the compile speed over the last few years, so my conclusion is that it's always best to write most of your logic code as small custom functions and then build that up in the HTML page so that you'll get quick feedback on syntax errors. 2. If