Why Did I Have Difficulty Learning React?

Just over six months into a job doing React development, I’ve been trying to figure out why it has taken me so long to feel comfortable with it. (Comfortable feels a bit too ambitious of a word. Maybe competent? Unexceptional? Whichever.)

For me, I think it has come down to four different things:

All the Technologies

Writing JS differently

Deep Hierarchies

Evolving Approaches

All the Technologies

Working at Abstract meant learning their tech stack. Every company is different, of course. The Abstract product uses React for their desktop app, based in Electron, and their web app. There’s also Redux. There’s Flow for static type checking. Then there’s all the other libraries that are imported and used along the way.

It meant I needed to jump in and learn everything new and fresh. I didn’t know the APIs of any of these technologies. It has taken me awhile to learn the edges of each one and understand where I was using the concept of one library versus another.

When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.

Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”

Writing JS Differently

I’ve been writing JavaScript since DOM Level 0. I started out writing everything as functions. Then Prototype came out and I had this new way of thinking about writing JavaScript. A year after Prototype, jQuery came out and, again, I was learning new concepts.

Component-based libraries like Dojo and YUI came out but I didn’t feel like I had to dramatically shift the way I write JavaScript. The JavaScript interface—ECMAScript, specifically—went pretty much unchanged for a decade.

And then ES5 and ES6 came out.

I now found myself having to not only learn all the new frameworks and libraries but also learn this new paradigm of developing JavaScript.

Similarly, using a static type checker meant I had to learn what was new JavaScript syntax and what was a part of Flow syntax.

Deep Hierarchies

Another hurdle I ran into was deep object hierarchies. This is a more subtle one but I definitely feel this when I’m digging into an issue.

To some degree, I think Redux is somewhat to blame, with each object needing global state being wrapped in a Connect component. As such, inspecting a React tree is often nearly twice as long than it feels like it needs to be.

Sometimes it’s hard to track down where a component is defined. It might be rendered as a child element but actually gets defined a few levels up, assigned to a prop, and then passed down. Where something “lives” isn’t always clear.

It’s also not always clear where the data is coming from that is populating a component. Sometimes it’s five levels up being passed down through rested props. Sometimes it’s pulled in via Redux.

I feel like a I have a dump truck full of context unloading itself into my brain before I can understand it.

It’s not unusual for me to begin my hunt down the rabbit hole opening 10 different files, trying to trace where the data is coming from.

At Abstract, we’ve started differentiating our Flow typing to make this clearer. This leads me into my last reason.

Evolving Approaches

The way we choose to solve a problem changes over time. Coming into Abstract, I was coming into a three year-old project that has evolved over that time. What started as a desktop-only product evolved to support desktop and web. React has changed in that time. Redux has changed in that time. Flow has changed in that time. Every developer on the team evolves.

As such, going through the project can often be like looking at the cross section of a felled tree. The rings and knots of The Old Ways are made visible under the light of debugging. New approaches don’t necessarily wipe out the old ones. Instead, the old code sits until one day it is uprooted from existence through refactoring and replaced.

I’ve often found myself hopping on a call with a co-worker, someone who has been with the company and the code much longer than I have, to be told, “yup, that should probably be refactored.”

Momentum

The past six months have been about learning all the things. Not just the different frameworks and the evolution of JavaScript but also the more subtle art of trying to learn the nooks and crannies of a codebase.

As such, it has taken me six months to build up some momentum and feel useful and productive.

It was difficult to come in thinking I was a senior developer and instead feeling like a junior. I often spent more time than I should have on my own just trying to understand things, frustrating myself in the process. I’d go a day or two or three of making no progress before reaching out to someone to explain something I didn’t understand but feeling like I should, feeling like I wasn’t good enough.

I put a lot of pressure on myself.

I’ve considered quitting many times.

I needed to reframe why I was at Abstract and come at it from the viewpoint of being a beginner again. As such, I’ve slowly been building momentum. A successful week is one that is better than the last.

I have to give a lot of credit to my managers and co-workers at Abstract. They’ve been patient and helpful and kind. I consider myself quite lucky to be among good people.