This lesson is part of a series on building a robust modeling layer in your AngularJS applications.
Hey, everyone. The next step we're going to talk about today in our modeling library is serialization and deserialization.
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.
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?
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 post.author. 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 post.author." 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.
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.