Most React developers misunderstand useEffect. I used to be one of them. Whenever something is needed to run after the render… I would just throw it inside useEffect. It worked. But I didn’t really understand why. So I spent the last 2–3 days studying it properly through a small project called Workout Timer. The project itself is simple. It calculates workout duration based on: • workout type • number of sets • workout speed • break duration It also shows a live clock and can play a sound when values change. But the real goal wasn't the timer. The real goal was understanding React behavior and performance. --- While analyzing the project I started questioning everything. Not the code. But the architecture behind the code. Questions like: • Does this really need useEffect? • Is this state actually derived state? • Are my dependency arrays correct? • Could a stale closure break this callback? • Are components re-rendering unnecessarily? --- During this challenge I practiced: • auditing effect dependencies • avoiding effect-driven derived state • fixing stale closures in intervals • stabilizing props for memoized components • verifying cleanup logic for timers • measuring component renders --- One important lesson became very clear: useEffect is not a general-purpose tool. React’s rule is simple: > useEffect exists to synchronize with external systems. Things like: • timers • subscriptions • DOM interactions • browser APIs Everything else usually belongs in render logic. --- This challenge reminded me of something important about learning React. Real improvement doesn't always come from building bigger projects. Sometimes it comes from studying how React actually works under the hood. And this small challenge helped me understand that better. --- I share daily learning posts on Dev.to, while my portfolio contains weekly structured progress recaps. Learning in public. One concept at a time. --- #React #FrontendDevelopment #JavaScript #WebDevelopment #ReactJS #LearningInPublic
Understanding React's useEffect: A Simple Project's Big Impact
More Relevant Posts
-
What Runs First in React? Most React developers know what useEffect, useMemo, and useCallback do individually. Far fewer know the exact order they execute in. And that gap causes bugs that are surprisingly difficult to trace. Here is the definitive execution order on first mount: -> Step 1: Rendering JSX React runs the function body of your component first. JSX is evaluated. console.log inside the return runs here. This is the render phase. -> Step 2: useMemo runs during render useMemo executes synchronously during the render phase, not after it. If you have an expensive computation wrapped in useMemo, it runs as part of building the component output. This is why useMemo can be used to compute values that are needed in the JSX itself. -> Step 3: useEffect runs after render After the component has rendered and the DOM has been updated, useEffect fires. It is intentionally deferred. This is where API calls, subscriptions, and side effects belong because they should not block the render. -> useCallback is different from all of them useCallback does not run during mounting. It stores a function reference. That function only executes when it is explicitly called. In the example on the right, increment only logs when you actually call increment(). The final order: Rendering JSX, then useMemo, then useEffect. Why this matters in practice: If you expect useEffect to run before useMemo, your state update will not be available when useMemo computes. If you expect useCallback to run automatically, your side effect will never fire. Getting the order wrong means working with stale data and writing code that behaves differently than you intended. Understanding execution order is not academic. It is the difference between components that behave predictably and ones that produce subtle timing bugs you spend hours debugging. Did you know the exact execution order before seeing this or did it surprise you? #React #ReactHooks #FrontendDevelopment #JavaScript #WebDevelopment #Developers
To view or add a comment, sign in
-
-
The 2026 Modern Frontend Developer Roadmap Feeling overwhelmed by the "JavaScript fatigue" or the endless stream of new frameworks? You’re not alone. The frontend landscape moves fast, but the secret to staying relevant isn't learning everything it’s learning the right things in the right order. I’ve put together this visual guide to help you navigate the journey from writing your first line of HTML to deploying production-ready applications. 📍 The Journey at a Glance: Stage 1: The Bedrock. Master HTML5, CSS3 (Flexbox/Grid), and Modern JavaScript (ES6+). Without these, frameworks are just magic boxes you don't understand. Stage 2: Version Control. Git isn't optional. Learn to branch, merge, and collaborate on GitHub early. Stage 3: The Ecosystem. Get comfortable with NPM/Yarn and build tools like Vite. Stage 4: Choose Your Path. React, Vue, or Angular? Pick one, master its lifecycle, and stick with it until you can build a full-scale app. Stage 5: Styling at Scale. Move beyond vanilla CSS with Tailwind CSS or Sass for professional, maintainable designs. Stage 6: Reliability. State management (Redux/Zustand) and Testing (Jest/Cypress) separate the hobbyists from the pros. Stage 7: Advanced Tooling. TypeScript is the industry standard for a reason. Combine it with an understanding of REST and GraphQL APIs. Stage 8: Deployment. It's not finished until it’s live. Master Vercel, Netlify, and the basics of CI/CD. 💡 My Advice: Don’t try to check every box in a week. Build projects at every stage. A "perfect" roadmap on paper is worth nothing compared to a "messy" project on GitHub. Which stage are you currently in? Or if you're a senior dev, what one tool would you add to this list? Let’s discuss in the comments! 👇 #WebDevelopment #Frontend #Coding #Programming #SoftwareEngineering #WebDevRoadmap #ReactJS #JavaScript #CareerGrowth
To view or add a comment, sign in
-
-
🔁 useCallback in React.js – Small Hook, Big Performance Impact When building React applications, unnecessary re-renders can silently affect performance. One hook that helps control this is useCallback. What is useCallback? useCallback is a React hook that memoizes a function, meaning React will reuse the same function reference between renders unless its dependencies change. This is especially useful when passing functions to child components, because React normally creates a new function on every render. That can cause child components to re-render even when nothing actually changed. Example: import { useState, useCallback } from "react"; function Counter() { const [count, setCount] = useState(0); const handleClick = useCallback(() => { console.log("Button clicked"); }, []); return ( <div> <button onClick={handleClick}>Click Me</button> <p>{count}</p> </div> ); } In this example, handleClick keeps the same function reference across renders because of useCallback. Why it matters: ✔ Prevents unnecessary re-renders ✔ Improves performance in optimized components ✔ Useful with React.memo When to use it? Use useCallback when: Passing functions to memoized components Working with expensive re-renders Optimizing large React applications ⚠️ But remember: Not every function needs useCallback. Overusing it can actually make code harder to maintain without real performance benefits. 💡 Understanding hooks like useCallback helps in writing cleaner and more optimized React applications. #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #ReactHooks #Coding
To view or add a comment, sign in
-
-
🚀 Understanding Class Components in React One concept that helped me understand how components work internally was Class Components. Before Hooks became popular, class components were the primary way to manage state and lifecycle methods in React applications. A class component is simply a JavaScript class that extends React.Component and must contain a render() method that returns JSX. Example: import React, { Component } from "react"; class Welcome extends Component { render() { return <h1>Hello World</h1>; } } export default Welcome; In class components: 🔹 Props are accessed using this.props 🔹 State is managed using this.state 🔹 State updates are done with this.setState() 🔹 Lifecycle methods like componentDidMount() allow us to run code when the component mounts, updates, or unmounts. Example with state: class Counter extends Component { state = { count: 0 }; increase = () => { this.setState({ count: this.state.count + 1 }); }; render() { return ( <button onClick={this.increase}> {this.state.count} </button> ); } } Today, most developers prefer Functional Components with Hooks like useState and useEffect, but understanding Class Components is still valuable because: ✅ Many legacy React projects still use them ✅ They help you understand React's lifecycle deeply ✅ Some interview questions still cover them Learning both approaches gives you a stronger foundation in React. Sometimes, understanding the old way helps you appreciate the modern way even more. #React #FrontendDevelopment #JavaScript #WebDevelopment #LearningInPublic
To view or add a comment, sign in
-
Blog 03 of my JS Unlocked series is live! 🚀 Control Flow in JavaScript: If, Else, and Switch Explained 👇 Every app makes decisions — show this page or that one, allow access or block it. That decision-making power in code is called control flow. In this one I cover: ✅ What control flow actually means ✅ if, if-else, and else if ladder with real examples ✅ switch statement — and why break matters ✅ When to use switch vs if-else (with a clear comparison) ✅ Hands-on challenge at the end Would love your feedback if you read it 🙏 🔗 https://lnkd.in/dSXtQpfS Thanks to #HiteshChoudhary Sir, #PiyushGarg💛 #JavaScript #WebDevelopment #Hashnode #WebDevCohort2026 #LearningInPublic #Frontend #JS
To view or add a comment, sign in
-
⚛️ Why React became one of the most popular tools for building modern web applications When I first started learning frontend development, one thing quickly became clear: As applications grow, managing the UI becomes harder and harder. Updating elements, handling state, keeping everything synchronized… it can easily turn into messy code. This is exactly where React shines. 🚀 Instead of thinking about the page as one big structure, React encourages developers to break the UI into small reusable components. For example: A page can be built from simple pieces like: 🔹 Navbar 🔹 Sidebar 🔹 Product Card 🔹 Button 🔹 Modal Each piece becomes its own component, which makes the application easier to manage and scale. Another powerful idea React introduced is state-driven UI. Instead of manually manipulating the DOM, you simply update the state, and React automatically updates the UI. Example: const [count, setCount] = useState(0); Whenever the state changes, the interface updates automatically. This approach makes applications: ✅ Easier to maintain ✅ Easier to scale ✅ More predictable Over time, I realized that learning React is not just about learning a library — it's about learning a better way to think about building user interfaces. Curious to hear from other developers 👇 #react #reactjs #frontend #webdevelopment #javascript #softwareengineering #coding #developers #frontenddeveloper #programming
To view or add a comment, sign in
-
A very common React mistake I see developers make: Mutating State When I was learning React, one concept that changed the way I write code was this rule: 👉 React state must never be mutated.its always immutable. But why? React does not deeply compare objects or arrays when state updates. Instead, it performs a reference(memory) comparison. That means React checks: Old State === New State ? If the reference is the same, React assumes nothing changed and skips re-rendering. Example of a mistake: cart.push(product) // ❌ Mutating state setCart(cart) Here we modified the same array in memory, so React may not detect the change because the memory location is same.so no re-render..no UI update. The correct approach is immutability: setCart([...cart, product]) // ✅ Creating a new array Now React sees a new reference, triggers reconciliation, and updates the UI correctly. 💡 Why React prefers immutability: • Faster change detection • Predictable state updates • Easier debugging • Better performance This small concept explains why patterns like: map() filter() spread operator (...) are used so frequently in React. because all this returns new object or array... Understanding this helped me write cleaner and more reliable React components. What React concept took you the longest to understand? 🤔 #React #Frontend #JavaScript #WebDevelopment #ReactJS
To view or add a comment, sign in
-
-
Functional Components vs Class Components in React Most beginners think Components in React are just reusable pieces of UI. But in reality, React has 2 types of Components: * Functional Components * Class Components * Functional Component: const Welcome = () => { return <h1>Hello World</h1>; }; * Class Component: class Welcome extends React.Component { render() { return <h1>Hello World</h1>; } } At first, both may look similar. But the biggest difference comes when you want to: * Manage State * Run API calls * Handle component load/update/remove Functional Components use Hooks: *useState() *useEffect() Class Components use Lifecycle Methods: * componentDidMount() * componentDidUpdate() * componentWillUnmount() Simple mapping: * componentDidMount() → useEffect(() => {}, []) * componentDidUpdate() → useEffect(() => {}, [value]) * componentWillUnmount() → cleanup function inside useEffect Why most developers use Functional Components today: * Less code * Easier to read * Easier to manage * Supports Hooks * Modern React projects use them Class Components are still important because: * Old projects still use them * Interviews ask about them * They help you understand how useEffect works If you are learning React today: Learn Functional Components first. Then understand Class Components. Because understanding both makes you a better React developer. #react #reactjs #javascript #frontend #webdevelopment #useeffect #coding
To view or add a comment, sign in
-
-
Why do we use #useState in #React instead of normal variables? While learning React, I came across a simple but important concept state management using #useState. Let’s take a small example from a header component where we have a Login / Logout button. import { useState } from "react"; const Header = () => { const [loginBtn, setLoginBtn] = useState("Login"); return ( <div> <li onClick={() => { loginBtn === "Login" ? setLoginBtn("Logout") : setLoginBtn("Login"); }} > {loginBtn} </li> </div> ); }; What is happening here? Initially, the button shows "Login" When the user clicks it: If it is Login → it becomes Logout If it is Logout → it becomes Login This happens because we used useState. 🤔 Why not use a normal variable? I try something like this: let loginBtn = "Login"; Then update it on click. But the problem is: 👉 React will NOT re-render the component when a normal variable changes. React only re-renders when: #State changes #Props change So even if you update a normal variable, the UI will not update. ⚡ Why useState works When we use: const [loginBtn, setLoginBtn] = useState("Login"); React does two things: 1️⃣ Stores the value (loginBtn) 2️⃣ Re-renders the component whenever setLoginBtn() updates it. So when we click the button and call: setLoginBtn("Logout") React automatically re-renders the component and updates the UI. Simple way to remember Normal Variable → Value changes but UI does NOT update useState → Value changes AND UI updates 🚀 Key takeaway for React beginners If something in your UI needs to change dynamically (button text, cart count, theme, form input, etc.), it should be stored in state using useState. Small concepts like these make React feel much more predictable and powerful. #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #CodingJourney #LearnInPublic #SoftwareDevelopment #TechLearning
To view or add a comment, sign in
-
🚀 Stop Using React Like It's Just JavaScript After reviewing multiple frontend projects and mentoring developers, I noticed a common mistake: 👉 Many developers use React… but don’t think in React. Here’s what that means 👇 ❌ Wrong Approach (JavaScript mindset) - Writing large components with too much logic - Repeating UI instead of creating reusable components - Direct DOM manipulation - Poor state management ✅ Right Approach (React mindset) - Break UI into small, reusable components - Think in terms of state → UI - Use hooks effectively ("useState", "useEffect", "useMemo") - Lift state up instead of duplicating it - Focus on declarative code, not imperative 💡 Example: Instead of: “Update UI when something happens” Think: “UI should automatically reflect the current state” --- 🔥 Real Impact I’ve Seen When teams shift to this mindset: - Code becomes cleaner - Bugs reduce significantly - Performance improves - New developers onboard faster --- 🧠 Pro Tip: If your React code feels complicated… You’re probably solving it in a JavaScript way, not a React way. --- What’s one React mistake you used to make earlier? 👇 Let’s help others avoid it. #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #SoftwareEngineering #CleanCode #Developers
To view or add a comment, sign in
-
More from this author
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development