Write Better Code in React
There’s a saying that programming is divided into two. Programming and good programming. Programming is what we’ve all been doing as a programmer. We all write our code with just one goal in mind. For it to work.
While good programming is not just making the code works, it also pays attention to the little things. Like how the structure of the code, naming the function, etc.
This is where a good programmer applies what is called clean code.
What is Clean Code you say?
So you see, it is merely not enough if you finish your development faster. If others cannot comprehend a single line of your code, it will only cause another tech debt.
Your code is classified as “clean” if it can be understood easily by everyone on the team. Clean code can also be read and enhanced by a developer other than its original author.
With understandability comes readability, changeability, extensibility, and maintainability.
Now, I will share my experience writing clean code on my current project “Document Builder” for PPL course using React.
Readability Through Expressive Variable/Function Names
First, let’s talk about names. Everything in an application has a name. They communicate what your code wants to do to the developers who read your code. Choosing good names to use makes your code seems like a piece of cake to read for other developers, as well as yourself in the future.
In React, we use Camel Case variable naming, so it is better to follow the best practice. Keep in mind, when writing Variable Names, it is better to name them using object names. And, please, never write a variable name with a single character, unless it is an iterator variable.
We can see the snippet of code above is used to describe the variables of table heading where it contains — you guessed it — every attribute of a list table. Try to give a meaningful name to a variable so your mate or even yourself gets the idea what is the variable’s purpose.
On the other hand, writing Function Names is better using verb names. It is just a lot clearer to notice it as a function when we know the first word is a verb.
In this segment of code, we know that every function above does its own thing based on the function’s name that’s stated. For example, I want to make a function that could set open the drawer. So, to name a function, simply name it like what it would do according to its behavior, which is handleDrawerOpen. This would help anyone who sees the code to understand each function’s purpose without the need to read the implementation.
Constants File to Your React Project
As I’ve been building Document Builder over the last few weeks, I’ve started to make the transition from making code that simply works to focusing on how I can make my project structure as clean and as to understand as possible.
Beyond just basic things like naming variables as clearly as possible, something I’ve been doing recently to clean up each component is to shift all of my constants to their own section of the project.
Why bother?
Let’s just take a look at what one of my elements looked like before my changes:
…versus now:
I think it goes beyond saying that Option #2 is a lot easier to read and that the code that is present allows users who are trying to understand what is going on to focus on what is actually being done within the lifecycle of that specific component as opposed to trying to make sense of the constants that are defined.
To get started, I made a file called menuConstant.js in a folder called “client/constants”. This folder holds all of the constants files we use within all of our project’s components. At this point, the inside of menuConstant file is looking like this:
Next, I want to use the constants I’ve made before in Header component. In order to accomplish that, I imported the desired constants to the Header component file like:
Then, I made a variable that executes getSideBarMenu function that returns SIDE_BAR_MENU_ITEMS_ADMIN or SIDE_BAR_MENU_ITEMS_USER constant based on the role of the current user who’s using the application.
const menu = getSideBarMenu();Lastly, I use the returned constant in implementing List Tag (Option #2) as you can see before.
Breaking out your constants is an amazing way to make your project clearer to those reading through your code, while simultaneously cutting down on unneeded repetition of constants from component to component. It’s been extremely helpful for me and I highly recommend everyone add it to their projects as soon as possible if they don’t have it included already.
Don’t Repeat Yourself (DRY)
Writing duplicate codes is not the best way in developing a program. It will make your code looks dumb by copying the same code over and over again. Instead, we could make it simple by writing it only once and import it or call it whenever we want to reuse it.
This kind of implementation can be seen when I’m developing a HistoryDocumentPage container. HistoryDocumentPage contains a list table that looks similar in UI like TemplateListPage, only some buttons and logics are different.
What I did here is to make ListTable and ListRow components so that they share reusable for HistoryDocumentPage.
After implementing ListTable and ListRow components separately, I use them both but give each TemplateListPage and HistoryDocumentPage containers their own space to handle their own business logic. Now, they go something like:
In my opinion, writing code is just like writing a storybook. We need to present the story in a clear way and attractive for others to read. If you write it carelessly, people might find it unreadable and not inspiring.
Thank you for reading, I hope it was useful!
