This is a technical retrospective on the decisions made when developing different aspects of NodeFlair’s product. This is done to hopefully make better decisions down the road. In this case, it was NodeFlair’s revamped on-boarding form that is in question, when we were planning for a review page.
In Software Engineering, the DRY principle aims at reducing repetition of code.
Let’s say for example, we have the following class Structure:
We have a class called Animal and we have a class called Dog which is a child class of Animal. As we know Dog is-a Animal, it is not really necessary to repeat the attributes and methods of Animal into Dog!
Duplication in logic should be eliminated. It suggests that by copy and pasting duplicate logic, the code writer does not have a good understanding of how the code comes into play and a poor understanding of abstraction. Unnecessary code to a code base results in an unnecessary increase in the amount work needed to maintain the code base and create additional tests just to handle the presence of these duplicate code.
For NodeFlair’s revamped on-boarding form, it did not have a review page initially.
We can express the original on-boarding form logic as a state machines as shown in Figure 1.
However, there is an issue that users would not be able to see all their details on one entire page. Hence, the need for the review page to enhance the user’s journey.
With the addition of the review page, we can have additional states which helps redirect the user to the page which the user has components he or she wishes to edit.
From Figure 2, the logic of pages should be as follows:
As a result, we would need to modify the buttons such that Next should not appear, which redirects the user to the next page. Instead, it’s replaced by another button Back To Review which returns the user to the review page.
⚠️ What you would see below is pretty bad.
However, it is a good learning experience to enforce good Software Engineering principles.
I had decided to replicate the jsx component for each page into a new page with a modified BottomComponent with the new button.
However, this results in a huge amount of repeated code, which is actually unnecessary. It is not really wise to handle such a practice.
As a result, we could actually just modify the BottomComponent and create a new component called ReviewBottomComponent which handles the state logic from Figure 2. As a result, we do not actually need to create 4 new pages just to handle the review state logic! It saves time and effort while following the principle of not repeating oneself.
Do not rush into things. Just because some ways seem faster and more convenient, it does not indicate that we should forgo our good software engineering practices. In this article, I made the mistake of just repeating the code used for all 4 pages and making 4 new pages just for the sole purpose of creating a new BottomComponent.
As much as possible, if there is already a child component in the parent component which handles that particular set of logic, we should make use of it as much as possible. In this case, our Page has-a BottomComponent. As a result, we can just make use of the BottomComponent and create an alternative ReviewBottomComponent to handle the review state logic.
If our Page does not have a BottomComponent, we should take responsibility by abstracting out the code such that we have create a component with similar functionality to that of a BottomComponent. From there, we can follow what we did in the earlier paragraph.
Nope. It does not make sense to repeat so much code just for a simple purpose. Please do remember to plan before coding!
Join the smarter way. Discover upfront real salary data backed by payslips and offer letters.
Join the growing community of 800+ tech talents who have already submitted their salary data. Put an end to salary opaqueness here in Singapore!
Follow us on Telegram (@nodeflairsg) for the latest Tech Insight, Reads, Salaries & Job Opportunities!
