8 Things I’ve Learned Over the Last Six Years Working With React
React is a Library, Not a Framework
Time flies. Five years ago we evaluated React, Angular, and Vue in our team and decided to go with React.
Today, it looks like we made the right choice. React is still around — unlike many other JavaScript libraries and Google Trends shows success.
Here’s a few important things I have learned in the last six years:
1. React Is a Library, Not a Framework
While Angular, for example, is a framework, React is “only” a library. While Angular brings a lot of what is needed to implement and maintain a complex business application, React focuses on the implementation of GUI components.
For forms, validation, internationalisation, etc., third-party libraries have to be used in React applications. This brings a great deal of freedom, but can also lead to a dependency hell and wrong choices.
If you don’t want to build your own React stack, you can, of course, use one of the many React frameworks out there:
2. Don’t Solve Every Problem Using Another Library
Always be careful when adding a new library to your project. Believe me, you will end up in a mess if you want to keep your dependencies up to date and use many libraries in the project that are either not maintained or constantly contain incompatible changes.
When you add a new library, you should always check its quality by looking at the following points on GitHub:
- How old is the last release?
- How many dependencies does the library use and are they up to date?
- How many stars, downloads, open issues, and open pull requests does the project have?
Especially if styling is involved, I advise creating a custom component rather than using an existing complex configurable component whose style has to be overridden, that’s mostly no fun!
3. If You Use Component Libraries, Use Headless Components
If you have the feeling that it is too much work or you understandably don’t want to implement your own date picker or dropdown component, you should look for “headless components.” These are components that cover necessary functionality and UX but no styling. It is left to the developer to style these components according to his needs.
Here are a few headless component libraries I can recommend:
4. You Don’t Need To Use Redux
React is not a framework, and so you quickly come to the conclusion that you still need something like a backbone for data management or state management.
The classic pattern we know for applications with user interaction is the MVC — Model View Control pattern. Facebook has given us an alternative: Flux.
For this approach, there are now many adoptions and implementations for React, Angular, and other UI solutions.
The most popular state management implementation is Redux, but you don’t need to use redux. Take some time to find the right solution for your application. Besides Redux, there are some alternatives — I can recommend Zustand.
You can also keep it simple, just use the state of components, and pass it down to child components using properties. This works for a lot of cases. For data, you need across the application and want to manage at the application level, like the user session, you can use the React Context API.
I mostly use the following pattern to create a context and use it in components using a custom hook.
Create a file containing the user context itself, the provider, and a shortcut hook function to access the context. Here’s how:
Put the provider as high up in your component tree as possible. Here’s the code to do that:
Finally, access the user context in any component you need with this code:
5. Use PropTypes the Right way
As your app grows, you can catch a lot of bugs with typechecking. For some applications, you can use JavaScript extensions like Flow or TypeScript to typecheck your whole application. But even if you don’t use those, React has some built-in typechecking abilities.
As the documentation of React says, with the prop-types lib you can prevent type errors, especially if you don’t use typescript or flow.
This works relatively easily and well. Just a little tip from my side:
Don’t use prop types to describe general data structures, use them to define what you expect in your component. Otherwise, you will end up with big shapes valid for multiple components, increasing the coupling and prone to errors.
4. Keep Your Components Small
Finding the right size for React components is one of the most difficult. The bigger your components become, the more complicated they get to maintain and test. Too small components on the other hand will make your code base hard to read — and hard to maintain.
My tip is to use standard software development patterns to separate your components. The most important ones in connection with React are the following:
And always remember, you are not writing code for yourself or the compiler/browser. You are writing code for other people, so try to stick to Uncle Bob’s clean code philosophy.
7. Divide Your Component Library Into at Least Two Modules
This is a real story. In my team, we were the first to work with React in the company. So we had to implement many layout React components to follow the company’s style guide.
When the second team started with React, the team of course didn’t want to implement the company style guide in React again and asked us for our React components.
Unfortunately, it was almost impossible to separate it from our project because it was very strongly dependent on our business logic.
My tip is to create your own UI component library from the beginning that doesn’t contain any business logic. This makes it much easier to share these components between teams or projects, makes it easier and more fun to test and work on the components, and of course, makes later redesigns very easy.
For the implementation of UI components, a solution like Storybook is a good choice.
And to not end up in an in-house dependency ad version hell, use a monorepo for your apps and libraries. NX helps you with that.
8. Write Tests
I am also known as Mr. 100% because I have the opinion that your unit test report should have a coverage of 100%. It is better to ignore parts of the code explicitly in the test coverage than to say that 80% coverage is enough. With this, you run the risk that important parts are not tested.
My preferred test setup for testing React applications consists of Jest as the test runner, React Testing Library as the framework for unit and integration tests of React components, and Cypress or Playwright for the full end-to-end tests.
Thanks for reading.
