Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Serializing and Deserializing Data Models in AngularJS

    Brett CassetteBrett Cassette

    It is important to have consistent data for your application to use. To achieve this, our modeling library will need to have the ability to serialize and deserialize data received into a format it understands, plain old JavaScript objects.

    This lesson is part of a series on building a robust modeling layer in your AngularJS applications.



    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson




    Man 1: Hey, everyone. The next step we're going to talk about today in our modeling library is serialization and deserialization.

    Deserialization is where we're going to get a response from our API, such as this bit of XML here if we have an XML API. What we want to do is actually transform this into a JavaScript object so that we can work with it in our JavaScript application.

    Serialization is the inverse operation. We're going to have our JavaScript application. When we want to save it, we need to transform it into XML so that our API knows how to read it.

    We have these gateways that sit at the edges of our application that perform this serialization and deserialization for us. This is an important part of the modeling library's responsibilities.

    Let's take a look at how this works here. We've exposed a configuration option on our API here which allows us to configure the format of the API. We'll actually be allowed to be even more specific here and give a fully qualified mimetype. We can see the differences between giving that MIME type and just giving this basic XML in a moment.

    We just want to see what happens when we run deserialize on this bit of XML here. Let's take a look.

    What we get is a bit of JSON. It's wrapped under this post object. We get all of the attributes for the post then underneath that.

    This is a common response that we're going to get from a back end where we have an object that's wrapped under a root element.

    We also have a configuration option for this that says we want to unwrap the root element here. The difference then is we get the attributes on the model.

    This is exactly what we want. We want to, by the time we've handed this off to the application, to have just deserialized to the attributes that we're interested in for our model.

    If you're paying really close attention you'll also notice that we've transformed to author ID here from the author association that was listed. We're going to take a look in a little bit at how we do that. Just hold on to that thought for a moment.

    What actually happens when we call deserialize? Well, there's really not that much code centered around it. It all fits on the screen right now.

    We have two events that fire, one before and one after we deserialize. This allows the rest of our application to hook into events. If we wanted to, say, post...Remember we're deserializing posts so if we want to say post.before deserialize we can run a function with the callback and get the XML object here if we wanted to do something with it before deserialization at any point in the application.

    Then we deal with the case where we didn't actually get any response from the API and we sent that to an empty object just so we're always sure we have some JavaScript type thing.

    Then there are actually two methods that run to allow us to deserialize from one format into a plain JavaScript object.

    The first one that runs is the mimetype parsing option. Let's say that we've been given our XML here. This is just pseudocode, right?

    If we have a post with an ID of 1, and this is what we receive we want to first make sure we transform that into a JavaScript object. The reason that we're interested in transforming this into a JavaScript object first is so that the rest of our functions can know that they will always have a JavaScript object as input.

    It's much easier to work with than getting XML, sometimes getting JSON. We want to make sure that we always have something consistent for the rest of our application to work with. We really have this gateway set up here to make sure that nothing passes into the application unless it's a JavaScript object.

    We run that first. Then we run the unwrap root function if that happens to be set on the API. Then we run a special function that is defined on the model. It's called "parse." If there is a parse function we'll run through that. If there's no parse function, we won't bother with it.

    This parse function allows every single model to define very specific ways to deserialize data. In this case, remember we had We saw that we had transformed that author into an author ID here. This is how it happened.

    It's because we got this author object and then we saw that on our parse method. We said, "Grab the ID from that author and make that post.authorID and then delete" At the end of this function we just return the post itself.

    We return that JSON object with the author ID. This allows us to both transform from the XML format and then, also, perform any little additional transformations that we want to before our application actually ends up receiving the data.

    I really want to make a big point here about deserialization happening at the edges of our application. Our application never even knows that it interacts with XML data because whenever it receives HTTP responses all of our HTTP responses are piped through this response handler.

    We don't need to worry about most of this handler here, but if we come down here if we've determined we have a successful response, we didn't get a 400 or a 500 response. We got something in the 200 range then we're going to run through the response resolver.

    The first thing that the response resolver does is call class.deserialize. It receives this response data and it runs through the deserialization method. The response that the application thinks that it receives is actually this deserialized data.

    We never have anything but plain old JavaScript objects that come into the application.

    I want to show you the same thing is true when we go ahead and save data. Whether we're sending a put or a post, we always send the instance, running it through the serialize method which we talked about being the inverse of the deserialize method.

    To show you how similar the serialize method is, it is the exact inverse of the deserialize method. The first thing that it does is run through our model specific format method. This is the inverse of our parse method. This transforms it back into something that the back end wants to see.

    Then we rewrap the root if we need to. Finally, we call mimetype.format. We see we have parsers parse data that comes in and then formaters format data that goes out to our application. Then we return the serialized data to send to the API.

    To recap what we've learned today, we've learned that deserializers transform the data that comes in from out back end responses into JSON and that serializers transform our JSON objects into the back end format that our back end expects.

    These occur at the edges of our application so that the rest of our modeling library doesn't even need to know that they occur. We can swap in and out model formats as we please without changing the way that rest of our application functions.