First things first
Let's understand what DRY and WET software principles are.
DRY
DRY - Don't Repeat yourself is a principle of software development that aims to reduce the repetition of software patterns and replace it with abstractions to avoid redundancy.
For example, if you use the following piece of code in 3 separate files. You can extract it to a separate file and use it across all files where they are needed.
// ./login.jsx
const [isLogged, setIsLogin] = useState(false)
const checkUserLogin = () => {
if(jwt.verify(token, 'wrong-secret') setIsLogin(true)
}
WET
The opposite of the DRY principle which stands for varying phrases which pass the same idea
write everything twice
write every time
we enjoy typing
Why is the DRY principle a widely accepted principle?
Maintainability: The biggest benefit of using DRY is maintainability. By having non-repeated code, you only have to maintain the code in a single place. New logic and bug fixes can be made in one place instead of many. This leads to robust and dependable software.
Readability: Since a piece of code follows a single responsibility principle, it becomes easier to read the code.
Reuse: The whole idea behind the DRY principle is to keep a repeated use of code in a chunk for easy reuse and not a duplication of the logic.
Testing: Blocks of code with a single responsibility are easier to test.
Applying DRY principles in react
Each of the topics addressed in this series is aimed at using software principles to keep our code more robust and dry
Component composition: Encourages reuse of components to avoid repetition of logic
Separations of concerns: Separating business logic from the UI for easy reuse, testing and readability
[Abstracting external libraries](Abstracting external libraries in react): External libraries such as
fetchoraxiosused for HTTP calls in components can have a utility class where they are called rather than in every component. This abstracts the components from the external library and allows the reuse of the utility class in other components, thereby keeping the code DRY.
Don't use DRY
The DRY principle is one of the basic principles of clean code, and as you can see from the above section, a lot of software principles are centred around keeping the code DRY and maintainable, but principles are not rules set in stone that you must follow. They are tools for you to go in a good direction. It’s your job to adapt them depending on the situation. And there are cases where using the DRY principle is not a good direction to go.
Premature refactoring
Follow the rule of 3, You shouldn't apply the DRY principle if your business logic doesn't have any duplication yet. Trying to apply DRY to something which is only used in one place can lead to premature generalization.
Unnecessary coupling
If two components have similar code but different logic and knowledge, abstracting them is going to lead to unnecessary coupling.
For instance, your web app checks if the logged-in user is a customer or an admin. Since the check is as simple as checking the userRole, you might be tempted to write a single utility class for them
const Login (userRole) => { let reRoute;
if (userRole === 'admin'){ reRoute = adminDashboard } else { reRoute = customerDashboard } }
The above code is simple enough, but if we wanted to check if the logged-in user is logging in for the first time or not, we would add an extra line of code
const Login (userRole, session) => { let reRoute;
if (userRole === 'admin'){
reRoute = adminDashboard
} else {
if (session.length){
reRoute = customerDashboard
}
reRoute = onboardingScreen
}
} ```
Now if we had extra user roles, we would keep on adding extra logic checks to the function. In a bid to lump all of the logic functions together. In this instance, it is better to keep the login functionality for different roles separate.
DRY doesn't mean “don’t copy-and-paste lines of source.” DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways. - The Pragmatic Programmer, 20th-anniversary edition, the same book which coined the DRY principle.
- Is it testable?
Ideally, your functions should be predictable and testable. If your abstraction is not as easy to test then you most likely have too many abstractions
Finally, the principles of DRY are simple and essential for clean code, but principles are not rules set in stone that you must follow. They are tools for you to go in a good direction. It’s your job to adapt them depending on the situation.
🍵 Happy coding