Some Thoughts About Writing Better React Code

by

I’ve spent a fair amount of time this week at work conducting what fellow Recurser Maryanne Wachter calls “code archeology” inorder to change out an old API for a new one I’ve written. (If you don’t know this context already, I’ve been working as a Full Stack developer now for two months after never-graduating.). Because of this I’ve had to deal with a lot of front-end code I’m going to describe as “bad” and thought a lot about what would make it “good.” However, whenever I use the term “bad” I want you to think of all the caveats like “we don’t really have enough experience or context to call code good or bad just by reading it” and “good code is working code written at the right price in the right timeline to satisfy the demands of capitalism placed upon us.”

I’m certainly not the React expert (we also use Vue at work which is a different gripe) but here are some things I constantly think about that I think would be useful to people learning React.

  • React is all about state. Your job is to write code that manages that state. The webpage you’re making is just a view of state. Think state first and webpage second. Don’t make a webpage and then write code that generates that state to make the things you want the user to see. This is unsustainable for complex multi-page apps (which is where things like Stores and UseContext come into play to centralize state) and is how you get infinite refresh reference loops.
  • Write code that focuses on clearly managing state. The functional syntax of Vue and React is superior because it puts state font in center (so learn and use them!). I may be biased because I got serious about programming when a lot of people were making the switch, but a functional programming mindset works much better than a class-based approach for React. The class-based syntax lures you into thinking you’re making a component and it makes a nice story about how it has some methods, and some props, and some data, and you’re going to build a structure out of these little blocks. This is the wrong way to think about React. In React you start at the beginning of your component code, get some state, run some functions on it, and by the end of it you’re responsible for returning JSX (your component’s HTML). It’s a story with a beginning, middle, and end, and when it’s over you’re going to go start the next story (aka the next component).
  • Elegant React code is elegant in its management of state, not necessarily in its data structures or execution. I think this is the source of a lot of the problems I see in my code archeology. When people come to React with experiences in other programming languages like my coworkers have, they are asking “how can I do this with the least memory and processor time?” when really you should first ask “how can I do this with the most straightforward state?”
    • If we were making code that represents a jukebox my coworkers might have a data structure for SongsToPlayNext that’s a queue of songs from the jukebox that the user can add to and the jukebox removes from. This could be a perfectly good approach in a context outside of React.
    • In React this could quickly have tricky issues: What if a song is deleted from the jukebox? Now we have to also synchronize the state of the song queue to the jukebox available songs. Even worse they might even put this queue state in a component and not the global state. If we had multiple users interacting with the jukebox how do we then manage multiple queues in each component? In React you want to avoid adding duplicate representations of state at all costs. Maybe my example is a little forced but hopefully you see how the better answer might be to keep everything in one global jukebox state. Each song in the database could be flagged with a number that represents it’s position in the play queue. The jukebox backend has a function playNextSong that gets the lowest numbered play queue song and each user has a addSong function that flags the desired song with the nth+1 play queue position.

I’m certainly not the first person to talk about these things and I’m sure I encountered a lot of them multiple times in my focused learning periods but their importance keeps getting clearer and clearer. A lot of them I learned by watching and copying video tutorials like Dave Gray and Code with Mosh which is just a very asymmetrical code pairing session which I’m a big fan of. Some of these things were reinforced by trial and error (I’m looking at you ReactDoku and the four rewrites it took to create). Hopefully if we all keep these things in mind (and stay open to learning new ones!) we’ll write frontend code the next archeologist will be excited to unearth.