React Advanced

React Advanced Conference 2022

Darshita Chaturvedi

In this talk, we will take a novel and original look into some of the unexpected behaviors in a React codebase and the anti-patterns that cause them. We discovered them while building a new full-stack web development framework on top of React. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Killing Bugs With Kindness

Hello everyone, my name is Darshita and I'll be talking about how to reduce bugs in a React codebase by understanding antipaths. A little bit about me, I'm the maintainer of the open source project Athree Engine, which is a new full-stack web development framework. I'm also the co-founder and CEO of Athree Labs, which is the company behind this project.

So using Athree framework, the front end of a website can be created by writing React code and its package in Node.js, Python, etc. There are many productivity tools baked into it, such as a visual editor that can be used to create the front end of a website to complement your React code. This is how that visual editor looks like. As you can see, there are numerous interactions on one page. For example, we can add components, style them, and move them around. And we can also see how responsive our website is by clicking on different screen sizes.

So while creating this framework, for our team, it was very important to understand and characterize antipatterns in our large React codebase, because suboptimal code in one interaction can affect the entire application. Moreover, the objective of our framework is to support building production-grade websites. Consequently, building internal standards that are rigorous around code quality were very important to us. So in this talk, I will share the types of bugs we have identified in our codebase and the guardrails we have built to avoid them in future. I will cover how to prevent three types of unexpected code behaviors. First, a component does not update upon a user event. Second, the component updates partially upon a user event, since the previous state is still there. And thirdly, the component renders unexpectedly.

Initially, while building our framework, we were encountering these bugs repeatedly. So our first resort was to use random print statements like a true developer. But of course, later on, we had to use, we had to create some method around it. So we used one central theme to codify hints that are easy to remember, and can lead us to identify antipatterns. And that theme comes from React's official documentation, which states that a React code should be independent of the sequence in which components will render, and when they will render. The first hint is if we are using hooks without a dependency array. We think that one way to visualize a React code is as a collection of interdependent pieces of code. Hence, if a code's dependency relationship cannot be established, then there is a high likelihood that it will result in bugs.
So if we can just take one thing away from this talk, it should be this. Be as paranoid as Charmi was in this iconic Always Sunny episode, when you see or write hooks such as useState, useRef, etc, that do not take dependency arrays. Another way to avoid unnecessary useState is by using the context of the event handler to store state. Here I am demonstrating this using the custom slider component. The code on the left has antipatterns. For example, there are four useStates and three callbacks. The startPosition state records the initial position of cursor. The code on the right is its refactored version. Note that we do not have any useState and only one callback because we have used the local context of the callback to store all the ongoing information related to user interactions. When we applied this refactoring to our framework, we were able to drastically reduce the ratio of useState per component. Our current ratio of number of useState to total number of custom hooks and components stands at around 1 is to 3. To give you a context of the size of our codebase, it has around 100 custom hooks and around 200 components. The next hint for antipatterns is if you are using nesting for arranging components. Note that while using nesting, if you are not paying attention, you might pass down duplicate states to children. This may lead to inconsistencies of states between parent and children. Recall that our code should be independent of the sequence in which components will render. Moreover, there should be a single source of truth for each state, otherwise it will result in bugs. The second thing to note here is that tracing changes in state is the most time-consuming step in debugging. Since nesting allows change in state at each level, it takes longer to debug. The third hint is if you are using many uncontrolled components. We are aware that there is an active debate on the use of controlled components, but we believe that controlled components should be preferred, especially if the number of interactions per page is high. In our framework, we have been able to reduce bugs by more than 80% by using controlled components. So, to summarize, be extra careful when you are using hooks without dependencies and using nesting to arrange components.

We should definitely avoid two anti-patterns. First is using props in context or as initial state.
And the second is using destroy and recreate anti-pattern.
As the name suggests, this anti-pattern refers to removing the component from DOM and destroying all the hooks and states created during the first function call. This is followed by creating the component again from scratch. This anti-pattern can lead to issues such as flickering effect.
There are four coding patterns that we recommend our developers to prefer to reduce bugs. First is using props in JSX. Second using the context of the event handler to store state. Third, instead of trying to make useState work somehow with patchwork, switch to a hook that takes dependencies, such as useMemo. And fourth, use controlled components wherever possible.
Thanks for listening. These are my social media handles. If you're interested in reading more about these anti-patterns, you can check my blog post. There I discuss these anti-patterns in more detail. I've also used an example app in the blog that demonstrates these anti-patterns. Finally, this is the link to the full stack web development framework we are building. If you're interested in contributing to our project or sharing feedback, please check it out. And if you like what we are building, please start our repository. Thank you.