useReducer in React for Complex State Logic

🚀 Controlled vs Uncontrolled Components in React — Real-World Perspective Most developers learn: 👉 Controlled = React state 👉 Uncontrolled = DOM refs But in real applications… 👉 The choice impacts performance, scalability, and maintainability. 💡 Quick Recap 🔹 Controlled Components: Managed by React state Re-render on every input change 🔹 Uncontrolled Components: Managed by the DOM Accessed via refs ⚙️ The Real Problem In large forms: ❌ Controlled inputs → Too many re-renders ❌ Uncontrolled inputs → Hard to validate & manage 👉 So which one should you use? 🧠 Real-world Decision Rule 👉 Use Controlled when: ✔ You need validation ✔ UI depends on input ✔ Dynamic form logic exists 👉 Use Uncontrolled when: ✔ Performance is critical ✔ Minimal validation needed ✔ Simple forms 🔥 Performance Insight Controlled input: <input value={name} onChange={(e) => setName(e.target.value)} /> 👉 Re-renders on every keystroke Uncontrolled input: <input ref={inputRef} /> 👉 No re-render → better performance ⚠️ Advanced Problem (Most devs miss this) 👉 Large forms with 20+ fields Controlled approach: ❌ Can slow down typing 👉 Solution: ✔ Hybrid approach ✔ Use libraries (React Hook Form) 🧩 Industry Pattern Modern apps often use: 👉 Controlled logic + Uncontrolled inputs internally Example: ✔ React Hook Form ✔ Formik (optimized patterns) 🔥 Best Practices ✅ Use controlled for logic-heavy forms ✅ Use uncontrolled for performance-critical inputs ✅ Consider form libraries for scalability ❌ Don’t blindly use controlled everywhere 💬 Pro Insight (Senior Thinking) 👉 This is not about “which is better” 👉 It’s about choosing the right tool for the problem 📌 Save this post & follow for more deep frontend insights! 📅 Day 17/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #PerformanceOptimization #SoftwareEngineering #100DaysOfCode 🚀

I struggled with this React concept more than I expected… 👇 👉 Why are my API calls running twice? ⚙️ What you’ll notice You open your network tab and suddenly see this: api/me → called twice api/roles → called twice api/permissions → called twice Just like in the screenshot 👇 Same request, duplicated… again and again. ⚙️ What’s actually happening In React (development mode), if your app is wrapped in Strict Mode, React will run effects twice on purpose. useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(setUsers); }, []); Even though it looks like it should run once… it doesn’t (in dev). 🧠 What’s going on under the hood React basically does a quick cycle: mount → unmount → remount Why? To catch hidden side effects To check if cleanup is handled properly To make sure your logic doesn’t break on re-renders So if your API call runs twice, React is just making sure your code can handle it. 💡 The important part This only happens in development Production behaves normally (runs once) Your side effects should be safe to run multiple times 🚀 Final thought If your network tab looks “noisy” like the screenshot, it’s not React being broken — it’s React being careful. And once you understand this, debugging becomes a lot less confusing. #React #Frontend #JavaScript #WebDevelopment #ReactJS #SoftwareEngineering

I recently completed a project focused on building and enhancing a Simple Todos app. This project was a great way to dive deeper into React state management, conditional rendering, and dynamic UI updates. Key features I implemented: ✅ Dynamic Task Creation: Added a text input and "Add" button to create tasks on the fly. ✅ Bulk Task Entry: Built a smart "Multi-Add" feature automatically generates three separate entries. ✅ In-Place Editing: Implemented an "Edit/Save" toggle for each item, allowing users to update titles without leaving the list. ✅ Task Completion: Added checkboxes with a persistent strike-through effect to track progress. ✅ Stateful Deletion: Ensured a smooth user experience when removing items from the list. This project pushed me to think about component structure, reusable props, and clean UI logic in React. Check out the implementation here: https://lnkd.in/dtG46cwU #Day97 #ReactJS #WebDevelopment #Frontend #JavaScript #CodingProject #LearnToCode #ReactComponents #NodeJS #ExpressJS #BackendDevelopment #WebDevelopment #NxtWave #LearningJourney #TechAchievement

⚡ A Simple React Optimization: Using React.memo While building React applications, one thing that can impact performance is unnecessary component re-renders. Sometimes a component re-renders even when its props haven’t changed. This is where React.memo can help. 🔹 What is React.memo? React.memo is a higher-order component that memoizes a component. It prevents re-rendering if the component’s props remain the same. Example 👇 const UserCard = React.memo(({ name }) => { return {name}; }); Now UserCard will only re-render when the name prop actually changes. 🔹 When should you use it? ✅ Components that receive the same props frequently ✅ Pure UI components ✅ Components inside large lists 🔹 When NOT to use it ⚠️ Very small components ⚠️ Components that always receive new props ⚠️ Without measuring performance impact 💡 One thing I’ve learned while working with React: Optimization should always be intentional and measured. Tools like React DevTools Profiler can help identify components that are re-rendering unnecessarily. Curious to hear from other developers 👇 Do you regularly use React.memo, or do you optimize only when performance issues appear? #reactjs #frontenddevelopment #javascript #webdevelopment #reactperformance #softwareengineering #coding

Some of the hardest React bugs I’ve seen weren’t actually inside React. They were happening somewhere in between. Between the event loop and the render cycle. You know the kind of bug. Everything looks correct. State updates are there. Handlers are wired properly. The logic makes sense. And yet… the UI shows stale data. Something flickers for a split second. It works fine locally, but breaks under real user interaction. Those are the bugs that make you question your sanity a bit. What’s really going on is this. We tend to think of React and JavaScript as one system. But they’re not. JavaScript runs your code - sync, promises, timeouts, all of that. React runs its own process - scheduling renders, batching updates, deciding when the UI actually updates. Most of the time, we blur that into one mental model. And most of the time it works. Until it doesn’t. That gap is where things get weird. You’ve probably seen versions of this: 🔹 You call setState and immediately get the old value 🔹 A setTimeout fires and uses stale data 🔹 A promise resolves and overwrites something newer 🔹 Everything works… until a user clicks fast enough Individually, none of this is surprising. But when it happens in a real app, it feels unpredictable. Because the problem isn’t what your code does. It’s when it runs. That’s why these bugs are so frustrating. You’re not debugging logic anymore. You’re debugging timing. The more I work on complex React apps, the more I notice this - a big part of senior frontend work isn’t just knowing hooks or patterns. It’s understanding how React’s rendering model interacts with the JavaScript runtime. Because once timing gets involved what looks correct can still be completely wrong. #reactjs #javascript #frontend #webdevelopment #softwareengineering #debugging #performance #typescript

26 questions. The difference between knowing React on paper and surviving a real production codebase. Here are the 26 questions categorized by the depth of experience required: Level 1: The Foundations => How does React’s rendering process work? => What’s the difference between state and props? => What are hooks, and why were they introduced? => What are controlled vs uncontrolled components? => When would you use refs? => How do you handle forms and validations? Level 2: State & Logic => When should you lift state up? => How do you manage complex state in an application? => When would you use useState vs useReducer? => How do useEffect dependencies work? => How do you handle API calls (loading, error, success states)? => How do you manage shared state across components? => Context API vs Redux — when would you use each? Level 3: Performance & Scale => What causes unnecessary re-renders, and how do you prevent them? => What is memoization in React? => When would you use React.memo, useMemo, and useCallback? => How do you structure a scalable React application? => How do you optimize performance in large-scale apps? => What tools do you use to debug performance issues? => How do you secure a React application? => How do you test React components effectively? Level 4: The War Stories => Have you faced an infinite re-render issue? How did you fix it? => Tell me about a complex UI you built recently. => How did you improve performance in a React app? => What’s the hardest bug you’ve fixed in React? => How do you handle 50+ inputs in a single form without lag? Syntax is easy to Google. Deep understanding is hard to fake. #ReactJS #FrontendDevelopment #TechInterviews #JavaScript #WebDevelopment #Developers

⚛️ Most React developers fix the symptom. Here's how to fix the cause. Stale closures in useState aren't a beginner mistake — they're a design decision you need to understand. This pattern silently breaks in production: const [filters, setFilters] = useState(initialFilters); useEffect(() => {  const interval = setInterval(() => {   fetchData(filters); // always reads initial filters             // never the updated ones  }, 3000);  return () => clearInterval(interval); }, []); // empty deps = stale closure trap The fix most devs reach for: → Add filters to the dependency array → Now the interval resets every time filters change → Race conditions start appearing The actual fix: const filtersRef = useRef(filters); useEffect(() => {  filtersRef.current = filters; }, [filters]); useEffect(() => {  const interval = setInterval(() => {   fetchData(filtersRef.current); // always fresh  }, 3000);  return () => clearInterval(interval); }, []); // stable interval, no race conditions 💡 What's happening under the hood: Every render creates a new closure. useRef gives you a mutable box that lives outside the render cycle — so your async callbacks always read the latest value without triggering re-renders. This is the difference between knowing React's API and understanding React's model. Have you run into stale closures in a production app? What was the context? #ReactJS #JavaScript #FrontendArchitecture #WebDevelopment #SoftwareEngineering

The Importance of Code Splitting in Frontend Apps As frontend applications grow larger, loading all JavaScript at once can significantly slow down performance. Code splitting is a technique that allows developers to break their application into smaller chunks that can be loaded on demand. This means users only download the code they need for the current page, improving load times and overall user experience. Frameworks like Next.js make code splitting easier by automatically splitting code based on routes. When a user navigates to a new page, only the necessary code for that page is loaded. This reduces the initial load time and ensures that applications remain fast even as they grow in complexity. Code splitting is especially important for users on slower networks or mobile devices. By reducing the amount of data transferred, developers can create more accessible and efficient applications. When combined with other optimization techniques such as lazy loading and caching, code splitting becomes a powerful tool for improving frontend performance. Question for discussion: Have you implemented code splitting in your projects, and did it improve performance? #FrontendDevelopment #JavaScript #Nextjs #WebPerformance #Programming

🚀 Understanding useEffect in React — Simplified! If you're working with React, mastering useEffect is not optional— 👉 It controls how your app interacts with the outside world. 💡 What is useEffect? useEffect is a hook that lets you perform side effects in components. 👉 Side effects include: API calls Event listeners Timers DOM updates ⚙️ Basic Syntax useEffect(() => { // side effect logic }, [dependencies]); 🧠 How it works 1️⃣ Runs after component renders 2️⃣ Re-runs when dependencies change 3️⃣ Cleanup runs before next effect or unmount 🔹 Example useEffect(() => { console.log("Component mounted or updated"); }, []); 👉 Runs only once (on mount) 🔹 With Dependency useEffect(() => { console.log("Count changed"); }, [count]); 👉 Runs when count changes 🔹 Cleanup Function useEffect(() => { const timer = setInterval(() => { console.log("Running..."); }, 1000); return () => clearInterval(timer); }, []); 👉 Prevents memory leaks 🧩 Real-world use cases ✔ Fetching API data ✔ Subscribing to events ✔ Setting intervals / timeouts ✔ Syncing with external systems 🔥 Best Practices (Most developers miss this!) ✅ Always use dependency array correctly ✅ Cleanup side effects properly ✅ Split multiple effects into separate useEffects ❌ Don’t ignore dependencies (can cause bugs) ❌ Don’t overuse useEffect unnecessarily ⚠️ Common Mistake useEffect(() => { fetchData(); }, []); 👉 If fetchData depends on props/state → can cause bugs 💬 Pro Insight useEffect is not just about running code— 👉 It’s about syncing your component with external systems 📌 Save this post & follow for more deep frontend insights! 📅 Day 13/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #useEffect #WebDevelopment #SoftwareEngineering #100DaysOfCode 🚀

🚀 Why useState is a Game-Changer in React. let's breakdown this 👇 💡 What is useState? "useState" is a React Hook that allows you to store and manage dynamic data (state) inside functional components. Without it, your UI wouldn’t respond to user input. 📱 Real-Time Example: Form Input & Validation Let’s take a simple login form 👇 import React, { useState } from "react"; function LoginForm() { const [email, setEmail] = useState(""); const [error, setError] = useState(""); const handleSubmit = (e) => { e.preventDefault(); if (!email.includes("@")) { setError("Please enter a valid email address"); } else { setError(""); alert("Form submitted successfully!"); } }; return ( <form onSubmit={handleSubmit}> <input type="text" placeholder="Enter email" value={email} onChange={(e) => setEmail(e.target.value)} /> {error && <p style={{ color: "red" }}>{error}</p>} <button type="submit">Submit</button> </form> ); } export default LoginForm 🧠 What’s happening here? - "email" → stores user input - "setEmail" → updates input as the user types - "error" → stores validation message - "setError" → shows/hides error instantly useState is what connects user actions to UI behavior. It ensures your forms are not just functional, but smart and responsible 💬 Have you implemented form validation using useState? What challenges did you face? #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #Coding