Lessons learned from the mistakes I made

If you are thinking that it’s another article on some random dude’s random mistakes while working with a ‘not so random’ JS library, then you are absolutely right. But mistakes, no matter how silly or small, are still ‘mistakes’ and if sharing them here can save some other random dude’s time and energy, then they should be shared with the awesome JS community :sunglasses:.

As this beautiful quote by Otto Von Bismarck says:

Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.

So I present‘5 point someone’ what not to dowith a React JS project:

1. Not using ‘must-have’ third party libraries:

The first mistake is not using important third party libraries which could have made the work so easy if we have used those earlier.

There are some third-party libraries that should be included in the project from the beginning itself. They make the developer’s job easy, and thankfully, the React community has provided us with many such libraries :innocent:, we just have to use them accordingly.

For example, Handling forms in react is already a pain and on top of it adding more functionalities like handling validations, showing validation and error messages, handling form submissions is like a living nightmare for the developer. But thankfully there is one awesome library called Formik , which does all of it and much more. It would have been easy for us if we have included it from the beginning.

2. Not splitting the code into smaller chucks:

React is built on the philosophy of reusable components. If there are any few lines in the code that are repeating and they can be written as a separate component, they should be written as it. It will make the code more maintainable and more reusable and will increase the overall code quality.

But we did the mistake of not exactly following this philosophy and hence not leveraging the full power of React.

3. Not maintaining consistency and not giving enough time to refactor the codebase:

I think there are two main factors affecting the quality and consistency of the codebase:

The first one is time . Somedays there will be too much work and too little time to complete it. There will be times when you can’t find the most efficient solutions for every problem because of the time limit OR you can’t maintain the consistency of the codebase because of the deadlines and you have to settle up for less efficient and inconsistent solution.

And the second one is the people . When multiple developers are working on the same project, there is a high chance that there will be a drop in the consistency and the code quality of the project if there is not any proper way of doing things.

So it's very important from the beginning itself to refactor the codebase and it was our third mistake to not taking care of it. We could have created some code guidelines for new developers to get a gist of the codebase before starting the coding, which could have saved everyone's time.

4. Not setting up linter before working in a team:

One solution of the consistency problem can be to set up a linter like ESLint with some pre-defined set of rules. A linter is a tool that can check that the given code is following some set of rules before it is merged in the main codebase.

Not using the linter from the beginning created one big issue ‘ merge-conflicts ’, when one by one, multiple developers got involved with the project. Most of the time they were not that big and didn’t take much time to resolve but we did waste time and energy to do something which could easily be handled by a tool.

5. Not wrapping third party components:

And the last mistake was not wrapping the third party components into a custom component. Which, then should be used in the codebase.

This one is really important.

For example, there is an npm package for formatting number inputs called ‘ react-number-format ’. We used it more than 100 times on different pages by importing it from node_modules directly, but it happened many times that the requirement changed for the number inputs and than we’ve to manually change it more than 100 places.

Alternately if we could have just wrapped it in a custom component, we only have to change that custom component when any requirement changes.