Filter Architecture In Your Front-end Project
When you’re working on a medium-to-large scale project, you probably need to handle many API requests and response. You send a request body to the backend server, and the server returns back the response. This is a very common way of fetching data.
During this process, sometimes you will notice that the returned response might contain unnecessary data, and the data format doesn’t compatible or align with your front-end project standard. For example, mismatched parameter keys, non-identical naming convention, different object format etc. While all these “unfiltered” data gonna becomes an unintentional culprit that creates bugs and increase your technical debt.
In this case, usually you will spend time keep debugging and fixing it until your component displays the response correctly. But, have you thought about WHY? Why all these bugs will happen? Why you’re the one who keeps dealing with it?
If you’ve already have a set of code standard in your front-end project, means you have a guideline to follow. You can prevent the API responses from messing up with your codes.
Alright, imagine you’re the lord of the land, and you set up a checkpoint at the gate of the city. You need to know who is passing through the city, and they can come in only with certain rights and permission.
So, here’s comes the Filter Architecture. It acts as a middle-net that stays between the process of requesting & fetching API response. Basically, you will modify your request and response body, can also call it as payload, during the data fetching process.
When the server returns the response data, you will filter the original API data according to your requirement. After that, stores the formatted data into your Redux or any other state management place on your project.
As a reminder, Filter it before storing.
For example, you’re using camelCase as the keys you front-end payload, but the back-end receives snack_caseas the keys. Then, in this case, you gonna format your payload by renaming the keys in order to match the back-end requirement. You may consider creating a global function that performs this logic change. Vice-versa, this same goes to the returned API response as well. You can convert the key names in the response and make it to match with your front-end standard. Thus, your front end code will always keep its standard for better maintainability, easier debugging & lesser bugs.
On top of that, you can also filter out the unnecessary data when you received the returned response from the API. For example, you have a section that consists of multiple cards that displays books information in your page. Each card will will only display the book’s name, cover, author and publisher. However, the API returns redundancy information like a service bean, author’s notes, publisher’s notes, etc. All these unneeded info can be filtered out & re-format before passing it to your card components.
Tips on Filtering
Let’s take the book infos (mentioned above) as a demo case. Below is an example of renaming keys and removing unwanted data inside the book array using map() :
In the example above, you can see that I only take the data needed for my card components. And then, I use get() to retrieve the value from the original array. Here’s how’s get() works:
get(object, 'your object path, can be nested one', 'fallback value')If the API data passes back empty value in any of the keys above, it will use the fallback value that I assigned by default. I assigned an empty string here. You may assign any default fallback value according to your need. This method helps reducing bugs & errors if you use it wisely. For more information, you can read the official docs of Lodash.
Thanks for reading! Do give me some claps if you find this article helpful! Happy coding & Cheers!
