Mess to Modern: Refactoring a React Nightmare

Have you ever opened a React codebase and been scared of what you saw on the other side? It could have been 900 lines of just complete spaghetti code mess, multiple different use effects, multiple different use states, all these different things we've opened codebases to and been worried about what we saw. My name is Caleb Garner. I'm a full stack developer and I've opened a lot of these React nightmares. I've had a lot of experience having to refactor them and make them look a lot prettier on the other side.

So what I want to do in this talk today is give you a five-step playbook on how to turn this inherited or created 900-line React component and turn it into something you'll actually enjoy working in. This is our starting point, and you'll see that this is very messy and it's doing a lot of things here. It's 900 plus lines of React, five user calls, 16 new state calls. There's fetching, transforming, validation, rendering all happening in the same spot. And it's a complete nightmare to work on from a developer standpoint.

Now, I've opened a lot of codebases and been met with something very similar to this. But where do we go from here? What do we do in order to condense this down and get into a place that's actually enjoyable to work in? Not only that, it's a lot more performant, and it's a lot better structured for the rest of the team to manage as well from this point. We're going to be going over five separate points in order to address codebases like this. The first one being system modularity. We're not actually starting within the component. We're starting on the outside and how we organize the entire structure of the project all together.

You see, what is the pattern that we see a lot in these codebases? And how this is going to work is we're going to go over what the pattern looks like, how do we fix it, and why do we fix it in the very end? You see, first up is systematic modularity. You know, most of the projects you're going to open are going to open to a flat components folder, 40-plus folders that tell you what components are and even what the framework is, but they don't tell you what the project is. And that's the first step for us to get this codebase into something modern and modular, is that our component structure should model what our app is doing and not the components or the framework it is in. Before you move a single line of code, you need a map of what the components in the app are going to look like. That's where you get into feature-driven components. Components, hooks, and types are all co-located based on the features, not based on the framework. And we get into this structure where if you need a specific item for a specific feature, it's found within the features folder. This makes things a lot more workable from when you're handing this project off to someone who's never seen it before or from just everyday, day-to-day maintenance of this project. This is going to be a lot easier and a lot more structured to be able to work in as a developer as well. And obviously, any shared components in the utilization of primitives, which is something we'll talk about a little bit later in the presentation, is also important as well. But all these structures and components are co-located in places that they need to be, not based in just a singular flat component library.

Now, why do we do this? We kind of shared the snippet here of what the exports would look like in our dashboard page if we met this pattern. And why? Conway's Law says your system will mirror your organization structure, usually by accident. Architecture and what this principle is we're implementing here tells us that we should be doing it on purpose. Our feature should tell us exactly what that code does, and we shouldn't have to guess what that component's doing or where that component is based off of our folder structure. This gives us a good baseline and good structure to not only modularize and make our individual components and pages better and our features better, but something that scales to the entire code base as well. Now, the next thing we're going to get into is logic extraction. We talked about the organization of the folders, and now we're going to get into the actual code, what we should be doing within these components as well. So, within our dashboard page, we had business logic baked into the actual component as well. These revenue calculations, fetching logic, validation were all living inside the component. That can be problematic in a couple of different ways. One, we have these components that are doing way too much on the front end, but we also – it's not testable. We can't unit test these individual components, and they're stuck within our component as well. You can't reuse any of these components if other features need to do the exact same thing. And if a component breaks, everything in this folder or in this file is going to break, especially all this logic and the reusable pieces as well. So, this is the pattern we're trying to get away from. Now, how do we do that? We have these specific hooks and break out this business logic into their own system, their own modular pieces of code that we import into our main dashboard. Use order filters owns a filter and source logic. Use orders owns a fetch. Each hook is independently testable with render hook.

The component calls one hook and gets everything it needs. The component is not describing what it needs or making what it needs on its own. It's using these reusable pieces and individual testable pieces of code that we can use within the code base as well.

Now, why do we match this to pattern? Why do we separate this business logic from the dashboard into these individual hooks? So, single responsibility. Apply it to each – each hook has one job. And when it breaks, you know exactly where to look. Or if you need to advance it or need to improve it, you know exactly where to look for that hook as well. Testability is possible in this model. To test these items, you're able to test in individual hooks. You don't have to organize that in a complete singular component by itself.

There's a mental shift when it comes to logic extraction. When we're taking this business logic outside of component, a component that fetches, transforms, validates, and renders is four things pretending to be a singular. It's pretending to all be fit – or fit under the single umbrella of this component. When you extract it into hooks, the component becomes a thin shell responsible for pure rendering. It's not responsible for these exterior things that should be reusable logic across the entire code base. So, we talked about – we've talked about the logic extraction. We've talked about the organization of the components. Now, I want to talk about state management.

This is one of the patterns I see quite often working with inherited code bases. You see, filtered orders is not a state. It's a computation, but it's being stored, synced, and maintained like it's real data. This pattern is something I see a lot where the separation between state and data is not being maintained in these code bases, in these projects, where we need to separate. Again, state needs to be managed like state, and data needs to be handled like data as well.

In this way, maintaining a more mature way and a more predictable way to maintain our state management. So, here's a pattern that we often see, but how do we fix that instead? If value can be calculated from an existing state, calculate it with something like useMemo. Use it as a piece of state as well. But when state has multiple related pieces, use a discriminating unit so impossible states become impossible to represent, and the type system enforces this here.

The main idea and shift around state management within our components that makes this more modular and more modern is we turn into predictable state management. We're not using these use states in a way that's very open-ended, and we're not creating a lot of chaos with our components and within our state management, but we're actually turning that into a predictable flow that can be seen throughout our code in something that's modular and something that's completely set up for within our components as well.

Now, next slide over here. So, why do we need this pattern? We don't want to guess the flow of our data and the flow of this application. We need to define a predictable pattern, especially using something like userReducer, something I've used a lot within my code, because it makes every possible state transition visible within the code and what your application is going to do and what the state management is going to do as you advance through your app. It's no longer playing a guessing game towards what your state is. You're distinctly defining what the state of your application is going to be and managing that in a much more structured way. And userReducer gives you a single place where states in the transition are defined and readable, but userReducer for local complex state, the other thing that I see a lot of the time, is reaching for a library like Zestand for state.

And we need to not reach for that for the first instinct, because state management that lives outside of the component tree, this state is needed for multiple different components. That's where you'd use a state manager like Zestand. So don't reach for a store by default if state doesn't leave the tree. It doesn't really need one in that case. But there's other methods and other ways that we can get this predictable state management across our entire project and within these specific components and within these specific processes. Now, I mentioned specific processes. The fourth one or fourth stage I want to talk about is data handling. This pattern that we're noticing in this snippet, user effect manages its own loading state, its own error state, and its own cache. And it's very easy for these to drift. Once one gets updated, the others don't.

And this is service state being managed on the client side. Then the more dangerous version of this is two different pages of the app both need this data, both need this structure, both need API orders or API customers. This logic needs to be shared across multiple components. And this pattern, if we're doing it in this way, both of those applications would need to define this user effect immediately. And that's not the case that we want to set up for our code. We want to be able to have something reusable. We want to have something that isn't doing this service state being managed on the client side. So what do we need to do? Well, extracting these queries into reusable components and reusable hooks. Query key is the entire caching system in one concept using the structure from React query.

And really the mindset here is breaking out these data blocks and data handling components based off of their domain. What data are they fetching so that can be reused across multiple applications? The individual component shouldn't be describing what they need to fetch, especially when it's reused across multiple different applications. But having this structure in individual query that can be reused is a superpower that can be used across multiple different components to grab similar data and have the same handling of this data, like caching and validation, and having the same structure in a singular point of entry for this data instead of every component handling this data on their own.

Service state and client state are different things that need different tools. The server state we talked about in a previous section, but doesn't need to be managed like a client state. The data that we need within our application, the business logic needs to be handled in a very different way. And this isn't just to clean up our code or make it a lot more prettier when we're looking at the individual components. It changes the mental model from fetch and store to cache and sync. When the API changes, you change one file. You don't need to go and look through individual components in order to find, oh, this component uses this query, and this component uses this query. Structured queries in a singular reusable file so that can be used across multiple different components, and it can be easily tested and easily reused and easily maintained across the code because the components shouldn't be saying what business data they need. Our queries should be maintaining what business data is needed across the application.

Now, another area that, or the fifth stage, the last page we want to talk about is having modular components. Now, nobody builds a 12-prop component on purpose. Nobody gets this point on purpose. What happens a lot of time is you add it one at a time. You add the order at one time. You add update status one time. You add is saving one time. And then you turn from this very simplistic component to 12 props, all doing, and really the mindset here is, one component having every single state and knowing how to do every single piece of this puzzle, what this component should be doing so that it can be reused across different components, across different structures. A lot of the patterns is we have this level of components that get to the level of primitives and get into the level of a shared component library. But this is very unmaintainable from the perspective of a developer as well, being able to maintain these different props and different states within this component in order to reuse it within our code. That interface grows, and the component becomes untestable and really unmaintainable from that point. So how do we address this? Well, it's compound components. If we want to structure this way as something that's broken out and every piece owns their own and really looking at components, there's two different ways that you can go about this. One, you could have individualized components and deeper primitives that do one thing very well. You have one structure, and this component is going to do one thing very well. The other side of this is having a lot more flexibility is a pattern like compound components, where you let every individual piece of this component do exactly one thing. You're adding to this composition and adding to this compound component, but you're not adding props and changing the complete layout and having this more almost brutalist way to handle the component as well. So details of the sample at the call site.

The caller controls what the layout is. Where we determine and call this component determines what it is. The pieces don't need to know about each other from that point. And why do we do a pattern like this? For anything requiring accessibility, and using Radix as an example for this, Radix is going to handle a lot of your accessibility and the value of your components as well, where they're going to solve keyboard navigation, they're going to solve focus driving, they're going to solve ARIA, and you're going to own the styling and own the composition from this standpoint. Where even looking at the structure as a caller of this component, I'm only going to call what I absolutely need and not have to maintain these props to get to that point that I need as well.

So we went through each of these components and each of these five phases of this component library and how to address it and how to go about it. If you notice the snippets, we went through each individual thing that's going wrong in this component. This is where we started. 900 lines of React, 5 UseEffect calls, 16 UseState calls, fetching, transforming, validation, and rendering all happening within the same component. Complete nightmare to work on. If we take these five principles in this playbook, we can go from this to this. 35 lines of React. This kind of transformation has been witnessed in my own code bases using these principles. The components now focus on pure rendering, keeping logic where it belongs, importing only necessary elements and logic within the component.

The component's primary focus is on rendering, keeping business logic separate. By reorganizing and structuring the code, it becomes more maintainable and scalable without hindering developer velocity. The component now offers an enjoyable development experience, making it easier to advance and enhance over time. Gratitude is expressed to the audience for their time and attention during the talk, highlighting the importance of their presence. Links to the speaker's personal journey and website are provided for further engagement and information, showing appreciation for the listeners' participation and inviting them to connect beyond the current interaction.