If you want to write a better React code, you should always remember what Ernest Hemingway said:
“The first draft of anything is shit”
And even if this guy had nothing to do with React development, or even Commodore, he knew exactly that the first creative act, is almost always, not “well-thought-out” and hard to understand by anybody except the author.
Reviewing and rewriting your code will finally make you more sensitive to the many mistakes you do on autopilot, but don’t fall into trap of excellence. Everyone reviews his code, and the top senior developers and top performers are included here in the first place.
I suppose this is a great place to start and as a number one rule:
1. Do not pull request your first drafts
To write a better React code, you need to simply make it better each and every time you write it.
The first draft got probably has more to do with pollution and is too complex to give away to somebody else. Think about it – you are the only one aware of what’s going on in the code. You may have a feeling that others should understand it, but it’s a delusion. [ecko_annotated header=” The first draft” annotation=”is almost never clear to anybody except you”][/ecko_annotated]
To make sure other people can follow your idea, you must be clear. And the first draft is almost never clear to anybody except you. Your role as a better developer is to make things as simple and as clear as possible and remove any inconvenient complexity to the core essence of the code. Whatever can be taken out – take it out.
Even if you think you already succeed, go away from your code and come back again the next day, or after a bit longer while. There is a high chance that the code won’t be so clear anymore even to you and you won’t resist making a few changes.
READY TO START YOUR NEW PROJECT?
2. Lint your React code
Use linting tools.
They are the most basic form of static analysis. They simply run through your code and try to spot potential errors.
If you search for some – here, I will Google it for you.
3. Split your React code into smaller pull requests
Imagine if I merge all the text in this article together to create one big block of letters.
Would you even start reading it? I’m almost sure you won’t. And it is the same with code. If you write your code in one big block it will be hard for others to even start. But if you split it into nice small and easy-to-chew pieces, you save time and trouble both others and yourself.
4. Take care of the naming in your React code
A simple way to improve your code is to name your files based on the role they play in the project. It is an enormous help for others to just look at the file and immediately get an idea of what it should do.
In fact, you should take care of all the naming in your code: files, folders, functions, variables, etc.
5. Type your code with PropTypes or TypeScript
To write a better React code is to write a more readable code with no bugs or typos.
Use TypeScript or PropTypes to do so. Both seem to do the same work, but in fact, they differentiate a bit. Thanks to Type Safety in TypeScript, you can detect errors and typos early on in the development process. While writing the code. It will give you a warning if you pass an argument of the wrong type to your React components.
PropTypes, on the other hand, is better to use if you want to test how the components interact with external data.
Mind the difference between them:
Typescript is validating types at compile time.
PropTypes are checked at runtime.
6. Use React and Redux Dev Tools
From the definition, React Developer Tools lets you inspect the React component hierarchy, including component props and state. Redux DevTools will help you debug the application’s state changes.
Both can be easily installed as a browser extension or as a standalone app.
7. Test To Avoid QA driven Development
[ecko_annotated header=”Test your code so well” annotation=”to keep the QA tester unemployed. “][/ecko_annotated]
An important and useful tip is to always remember to test the changes you made. Yourself.
Make sure you know exactly how they affect the rest of the app, and are not making your app more complex than necessary. It is tempting to push the code to the QA, but your goal should be to not use his help at all. Try to test the code so well that QA can get unemployed. Literally.
8. Become friends with Google and Stack Overflow
Many answers to your code questions can be easily found online. I’m almost sure someone had the same problem before and shared his experience somewhere on the internet already.
If not, you can easily start a conversation and get a quick answer on Google, or Stack Overflow, so don’t be afraid if something seems too hard. You have a world of help.
9. Extra tip: plan it!
This should be number one, but it would destroy my welcoming Hemingway quote that I’m proud of.
Besides that (brutal, but true), not many developers actually plan their work, so you raise your chances to execute way much better code than them.
Make a mockup and think a few times about how are you about to approach it. Plan all the components as single UI elements. Don’t “just type and go”. Plan it. It will help you keep the code less complex, which is probably the most important thing here.
We will write more about planning in the future, so stay tuned.
10. Summary
Coding has a lot to do with brain work. And brain prefers the lazy approach to stay away from any trouble and effort, and does not abuse the energy levels in case of serious danger.
The thing here is, there is no danger nowadays to keep the energy level for, yet we inherited this (somewhat useless) approach from our ancestors.
This is our mind’s default setting, and just by learning how to resist it, we can dramatically improve not only our code quality but the quality of our work and life.
This is why writing clean code doesn’t require much technical knowledge, but more of discipline.
