Rockstar Lifecycle, Might Not Make It — Beginners guide Serializers in React

Data is complicated. often times it can seem like data is complicated just for the sake of being complicated. today were going to learn about an Active record tool to help us all make it just a little bit less complicated

Todays were going to be learning about how to best leverage the Active Record tools to order and organize your information. more specifically. were going to be learning about Serializers.

Lets pertend for a min that im working on a group project. My partner and i just created the login functionality, we realized that we needed to find a way to select specific information for the logged in user in various instances. We dont know what to do. are we going to have to write a bunch of filters and pass all the information everywher? or… is there a betterway?

We needed to create a Rails backend API that we wanted to be able to interact with a JavaScript frontend (if you are not familiar with API’s, it would be beneficial to read the information here before continuing). We began by seeding our database with user objects, post objects, and comment objects. Here is a basic diagram illustrating the relationships between each object:

Add the following :

gem ‘active_model_serializers’

run ‘bundle install’

Seems simple enough. The instance of a user (whoever is signed in) can leave both questions and comments. questions can receive many comments from different users (including the user who created the original post). This can all be seen and rendered to the DOM in real time, without refreshing the page, on the frontend. But every time a user creates a post or a comment, every time a post receives a comment, all of this data needs to be persisted and stored. The seeded data is already persisted and stored in the Rails API, but when a new user creates an account how is that information remembered? Where is that data stored and how is it persisted. And you’re probably thinking, well…through the API. Obviously.

You’re exactly right! And the API is storing and persisting the data from our seed file. But we can’t just manually put all of this new information into our seed file and then re-seed our database. Every time a user or a post or a comment is created in the frontend, it needs to be persisted and stored in the backend so it can be remembered and utilized wherever and whenever it is needed. Not only do all these new objects need to be stored in the API, they need to be associated properly. You’d think that the models accomplish this. And they do, to an extent. In our application, we wanted to give the user the ability to see all the questions that they’ve answered and created.

In the Rails server, to see what user posted what post/comment, you could simply use dot notation (user_obj.posts →[{post_obj1}, {post_obj2}, {post_obj3}, …]). But the association could not be done this way in our JavaScript the frontend. So what are our options?

Well, the first option (and, unfortunately, our first course of action) is to try to handle these associations in the frontend. Basically using JavaScript functions to read the information of the objects fetched from the APIs, then from that tie it to an existing object (or send a post request to our API to store the data, get that information back using a get request, then associate the newly added object with other pre-existing or newly created objects). It sounds confusing. Because it is. First of all, making that many requests for simply associating objects is inefficient and redundant. On top of that, these methods would ended up being dozens of lines long

The serializer facilitates a relationship that is created in the backend and then translates it to the frontend. Cool. But how? What exactly does it do?

After implementing the serializer, our logged in user API looked something like this (pay to mind to our early seed data):

As you can see, after using the serializer, we not only have the User object, but we have added the keys “comments” which points to a value which is an array containing all post objects created by that user.

We ALSO have added a “submitted_questions” key that points to an array value containing all of the comment objects created by that user.

This makes our life in the frontend so much easier because all we need to do now is use dot notation in whatever function we use to append the new or render the existing data to the DOM. This is pretty incredible considering we don’t have write any additional functionality to associate the user and their post/comment (and establish that association each individual time a user posts or comments on a post). We also don’t have to make any additional fetch requests to the API (other than the post request upon creating a new object or the initial get request that pulls the saved data and appends it to the DOM when the page first loads).

how does the Serializer work?

You would make a serializer to accompany all of your models with all the attributes required by the client (the params for the class instance). Then you need to include (embed) the relationships. And much like the associations written in the models, you can have has_many or belongs_to written in the serializer itself (in the serializer, belongs_to can also be represented by has_one). There are many uses for serializers but the use that pertains to our project was the creation of nested JSON data.

The goal for this function is to be able to write comment_obj.username in a JavaScript function (in our frontend) and access the username of the user who wrote the comment or post. This suits our situation perfectly! With some additional functionality in the Comment Serializer we can be picky about not only what data we are retrieving, but how we are retrieving it. And guess what?

None of this had to be done in the front end.