React didn't click immediately. Coming from vanilla JavaScript and jQuery, the component model felt unnecessarily complicated. Why describe the UI declaratively when I could just manipulate the DOM directly? That question answered itself the first time I tried to maintain a moderately complex jQuery application as the requirements changed — the DOM manipulation spaghetti became impossible to reason about.
My first real React project was a dashboard for a small business client. Data visualisation, filterable tables, form management. Nothing architecturally complex, but enough surface area that the component model proved its value clearly: I could reason about each component in isolation, test it independently, and reuse it across different contexts without the state management becoming tangled.
The mistake I made consistently in my first few months was over-componentising. I created components for things that didn't need to be components — single-use UI fragments that were just adding indirection without adding reusability. The right heuristic: a component earns its existence by being either reusable in multiple contexts or complex enough to benefit from encapsulation.
State management was the other early stumbling block. I reached for Redux too quickly — before understanding why local component state is insufficient — which meant I was learning Redux's ceremony before I understood the problem it solves. If I were starting again: master useState and useContext before touching any external state library.
The moment React truly clicked was when I built my first form with complex validation logic. Managing that in vanilla JS is an exercise in DOM query pain. In React, the form state is just JavaScript — you can inspect it, derive from it, reset it, and test it without touching the DOM at all.