Lessons Learned: Common React Code-Smells and How to Avoid Them

Code smells are certain patterns and characteristics of code that could indicate or create a bigger problem in the future. In other words, code of questionable quality. The keyword here is . Identifying something as a code smell does not mean that it should be immediately fixed or that it is a problem — only that it should be looked into. It does not mean that the particular piece of code is badly written, only that it should be examined more carefully. questionable Organizations, teams and different developers have their own understandings of particular patterns and habits. It all sums down to whether a certain technique for you or doesn’t. works The point I will communicate in this article is that it’s worth examining to avoid problems in the future. But before that, let’s clear some terms out of the way. particular patterns There’s a TL;DR at the end of the article if you want only the main points and lessons learned. Code-Smells vs Anti-Patterns An is the diplomatic way to say that the solution to a given problem is not good enough. Finding an anti-pattern means that we have identified a in the code base that should be refactored as soon as possible. anti-pattern problem mean that a design pattern be misused or there is an opportunity to implement something better. They are more of a rather than a fact. Code smells could possibility Refactoring When we identify a code smell or a place in the code which could use some improvements we reach for the term . Since in this article we will be mentioning this word quite a lot we need to clarify exactly what we mean by it. refactoring Refactoring is the processing of some code’s design without it’s functionality. Put in even simpler words — we change how the code is but we don’t change how it . modifying changing structured behaves But how can we change something without modifying its behavior? If we need to refactor a component to take less props or split it into multiple smaller components does that count as behavior change? Yes, changing the component’s props change the way we invoke it. However, our goal is to have the app working the same way after we have finished it. If a component is responsible for displaying a list of filters and we split it into multiple components we need to have a working list of filters in the app. will refactoring still Bloated Components Before React laid the foundations of component-oriented front-end development, we used to mimic the model used in server-side languages. Depending on the framework, there used to be an HTML containing the markup and a file responsible for providing the view with the data it needs. MVC template controller When this practice transfers to React applications it leads to the creation of a component. Those are components that can reach up to 1000 lines of code and contain insane amounts of logic and markup. master There are different ways for a component to reach that bloated state. Following the obsolete idea of having page components is one. Another could be taking the idea of smart/dumb components too much to heart. Some times it feels easier to jam another method inside the class rather than the code. refactor The end result is the same. We end up with a giant component which acts as the origin point for business logic and store connections. The snippet above is to serve only as a vague example, an actual master component can hit a thousand lines of code or more. How to avoid it? We could technically write the whole app in a and all the markup in its render method. Of course, we don’t to it because maintaining something like that would be impossible. The same logic can be applied to writing a whole page’s logic in a single component. single React component If you’ve fallen in a situation in which you need to such a component you have no other choice than to roll your sleeves up and get to work. The sooner you start slicing pieces away from it the better it will get.If you are working on a greenfield project, however, there are two ways to avoid this problem — good planning and self-discipline. refactor you start working on the page, it down on a piece of paper and mark your components with rectangles. Consider the possible interactions between the different parts of the page. Depending on the complexity consider using multiple containers in the different parts of the page and have them communicate between each other using the component. Before sketch page Self-discipline comes in the picture when we need to the plan we’ve made. While deviating from the blueprint be appealing, the cost for that is unavoidable and the interest is high. Spending half an hour to do something the right way could save days of refactoring in the long run. follow could When you start pulling away components from the master, you will see that there is logic related only to particular pieces of the page. Extracting a few parts like that will make the container a lot . leaner Repetitive Logic I follow a simple rule when it comes to repetitiveness. I can’t recall exactly where I read it but it states that if you need to copy something for the then it needs to be . third time extracted I give myself a free pass if there is only occurrence, but once they become three then it’s time for a . one other refactor Having code is unpleasant for every time you need to make changes you have to go on a safari throughout your code base. Whether it is business logic or some markup, extracting it keep our sanity in check. repetitive will How to avoid it? Logic that ends up in many components calls for a or a component which uses . Lately I’ve been falling more in favor of the latter because I find it easier to understand exactly what data it exposes. Except for some super specific cases, anything that you can build with one you can build with the other, so it’s more a matter of what you feel comfortable with. Higher Order Component Render Props Something that we need to talk about here is to and problems. If there is a piece of business logic that is needed in many places moving it to a file is fine as well. Once you have the need to associate it with markup or some particular behavior then it’s okay to promote it and use the patterns we mentioned above. not overengineer overcomplicate utils.js Prop Drilling Taking the concept of components too much heart can lead to bloated containers, but it lead to the infamous as well. smart and dumb (presentational and container) can prop drilling Prop Drilling means to pass props levels of components deep in order to reach a particular component that needs those props. And since a parent pass a prop directly to one of its grandchildren it needs to go through other components on its way down. multiple can’t The problem is that all those other components won’t actually use the prop, they will just pass it down to lower level. This leads to the unnecessary and in the code base. Changing the data’s structure or the name of the prop would require modifications in multiple places. exposure of information tighter coupling It’s a common occurrence to rename a prop in a component due to or for the sake of . Doing that a couple of times in the prop drilling chain will only leave us confused and frustrated. name collisions clarity How to avoid it? If you are working on a small application and prop drilling is starting to become a problem for you then using the may be your best solution. From React 16.3 onward we have access to a new and improved API that allows us to share data in deep component hierarchies. Context API If state management and prop drilling are starting to get out of hand then adding a library like or to the stack should alleviate the problem. Of course those come with a non-negligible so avoid any snap decisions. Redux MobX learning curve If you are using such a library, consider adding more . If you need a component to fetch half the store and pass it down the presentational components then it’s probably time to decentralize the hierarchy a bit. already container components Since both Context and the libraries I mentioned have excellent documentation, there is no point of adding an example here. JSX Outside the Render Method Something that I personally find confusing, is being generated in an of a class component. Looking at the render method’s we should be able to get a good grasp of what this component prints. However, by generating markup in other methods we will soon need to up and down across our component’s code to understand what it renders. JSX instance method return value bounce If we need to extract some markup into its own method then that means that we are looking to in some way. However, by using this technique we bind the component to the markup even further. Since that method will most likely use something from state or props we will increase the level of coupling. separate concerns How to avoid it? If you find the need to move some JSX into an instance method I would advice to move it into a separate component instead. In OOP languages, the idea of putting some functionality in a separate method means that it needs to be away for or logical purposes. In the context of React, the equivalent of the above idea is to extract some logic into its own component. abstracted reusability The counter-argument here is that by adding a component instead of a method call inside the JSX we still can’t grasp exactly what it does. While that is true, we will have clear visibility of the component’s accepted props which is a strong hint for its functionality. At least we will know what data it needs and what callbacks it calls. Deep Indentation When we write markup we sacrifice readability and force ourselves to keep mental track of where we are in the code. Nested statements, chained operations, or deep markup are the common cause of increased indentation. While not necessarily bad or problematic, working with deeply nested code often leaves us wandering where we actually are in the file. deeply nested if ternary loops JSX To be fair this is something that I try to avoid no matter what language or framework I am working with. Flat and linear code is, in my opinion, much easier to understand and more pleasant to the eye. How to avoid it? If we want to the level of nesting we can easily to that by the level of . decrease increasing abstraction The first approach that we can take is to extract the nested functionality into a separate component. My reasoning is that the higher the indentation the more specific the markup gets for a particular part of the . If we need to provide great details about a particular piece of the page then we should move it in a separate file and let it breathe there. UI Indentation inside class methods can also increase really fast. A change in the code style can easily alleviate that. Just removing unnecessary statements and flattening long promise chains with can have a big impact. else async/await Lack of a Clear Standard The JavaScript ecosystem is . Different members of the community hold different opinions and they tend to hold them firm. dynamic Often, developers join the team with different and . While diversity can sometimes lead to better solutions, often those cultural clashes lead to low code quality. The different , and preferences make our code base look like the React equivalent of a cosmopolitan city from a movie. coding styles habits paradigms coding styles formatting Sci-Fi This often has the biggest strain on developers since we will have to do a mindset shift depending on what parts of the app we are currently working on. Not sticking to a particular coding standard and set of best practices leads to frustration, tension and unnecessary time spent on discussing whether semicolons are necessary or not. How to avoid it? No matter if you are the solo developer of a small web app or part of a bigger team, sticking to a set of practices have the highest impact towards your and . It’s important to understand that no code standard will leave everyone on the team happy. Just pick something and go with it. will productivity code quality is an excellent code formatting tool that you can run in your editor or as a commit hook. It doesn’t give you too much configuration options which is actually good — less things to fight about. It can also be used with style guides like or the one uses. Prettier Standard Style AirBnB TL;DR Code smells are not identified problems. They are a suggestion that something may be done better. Increasing the level of abstraction when necessary could make component code a lot cleaner. Don’t reach a state where a refactor is too big of a burden. Code will periodically need to be changed — refactor often. Bad coding style and practices could sometimes cause more problems than the design patterns we misuse. Newsletter Hey, I’m running a small newsletter in which I share random thoughts, musings and insights about software development. No tutorials, no ads. Just some things I’ve found worthy of pondering delivered to your inbox every few weeks. If this sounds appealing to you you can subscribe . HERE Clap and Share If the content of this article was helpful to you I’d appreciate if you hold down the clap button for a bit. This way it will reach and help more people. Share it with friends and colleagues that may find it useful and send any feedback my way!