React learning notes: the path I actually took

This is a living note — I rewrite it whenever my understanding changes. It’s not the most complete React tutorial; it’s the path I actually took until React became my primary tool on client projects.

The learning order that worked

My first mistake: jumping into React before being comfortable with JavaScript. Every error felt like magic. The order that finally worked:

1. JavaScript first, properly. Array methods (map, filter, reduce), destructuring, spread, promises/async-await, and closures. React is fundamentally just functions being re-invoked — once closures click, useState makes sense.
2. Thinking in components. Break the UI into boxes: which ones own state, which ones only receive props. My exercise: take a real e-commerce page and draw its component tree on paper before writing any code.
3. As little state as possible. The rule I still hold: if a value can be computed from props or other state, never store it as new state.

// The anti-pattern I used to write: derived state.
const [items, setItems] = useState([]);
const [total, setTotal] = useState(0); // ❌ can always go stale

// What I write now: compute during render.
const [items, setItems] = useState([]);
const total = items.reduce((sum, it) => sum + it.price * it.qty, 0); // ✅

Patterns proven on client projects

After several commercial builds (storefronts, admin dashboards, multi-step forms), these three patterns have saved me the most:

• Server state ≠ UI state. API data goes to TanStack Query (cache, refetch, loading states) — useState is only for things the UI truly owns: open modals, form inputs, active tabs.
• Lift state only when needed. Start at the deepest component; lift to the parent only when two components genuinely need the same value. Lifting too early = painful props drilling.
• “Dumb” components pay off later. Presentational components with no logic move easily between projects — half of the UI kit I use on client work was born in earlier projects.

When I deliberately DON’T use React

The site you’re reading doesn’t use React — it’s server-rendered with Hono JSX + HTMX on Cloudflare Workers. The reason is business, not taste: static content plus a simple form doesn’t need 100KB of JavaScript in the browser. I reach for React when the app is genuinely interactive — shopping carts, realtime dashboards, editors.

That’s the biggest lesson: learn React until you know when not to use it.