PPL 2020 — Document Builder: Writing Cleaner Code in React
This post is written as a part of individual review criteria of Fasilkom UI’s software engineering project course: PPL 2020
I think a clean codebase is like a good textbook. When people use a textbook as a reference when doing paperwork or homework, most of the time they do not start from chapter 1. When we do a numerical analysis homework on the topic of LU Factorization, for instance, we look immediately for the chapter that explains it. Most people don’t start from the preface.
A good textbook is easy to understand and can lead us to the right chapter or part of the book when we need it. So is clean code. When we work in a team, be it a big or small team, our code is meant to be read by others. Plus, our code is meant to be extended, modified, or fixed by others. Other than being readable, clean code is something that your teammate can smile at upon modifying/extending it. Wouldn’t it be nice when people heave a sigh of relief when seeing code written by you because they understand it well and they don’t have to do a lot of work modifying it?
Building Document Builder in the Software Engineering course (PPL) is not my first experience with React. I have worked on multiple projects before and have experienced many things. I’ve experienced trying to understand complex code structures designed by others, I’ve been amazed by the simplicity that I can enjoy because of a very mature React codebase, and I’ve experienced trying to explain my “dirty” code to others because I was too lazy to refactor it.
From those experiences, I tried several things to implement clean code in our React codebase in the Document Builder project for the PPL course.
Build UI Kit Early
A lot of people hate writing CSS.
I state this based on my experience working with others. Different people have a different way and a different standard in writing CSS. Some people like the concept of flexbox, some people like to position: absolute everything (WARNING: not recommended). Based on my experience contributing to multiple frontend services, most of the dirty code is located in the styling (I’ve nearly cried during one of my previous internships because the previous engineer add !important in a lot of the CSS).
But when we build our software, we want to be consistent. This problem has been solved by a lot of CSS frameworks out there. However, what if we want to build something that’s customizable and unique to our brand? I learned the concept of building UI Kits from one of my previous software engineering internships.
An example of a very highly used component in any user interface is the button. When we standardize the styling and use cases of a button, when it needed to change, we only need to do one code change for all of the buttons we use.
The next most used thing in styling is colors. Try to prevent defining the hex manually for everything that you’re styling and use a defined global theme instead. This has become very rewarding for our team because when the client gave feedback on our button color on the first sprint review, it was extremely simple to modify it.
Don’t Repeat Yourself (DRY), But Don’t Overdo It (DOI)
Maximize any non-specific component to be reused by others, but do not do the same for containers. To unify the definitions here, a component is a UI unit that does not have any business logic in them. Buttons, Modals, and Cards are some examples of components. Containers, on the other hand, have business logic and usually, API calls in them. Examples of containers are SignUpPage, LoginPage, DocumentListPage.
I know that it is very tempting for instance, to reuse the container CreateTemplatePage to also handle editing templates since they show almost exactly the same thing, only some buttons and logic are different.
But conditional business logic, in my opinion, is a recipe for going nuts. Trust me, I’ve been there. Instead, what we can do is to make any UI component that they share reusable, and leave the business logic and anything that’s different for each container to handle.
These two previews of two files of code, although not perfectly clean yet, is an example of our effort in implementing DRY and DOI. We use the same UI form component TemplateContent, but give each CreateTemplatePage and EditTemplatePage their own space to handle their own business logic.
I think these two tips are something that I can share about the clean code implementation to React that our team is implementing. Feedback or any other opinions are very much anticipated and appreciated!
Thank you for reading, I hope it was useful.
