Must-Have Weapons in Your React Armory
Tags: react, javascript, webdev, tooling
Published: 2021-09-13 05:48:48

Weapons (tools) make a soldier (developer) effective. Advanced and effective weapons (tools) in your armory ensure you have the firepower to handle the complexity of an ever-growing code base.
Let’s look at a few of the tools I used in my last project. These tools helped me to write code quickly yet maintain quality.

<hr>

## React Dev Tools
Programming is 20% coding and 80% debugging. Debugging is what makes a programmer efficient in comparison to others.
React Developer Tools let you inspect a React tree, including the component hierarchy, props, state, and more. To get started, just open the React Developer Tools and switch to the React Components or React Profiler tab.
By selecting one of the components in the tree, you can inspect and edit its current props and state in the panel on the right. In the breadcrumbs, you can inspect the selected component, the component that created it, the component that created that one, and more.
React developer tools are available for [Chrome](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) and [Firefox](https://addons.mozilla.org/en-US/firefox/addon/react-devtools) as an extension.

<hr>
## Styled Components
<img src="https://miro.medium.com/max/516/1*CrJ9gMVMHtMOhGgY1obVJg.png"/> 
While styling components, we also have to take care of vendor prefixes for cross-browser operability. If we’re using LESS or SASS we have to compile code to CSS.
With a component being an individual entity and a basic building block for building apps, it’s recommended for styling to be included within the component, rather than the container app taking care of styling with class names.
Styled components allow us to keep the styles within the component, coupled with the JavaScript code.
Read about some more benefits [here](https://www.styled-components.com/docs/basics#motivation).

<hr>
## React-Intl
Having strings, a lot of text in the UI, and having to internationalize it can be painful at times. With the right translation based on browser locale or user preference, presenting the user interface in a different language can be tricky.
React-Intl handles it in an elegant way, wrapping your components in a scope and rendering strings based on the locale.
With support for formatting dates, numbers, plurals, etc out of the box, it makes handling such translations easy. Moreover, for a fully-fledged translation conversion, you can have translations based on languages you want to support and you can configure React-Intl to pick up the right translation file at runtime.
Read more [here](https://github.com/formatjs/react-intl/blob/master/docs/Getting-Started.md#introduction).

<hr>
## Storybook
<img src="https://pbs.twimg.com/profile_images/1100804485616566273/sOct-Txm.png"/>
[Storybook](https://storybook.js.org/) allows you to write and test components in isolation.
When there are multiple people working on UI components that need integration at a later point in time, storybook makes it easier for individual developers to write and test their components in isolation.
Moreover, the storybook also serves as a living document of what has been done so far. You can look at all the components at a glance and check how they behave. You can play with a component by modifying supplied props and testing its behavior.
I may sound crazy if you’ve only worked with a smaller codebase but when projects grow, there are times when a developer ends up writing a component that already existed or a behavior variation of an existing component could have met the purpose. In such cases, the storybook acts as a go-to page to see what components & what behaviors already exist.
Check out how you can add stories to your components and make it available as a storybook, [here](https://github.com/storybookjs/storybook).

<hr>
## React Testing Library
<img src="https://raw.githubusercontent.com/testing-library/react-testing-library/main/other/goat.png"/>
It comes last in this piece but this is the most important one and a lifesaver when testing React apps.
Based on this principle, and I quote the author,
```The more your tests resemble the way your software is used, the more confidence they can give you.```
The biggest confusion I have as a developer is when writing tests whether my suite is under mocked or over mocked. Am I testing with the right expectations?
React Testing Library comes up with guidelines about what should be tested, allowing us to test the DOM changes and updates as good as what the end-user will perceive.
Combine it with Jest and you get a robust set of APIs that you need to be able to render your components in isolation, mimic behavioral changes, and observe DOM changes.
Get started [here](https://testing-library.com/docs/dom-testing-library/intro).

<hr>
I have listed the tools that have helped me. That said, there may be tools that have helped you, which you think are better than the ones I’ve listed. I’d love to hear about them.