React 19 Simplifies Forms with useActionState

use() is the first React hook you can call inside an if statement. Not a typo. React 19 quietly broke the "Rules of Hooks" - for exactly one hook. For years the rules were absolute: - Always call hooks in the same order - Never inside conditions, loops, or early returns use() ignores both. On purpose. What use() replaces: - useState + useEffect just to unwrap a promise - useContext pinned to the top of every render - Manual "if (!data) return <Spinner />" loading guards What use() actually does: - Unwraps a promise: const data = use(promise) - Reads context: const theme = use(ThemeContext) - Works inside if, for, ternaries, early returns - Suspends the component automatically while pending The mental model shift: Fetch the promise in the parent. use() it in the child. Wrap in <Suspense>. Done. If you're still writing useEffect(() => fetch().then(setData), []) in a React 19 codebase - React is now doing that work for you. Which React hook do you still reach for out of habit - even after React 19 made it obsolete? #React #React19 #Frontend #WebDev #JavaScript #LearnInPublic

React 19's `useActionState` hook is the simplest way to cut form boilerplate in half. If you're still writing React 18-style form handlers with separate `useState` calls for loading, errors, and results — this hook consolidates all of that into one line. Key points: 🔹 **One hook replaces three `useState` calls** — `useActionState` returns `[state, dispatch, isPending]` in a single call 🔹 **No `e.preventDefault()` needed** — wire the action to `<form action={formAction}>` and React handles the rest 🔹 **Automatic pending state** — `isPending` is managed by React, no manual `setIsPending(true/false)` 🔹 **Works with Server Functions** — seamless integration with React Server Components 🔹 **Multiple independent actions** — use multiple `useActionState` calls in one component, each managing its own state Before (React 18): ```jsx const [loading, setLoading] = useState(false); const [error, setError] = useState(null); const [result, setResult] = useState(null); // handleSubmit with try/catch/finally ``` After (React 19): ```jsx const [state, formAction, isPending] = useActionState( async (prev, formData) => { // Your async logic return { success: true }; }, initialState ); ``` The hook is stable in React 19 and ready for production. Full deep dive with code examples here: https://lnkd.in/eHMp_Z-X What's your experience been? Have you migrated to `useActionState` yet? #react #javascript #webdevelopment #frontend #react19

Most React developers know this rule: “Don’t call hooks inside loops or conditions.” But far fewer understand why. React doesn’t track hooks by variable name or location. It tracks them purely by call order during render. So internally, it’s closer to this mental model: • First useState → slot 0 • Second useState → slot 1 • Third useState → slot 2 Each hook call is mapped based on its position in the sequence. Now imagine this: if (isLoggedIn) { useState(...) } On one render the hook is called, on another it’s not. That shifts the entire sequence. React will still read: • “2nd hook → slot 1” But now it’s actually reading the wrong state. I built a minimal useState implementation (attached) to demonstrate this. You’ll notice: • Hooks are stored in an array • Each call consumes the next index • The index resets on every render • Everything depends on consistent ordering That’s the real rule: It’s not about avoiding conditions It’s about keeping hook calls in the same order every render Once that order changes, state association breaks. #React #JavaScript #Frontend #SoftwareEngineering

Many React bugs are self created Not because React is hard But because we sometimes store things that React can calculate for us. Lets fix one common mistake Dont store derived values in state If a value can be created from existing state or props, you usually dont need useState. Avoid this practice function CartSummary() { const [items, setItems] = useState(3) const [pricePerItem, setPricePerItem] = useState(25) const [total, setTotal] = useState(0) useEffect(() => { setTotal(items * pricePerItem) }, [items, pricePerItem]) return <p>Total: ${total}</p> } Looks ok... but it adds => Extra render cycles => More logic to maintain => Chance of outdated values Better Approach function CartSummary() { const [items, setItems] = useState(3) const [pricePerItem, setPricePerItem] = useState(25) const total = items * pricePerItem return <p>Total: ${total}</p> } Cleaner, Faster and Easier to understand Sometimes the best React code is less React code. #React #JavaScript #Frontend #WebDevelopment #Coding

Unpopular opinion 👇 You probably don’t need Redux anymore.😅 With modern React: • Context API + useReducer • Server state libraries (like React Query) • Better component design Most apps can scale without heavy global state tools. But here’s the catch: 👉 The real problem isn’t the tool—it’s how we structure state. Good engineers don’t ask: “Which library should I use?” They ask: “Where should this state live?” What’s your take—Redux still essential or overused? #React #JavaScript #Frontend #SoftwareArchitecture #Thoughts

React recap: 𝗨𝘀𝗶𝗻𝗴 𝗶𝗻𝗱𝗲𝘅 𝗮𝘀 𝗮 𝘂𝗻𝗶𝗾𝘂𝗲 𝗜𝗗 𝘄𝗮𝘀 𝗺𝘆 𝗯𝗶𝗴𝗴𝗲𝘀𝘁 𝗺𝗶𝘀𝘁𝗮𝗸𝗲 𝗶𝗻 𝗥𝗲𝗮𝗰𝘁. At first, it felt harmless. items.map((item, index) => ( <Component key={index} /> )) Everything worked… until it didn’t. Here’s what I learned the hard way: • When the list changes (add/remove/reorder), React gets confused • Components don’t re-render correctly • State sticks to the wrong items (this one is scary) • Bugs appear that make zero sense at first I spent hours debugging something that wasn’t even obvious. The real problem? Index is not a stable identity. So what should we do instead? ✔️ Use a unique ID from your data (database ID, UUID, etc.) ✔️ Generate stable IDs (not on every render) ✔️ Think of keys as identity, not position Bad: key={index} Good: key={item.id} Simple change. Massive difference. One small mistake can quietly break your entire UI logic. If you're using index as key — fix it before it fixes you. #React #Frontend #WebDevelopment #JavaScript #CodingLessons

𝐈𝐬 𝐲𝐨𝐮𝐫 `useEffect` 𝐡𝐨𝐨𝐤 𝐫𝐮𝐧𝐧𝐢𝐧𝐠 𝐭𝐨𝐨 𝐨𝐟𝐭𝐞𝐧, 𝐨𝐫 𝐧𝐨𝐭 𝐞𝐧𝐨𝐮𝐠𝐡? 𝐘𝐨𝐮'𝐫𝐞 𝐧𝐨𝐭 𝐚𝐥𝐨𝐧𝐞. I’ve seen countless `useEffect` bugs boil down to one thing: incorrect dependency arrays. It’s deceptively simple, but a missing dependency can lead to stale closures and unexpected behavior, while an unnecessary one can trigger re-renders like crazy. Consider this: if you define a function or object inside your component and use it in `useEffect`, it must be in your dependency array. However, if that function itself isn't memoized with `useCallback` (or the object with `useMemo`), it becomes a new reference on every render, causing your `useEffect` to fire relentlessly. The Fix: 1. Be explicit: List all values from your component scope that `useEffect` uses. ESLint usually flags this for a reason. 2. Memoize functions/objects: If a function or object needs to be a dependency but shouldn't trigger re-runs unless its own dependencies change, wrap it in `useCallback` or `useMemo`. ```javascript // Problem: myApiCall changes every render if not memoized const MyComponent = ({ id }) => { const myApiCall = () => fetch(`/data/${id}`); useEffect(() => { myApiCall(); // myApiCall is a new function on every render }, [myApiCall]); // Infinite loop! } // Solution: const MyComponent = ({ id }) => { const myApiCall = useCallback(() => fetch(`/data/${id}`), [id]); useEffect(() => { myApiCall(); }, [myApiCall]); // Now, myApiCall only changes when 'id' changes } ``` It's a subtle but critical distinction that keeps your React apps performant and predictable. What's the trickiest `useEffect` bug you've ever had to squash? #React #JavaScript #FrontendDevelopment #WebDev #Performance

React keeps evolving but one thing hasn’t changed: Clean, maintainable components still matter more than trendy patterns. There’s so much noise around tools, libraries and “must-know” tricks that it’s easy to overlook simple patterns that make day to day code better. So switching gears a little from my usual reflective posts today I wanted to share something practical from my experience, 5 React patterns I keep coming back to in real projects that help reduce component bloat, improve readability, and keep code easier to scale. Inside the carousel: 1. Early returns over nested conditions 2. Custom hooks for cleaner logic 3. Object maps over condition chains 4. When not to overuse useMemo 5. Splitting UI from business logic None of these are flashy. They’re just small patterns that compound. Save it for your next React refactor if useful. ⚛️♻️ #ReactJS #FrontendDevelopment #JavaScript #SoftwareEngineering #WebDevelopment #CleanCode #FullStackDeveloper

useState is great for simple values. But when state starts spreading across multiple fields, conditions, and edge cases, useReducer usually wins. Why? Because it makes state changes predictable. Instead of chasing setters across a component, you define actions and keep update logic in one place. - Less guessing. - Less scattered logic. - Cleaner React. My rule: Use useState for simple state. Use useReducer when state has multiple ways to change. React gets easier when state transitions are explicit. #react #javascript #frontend #webdevelopment

Stop complicating your React code. Managing complex state can quickly become overwhelming. When you rely on multiple useState hooks, your logic often becomes fragmented, harder to reason about, and difficult to maintain. There’s a better approach 👇 👉 Use the useReducer hook It allows you to manage related state in a centralized and predictable way, making your components cleaner and more scalable. Want to take it further? Abstract your reducer logic. This gives your components a simpler interface and keeps implementation details isolated — a key step toward better architecture. These patterns aren’t optional. They’re essential if you want to build maintainable and scalable React applications. 📖 Dive deeper in my article: https://shorturl.at/P2Bqs #React #JavaScript #Frontend #WebDevelopment #CleanCode #SoftwareEngineering #ReactJS