Artem Krasovskyi’s Post

useEffect can cause you side effects. I've seen people with months of React experience still getting burned by it. This is Post 8 of the series: 𝗥𝗲𝗮𝗰𝘁 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 Where I explain what React is actually doing behind the scenes. 🔹 It doesn't run when you think it does. Most devs assume useEffect runs during render. It doesn't. It fires AFTER the render and AFTER the browser paints. React keeps the render phase pure and side-effect free on purpose. 🔹 The dependency array controls everything. This one argument decides when your effect runs. No array → runs after EVERY render [ ] empty → runs once on mount [dep] → runs when that value changes Get this wrong → bugs that are nearly impossible to debug. 🔹 [ ] is often a lie. Everyone slaps [] thinking "run once and forget." But if you're using any variable from inside the component and not declaring it as a dep — that's a stale closure. A hidden bug that silently uses outdated data. 🔹 Missing deps → infinite loops. useEffect with no dep array + a setState inside? That's: render → effect fires → state updates → re-render → effect fires again… Infinite loop. Your app crashes. You panic. 🔹 Cleanup is NOT optional. Every event listener, timer, interval, or subscription you create inside useEffect needs to be cleaned up. No cleanup → memory leaks grow silently in the background. 🔹 Stop overusing it. useEffect is for syncing with external systems. Not for everything. Deriving state, transforming data, computing values. None of that needs useEffect. Ask yourself before writing it: "Is this syncing with something outside React?" If no → you probably don't need it. Next post : State vs Ref vs Variable Follow Farhaan Shaikh if you want to understand React more deeply. 👉 Read the previous post: React hooks hate you for this: https://lnkd.in/d7ySVnJA #React #ReactJS #WebDevelopment #Frontend #JavaScript #useEffect #BuildInPublic #LearnInPublic #FrontendDevelopment #ReactUnderTheHood #DevTips #WebDev #Programming

Have you ever felt frustrated with unwanted re-renders of React components and struggled to find a proper solution? Consider the following insights and share your worst re-render story below. Deep diving into React has taught me more than any tutorial ever could. The more I explored its internals, the more I realized how much was hiding beneath the surface. Re-renders seem simple until your app starts lagging, and you have no idea why. Here’s what I learned the hard way: → Understanding what actually triggers a re-render (it's not just setState) → Why React.memo silently breaks when you pass inline functions or objects → The Context trap that re-renders every consumer even when they don't care about the change → When to reach for useMemo vs useCallback and when to skip both entirely → How the key prop is a reset weapon, not just a list requirement → Architecture patterns that prevent re-renders by design, no memoization needed The deeper you go, the more you realize React rewards curiosity. Every "why is this slow?" question led me to a better mental model. Swipe through the carousel and save the slide that matches your current bug. #React #Frontend #JavaScript #WebDev #LearningInPublic

Just completed Epic React's React Hooks workshop! 🎉 Honestly? I thought I knew React Hooks. I use them every day. useState, useEffect, useRef - they're practically muscle memory at this point. So when I started this workshop, I expected a quick revision. The workshop didn't just recover WHAT hooks do and HOW to use them - it went deep into the WHY behind each decision and their appropriate applications. And that's where the real value was. Here's what genuinely shifted my thinking: - State is component-specific memory - understanding this framing made it immediately clear when to use state vs. derive a value. Always derive state when you can. Fewer sync bugs, cleaner code. - Lazy initializers in useState - passing a function instead of a value means expensive computations only run once, on mount. A small change, meaningful performance win. - Side-effects & the React lifecycle - Mount -> Render -> DOM update -> Layout Effects -> Paint -> Effects. Seeing the full lifecycle laid out made useEffect's behaviour click in a way it never quite had before. - Memory leaks, explained properly - Event listener callbacks close over their scope. If you don't clean up, those closures linger in memory long after a component unmounts. - WHY objects don't belong in dependency arrays - useEffect uses Object.is for comparison. A new render produces a new object reference, even with identical properties. Destructure and pass primitives instead. - State update batching - dispatch doesn't immediately re-render. Updates are queued, batched per event, then applied. - useId() for accessibility - generating stable IDs for linking labels and inputs, preventing hydration mismatches, and building truly accessible reusable components. Often overlooked, genuinely important. First-principles understanding is what separates code you write from code you understand. This workshop is a masterclass in that approach. A huge thank you to Kent C. Dodds - the way this course is structured around application and WHY before HOW is exactly the kind of teaching that actually sticks. Onward to the next workshop! 🚀 #React #ReactJS #ReactHooks #Frontend #FrontendDevelopment #WebDevelopment #JavaScript #EpicReact #LearningInPublic

🎬 Movie Search Application (React) Developed a responsive movie search web application using React that allows users to search and explore movies in real time. The application integrates with an external movie API to fetch dynamic movie data such as title, poster, year. Implemented core React concepts including state management using hooks like useState and useEffect, along with event handling for search functionality. Added features like instant search, Enter key search, conditional rendering for error handling, and sorting movies by release year. Designed a clean and responsive UI using Flexbox and styled-components, including dark mode support for better user experience. 🔗 Live Demo https://lnkd.in/g2X-_Ken 💻 GitHub Repository https://lnkd.in/gczd-9bY #ReactJS #JavaScript #APIIntegration #RESTAPI #StyledComponents #ResponsiveDesign #FrontendDevelopment #WebDevelopment #MovieApp #FrontendProject #Coding #WebApp #Netlify #GitHub #OpenSource

This is subtle but causes real performance issues: ```js // New function reference every render — React remounts the child each time function ParentComponent() { function ChildComponent() { return <div>Child</div>; } return <ChildComponent />; } ``` Every time ParentComponent renders, React sees a brand new component definition. It unmounts and remounts the child — destroying its state and causing unnecessary DOM operations. The fix is simple — define components at the module level: ```js // Stable reference — React correctly reuses the component function ChildComponent() { return <div>Child</div>; } function ParentComponent() { return <ChildComponent />; } ``` This is one of those mistakes that's easy to make and hard to debug when you don't know what to look for. #ReactJS #JavaScript #Frontend #WebDevelopment

If your React component has isLoading, isError, isEmpty and isSuccess as separate props, you have a problem. I have written this exact code. More than once. It starts small. You add isLoading to show a spinner. Then isError for the error state. Then isEmpty because the empty state needs its own UI. Then isSuccess for the confirmation screen. Now you have four boolean props. And they fight each other. What happens when isLoading and isError are both true? Which one wins? Nobody knows. The component does not know either. You just hope the parent passes the right combination. This is Boolean Prop Hell. And it is sitting in most React codebases right now. Booleans feel simple but they hide impossible states. 4 boolean props = 16 possible combinations. Your component can only handle maybe 4 of them. The other 12 are bugs waiting to happen. Replace all of them with a single status prop. One value. One source of truth. No impossible combinations. The component always knows exactly what to render. This is how every serious component library handles it. There is a reason for that. When you find yourself adding another boolean prop, stop for a second. Ask: is this a new state or just a variation of an existing one? Most of the time you do not need a new prop. You need a better status model. Before and after in the screenshot below 👇 #ReactJS #Frontend #WebDev #JavaScript

Day 26 #100DaysOfCode 💻 Today I learned about Function, Component, State & Event in Next.js. 🔹 Function Functions are reusable blocks of code used to perform specific tasks. 🔹 Component In Next.js, everything is a component. It helps to break UI into reusable pieces. 🔹 State State is used to store dynamic data inside a component and re-render UI when data changes. 🔹 Event Events handle user interactions like clicks, input, form submission, etc. 💻 Code Snippet: "use client"; import { useState } from "react"; export default function Counter() { const [count, setCount] = useState(0); const handleClick = () => { setCount(count + 1); }; return ( <div> <h2>Count: {count}</h2> <button onClick={handleClick}>Increase</button> </div> ); } 🚀 Small reflection: Understanding these core concepts makes building dynamic and interactive apps much easier. #NextJS #ReactJS #WebDevelopment #JavaScript #Frontend #CodingJourney #Akbiplob

React Fiber: what it actually means for your code Most React devs know what Fiber is by name. Fewer know why it matters day to day. The old reconciler worked synchronously. State changes, React walks the whole tree, diffs it, writes to the DOM. One pass, no stopping. On a large component tree that blocked the main thread long enough for users to notice — animations stuttered, inputs lagged. Fiber fixed this by replacing the recursive call stack with a linked list. Each fiber is a plain object: component type, props, state, and pointers to parent, first child, next sibling. React now owns the execution, so it can pause whenever something more urgent comes in. Work splits into two phases, and this is the part worth understanding. The render phase builds a work-in-progress tree in memory without touching the DOM. React can stop mid-tree, hand control back to the browser for a keypress or a frame, then continue. If a higher-priority update arrives, it discards the in-progress work and starts over. The commit phase doesn't pause. Once the tree is ready, React applies all DOM mutations in one go. This part has to be synchronous — a half-applied DOM update breaks the UI. Here's where it connects to your actual code. useTransition works because React can genuinely deprioritize a state update and interrupt it if needed. Without Fiber, marking something as "non-urgent" would be meaningless — the old reconciler couldn't stop anyway. Suspense pauses a subtree while data loads for the same reason. React keeps the current tree on screen, builds the new one in the background, swaps when ready. Slow renders that only appear under load, inputs that lag when a big list re-renders, Suspense boundaries not behaving as expected — all of these trace back to how Fiber schedules and interrupts work. When something's off and the profiler gives you a confusing flamegraph, knowing that React works in two phases (one interruptible, one not) usually tells you where to look. #react #frontend #javascript #webdev #reactjs #frontenddevelopment #softwaredevelopment

How you structure your projects matters as much as the code itself! 📂🚀 Organization isn't just about finding files faster; it’s the foundation of scalability and maintainability. A well-structured project makes collaboration seamless and keeps technical debt to a minimum. In my recent work, I’ve been prioritizing a modular folder structure similar to this one. By clearly separating Features, Hooks, and Services, the codebase stays clean and easy to navigate even as the application grows in complexity. What does your favorite frontend folder structure look like? Let’s discuss in the comments! 👇 #WebDevelopment #Frontend #CleanCode #ReactJS #SoftwareEngineering #ProgrammingTips #JavaScript

You wrapped your component in React.memo… but it still re-renders 🤔 I ran into this more times than I’d like to admit. Everything looks correct. You’re using React.memo. Props don’t seem to change. But the component still re-renders on every parent update. Here’s a simple example: const List = React.memo(({ items }) => { console.log('List render'); return items.map(item => ( <div key={item.id}>{item.name}</div> )); }); function App() { const [count, setCount] = React.useState(0); const items = [{ id: 1, name: 'A' }]; return ( <> <button onClick={() => setCount(count + 1)}> Click </button> <List items={items} /> </> ); } When you click the button the List still re-renders. At first glance, it feels wrong. The data didn’t change… so why did React re-render? The reason is subtle but important: every render creates a new array. So even though the content is the same, the reference is different. [] !== [] And React.memo only does a shallow comparison. So from React’s perspective, the prop did change. One simple fix: const items = React.useMemo(() => [ { id: 1, name: 'A' } ], []); Now the reference stays stable and memoization actually works. Takeaway React.memo is not magic. It only helps if the props you pass are stable. If you create new objects or functions on every render, you’re effectively disabling it without realizing it. This is one of those bugs that doesn’t throw errors… but quietly hurts performance. Have you ever debugged something like this? 👀 #reactjs #javascript #frontend #webdevelopment #performance #reactperformance #softwareengineering #programming #coding #webdev #react #typescript