In this blog, I’d be explaining few best practices when working with React/React-Native or any other javascript application. Following are the guidelines will not only reduce the pitfalls but can also make your code more scalable.
Disclaimer: This is an opinionated guide. Decide what works for you and your team and stick with those policies.
Let’s discuss these practices one by one.
TL;DR
Testing, Typescript and Linting.
Testing.
That’s it! There I have said it. Test your WIP (Work In Progress) as much and strictly as you can. If your code is test passed, you are almost there. Do not bypass your work from the testing. Yes, I know you have already heard it like zillionth time but let me write the tools for testing for you.
Jest
The javascript testing framework backed by Facebook, Inc. It is a de-facto standard when it comes to testing JavaScript applications. Works with the project using: Node, Typescript, React, Angular, Bable and more.
Enzyme and/or react-testing-library
It is a powerful tool for Integration testing. Unit tests on their own don’t guarantee that your app will work even if those tests pass because the relationship between the units might be wrong. You should test different features with integration tests.
Cypress
Cypress is an end-to-end testing tool. It enables you to write unit tests and integration tests too. These tests are usually run on the entire application.
"Fast, easy and reliable testing for anything that runs in a browser.”
Linting.
Your test passed codebase can still be a pain for the other developers. If a codebase does not follow strict coding standard guidelines — it will directly impact its scalability. Scalable code is as important as bug-free and tested code. ESLint lets you put uniform, standard coding guidelines. The project should follow one and only one standard protocol. For more details, please check my blog on ESLint.
Typescript.
TypeScript is a strongly typed programming language that builds on JavaScript giving you better tooling at any scale. TypeScript adds additional syntax to JavaScript to support a tighter integration with your editor. Catch errors early in your editor. Using Typescript in trivial applications is often looked like little over the top. However, if your project is medium to large scale you should consider developing it in Typescript.
While Typescripting, Testing and Linting cover the major part following are few other practices that you can follow:
Libraries
With the npm, you have thousands of third party libraries at your hand that you can use. But you should be cautious of the third parties you are adding to your project. In general, the more third parties you add, the more control you lose over your project, the bulkier it gets. Here are few rules to help you out.
- Check how often the dependency gets updated or maintained. You can visit the Github repository and check the open issues and the recent activities.
- You can check the weekly downloads. It gives you a brief idea about the popularity of that dependency.
- Make sure the dependency you are adding is backed by the authentic contributor(s).
- You should also consider checking the unpacked size, last published date.
Strict CI/CD
It is needless to say. You should set up the CI/CD that runs all the test cases, lint scripts. Feel free to set up the lenient CI/CD if you want bugs to enter in your production. Consider using Github actions or CircleCI. Every time someone merges or pushes their changes into the main branch there should be an action that runs all the test scenarios and lint scripts beforehand.
Comments
Do you think your piece of code requires commenting for better understanding? Chances are, you are right. Write comments when and where it is necessary. However, you should consider few important things:
- Update your comment(s) when required.
- Feel free to mention Tickets ID for reference in the comment.
- Do not write unnecessary comments. For example:
// assigning 10 to the x
let x = 10;
Code Refactoring & maintaining the docs
They say that the first rule of programming is,
“dOn’T tOuCh If iT’s wOrKiNG!”
I don’t want to sound rude but, I do not believe this. I believe — improve it if it can be improved. Optimize if it can be optimised. With the luxury of having a version control system, I wouldn’t even mind experimenting with it. You should consider your codebase refactoring every once in a while. Monthly if not weekly.
Contribute? Found a mistake?
Feel free to connect with me, I’d love to hear from you! Thanks for reading.
Top comments (3)
I completely disagree respectfully. If something works, and really works, do not change it. That's when you will lose hours with something that was already working.
Polishing a diamond won't bring up its value.
Hi Uriel, thanks for letting me know your opinion. Like I said it's opinionated. But again, code refactoring isn't loosing hours.
And yes, many Diamonds requires polishing every once in a while!
Maybe the thing is not Diamond, we can do this in free time. Give back, only if one is interested.