Components, props, state, hooks — the concepts that rewired how I thought about UI, and the mistakes I made getting there.

#React #Learning #Junior

Why React

When I started, the team I joined was using a mix of jQuery and server-rendered templates, and the senior engineers were debating whether to adopt a modern framework for the next project. React was the obvious choice in 2019 — it had the largest community, the most job postings, and the clearest migration path from the jQuery world we were leaving behind. I was tasked with learning it first, building a small proof-of-concept, and then helping the rest of the team get up to speed. That assignment was both the best and most intimidating thing that had happened to me in my short career, because I was suddenly the "expert" on a technology I had known about for less than two months.

The landscape in 2019 was different from today in ways that are easy to forget. Hooks had been stable for less than a year, and most tutorials still led with class components. Redux was the default state management answer for any application more complex than a counter, and the boilerplate was substantial enough that entire libraries existed just to reduce it. Create React App was the canonical starting point, and the idea of server-side rendering with Next.js was considered advanced for a team that was just learning to think in components. I learned React at a moment of transition, which meant I had to understand both the old patterns and the new ones, because the codebase I was joining used the old and the codebase I was building used the new.

The Learning Curve

The hardest part of learning React wasn't the syntax — JSX is approachable enough that you can read a component and roughly understand what it does within an hour. The hard part was the mental model: thinking in components, understanding the unidirectional data flow, and internalizing that the UI is a function of state rather than a series of imperative DOM manipulations. That last shift took months, and I spent a significant portion of that time fighting the framework — trying to use refs to directly manipulate the DOM the way I was used to, before finally accepting that React's model was different and that fighting it would produce worse code than embracing it.

Hooks were the concept that took longest to internalize, particularly useEffect. The mental model of "this function runs after every render, and the dependency array controls when it re-runs" is simple to state but surprisingly hard to apply correctly. I wrote dozens of effects with wrong dependency arrays before I developed the instinct to question every external reference inside an effect. The senior engineer reviewing my early React code spent more time on dependency arrays than on every other aspect of the code combined, and I'm grateful for that patience because the habit has saved me from countless stale-closure bugs in the years since.

What I'd Do Differently

If I were learning React again from scratch, I'd skip the class component tutorials entirely and start with hooks. The class component mental model — this, lifecycle methods, binding event handlers — is a conceptual tax that adds nothing for a new learner in 2026, and the time spent understanding it is time that could go toward the patterns that actually matter in modern React. I'd also start with TypeScript from day one rather than adding it later, because the type system catches an entire category of bugs that a junior developer would otherwise spend hours debugging with console statements.

The other thing I'd do differently is build fewer toy projects and contribute to more real codebases. Toy projects are valuable for learning syntax, but they don't teach you the skills that matter in a professional setting: reading code you didn't write, understanding why a decision was made before you change it, and working within constraints you didn't choose. Contributing to an open-source project, even with trivial documentation fixes or small bug reports, would have accelerated my growth more than the tenth todo app I built to practice state management.