DEV Community: ParagNukte

🧩 Demystifying `useEffect`: The Sidekick You Never Knew You Misunderstood

ParagNukte — Tue, 08 Apr 2025 09:41:14 +0000

When I first started working with React Hooks, useEffect felt like this magical black box. You toss in some logic, slap on a dependency array, and just hope everything works.

Fast forward 3.5 years, and I’ve learned that truly mastering useEffect can make or break how clean, performant, and bug-free your components are.

In this post, I’ll walk you through what useEffect actually does, how to use it right, common pitfalls, and some patterns I personally use (and avoid) in production apps.

🧠 What is `useEffect`?

At its core, useEffect is how React lets you synchronize a component with external systems — network requests, subscriptions, DOM mutations, timers, and more.

Think of it as:

“Run this code after the render.”

The basic signature:

useEffect(() => {
  // side effect logic here

  return () => {
    // cleanup logic here (optional)
  };
}, [dependencies]);

The useEffect hook runs after the DOM has been painted. That’s important because unlike class components where componentDidMount and componentDidUpdate are separate, useEffect handles both — and more — depending on how you configure the dependency array.

🔄 Dependency Array Demystified

The second argument is where the real magic happens:

Dependency Array	What Happens
`[]`	Runs only once (after initial render)
`[a, b]`	Runs on initial render + whenever `a` or `b` change
(no array)	Runs on every render

// Example: Fetch on mount
useEffect(() => {
  fetchUser();
}, []);

☝️ Always be intentional with dependencies — it affects when your effect runs.

✅ Common Use Cases

Here are a few practical examples I use regularly:

1. 📡 Fetching data on mount

useEffect(() => {
  async function fetchData() {
    const res = await fetch('/api/data');
    const json = await res.json();
    setData(json);
  }

  fetchData();
}, []);

2. 🖱️ Subscribing to events

useEffect(() => {
  const handleResize = () => setWidth(window.innerWidth);
  window.addEventListener('resize', handleResize);

  return () => window.removeEventListener('resize', handleResize);
}, []);

3. 🧮 Re-running logic based on props/state

useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]);

⚠️ Common Pitfalls (I’ve Been There)

❌ Missing dependencies

React doesn’t “guess” what your effect depends on. If you use a variable in your effect but don’t include it in the dependency array, you’ll likely run into bugs — especially async or delayed ones.

✅ Enable ESLint’s react-hooks/exhaustive-deps rule

It’s a life-saver. Seriously.

❌ Doing too much in one `useEffect`

// This is not ideal
useEffect(() => {
  fetchData();
  setupSubscription();
  updateLocalStorage();
}, []);

This is a code smell. Each effect should have a single responsibility. Splitting them into multiple useEffect hooks keeps dependencies accurate and effects easier to debug.

💡 Best Practices

🔹 Keep effects focused: One responsibility per hook
🧹 Always clean up: Especially for timers, listeners, subscriptions
🧠 Use stable references: For objects/functions using useRef or useCallback
📏 Don’t define unnecessary functions inside useEffect unless they’re only needed there
🧰 Use custom hooks to extract and reuse common effects cleanly

⚡ Real-World Tip: `useEffect` ≠ Lifecycle Methods

A mistake I made early on was trying to map lifecycle methods 1:1 with hooks — thinking useEffect == componentDidMount or componentDidUpdate.

But that’s not how hooks work.

Instead, ask yourself:

“What side effect should run in reaction to this state or prop?”

This mental model leads to cleaner, more predictable code than trying to mimic class lifecycles.

🧪 Bonus: When Not to Use `useEffect`

Sometimes you don’t need useEffect at all. Some common cases:

✅ Derived state: Compute values directly in render or via useMemo
✅ DOM reads/writes before paint: Use useLayoutEffect instead
✅ Transforming props/state: Often better handled directly in JSX or helpers

// ❌ Don't do this
useEffect(() => {
  setX(props.value * 2);
}, [props.value]);

// ✅ Do this instead
const x = props.value * 2;

✨ Final Thoughts

useEffect is powerful — but only when used with care.

Once you stop thinking of it as a lifecycle substitute and start thinking of it as a reaction engine — something that runs when certain values change — things start to click.

So next time you reach for useEffect, pause and ask:

🔍 Am I tracking the correct dependencies?
✂️ Can I break this into smaller effects?
❓ Do I even need an effect?

Thanks for reading! 🙌

If you found this helpful or have your own useEffect war stories, I’d love to hear them. Drop a comment or share how you approach effects in your React apps!

How to Write Maintainable Code: A Developer’s Guide to Future-Proofing Your Work

ParagNukte — Wed, 02 Apr 2025 18:47:55 +0000

Introduction
Ever had to untangle a messy codebase that looked like a spaghetti junction of functions, global variables, and cryptic comments? If yes, you know the agony of dealing with unmaintainable code. Writing maintainable code isn't just a good practice—it's a necessity if you want scalable, collaborative, and bug-free development.

Having spent over three years in the industry, I’ve learned that maintainability isn’t just about writing "clean code"—it’s about structuring it in a way that ensures adaptability. So, let’s dive into the fundamentals that make code maintainable.

1. Keep Your Code Modular & Organized

A well-structured codebase is a lifesaver. The golden rule? “Write code as if the next person maintaining it is a highly stressed developer who has no idea what’s going on.” That future developer might even be you, months down the line.

Use meaningful folder structures based on features or functionality.
Follow separation of concerns by breaking code into well-defined modules.
Keep files small—each module should have a single responsibility.

💡 Example: In a React project, keep API calls separate from UI components. Instead of fetching data inside a component, move it to a dedicated service file.

// services/userService.js
export const fetchUserData = async () => {
   const response = await fetch("/api/user");
   return response.json();
};

2. Follow Consistent Naming Conventions

Names should be self-explanatory and not require a detective to decipher their intent. If your variables and functions make sense without comments, you’re doing it right.

✅ Good Practice:

function getUserProfileData(userId) { ... }
const isUserLoggedIn = true;

❌ Avoid:

function gupd(uid) { ... }
const check = true;

Stick to one naming convention (camelCase, PascalCase, or snake_case) across the codebase.
Be descriptive but concise—no need for fetchDataFromUserProfileTableInDatabase().

3. Write Self-Documenting Code (Reduce Comment Dependency)

Comments should explain the “why”, not the “what.” If you need excessive comments to make sense of your logic, the code might need refactoring.

✅ Example of meaningful comments:

// Using binary search instead of linear search for better performance.
function searchItem(arr, target) { ... }

❌ Avoid unnecessary comments:

// Loop through the array
for (let i = 0; i < arr.length; i++) { ... }

Instead of excessive commenting, focus on writing self-explanatory logic.

4. Embrace DRY (Don’t Repeat Yourself)

Avoid redundant code by reusing functions and keeping logic abstracted where necessary. If you find yourself copying the same lines multiple times, refactor.

🚀 Use Utility Functions

// utils/formatDate.js
export const formatDate = (date) => new Date(date).toLocaleDateString();

Instead of formatting dates manually in multiple places, call formatDate(date) whenever needed.

5. Prioritize Readability Over Cleverness

Sure, a one-liner ternary function might look cool, but if it takes another developer (or future you) extra time to decipher it, rethink your approach.

Instead of squeezing everything into one statement:

const userStatus = isAdmin ? (hasPermissions ? "Granted" : "Limited") : "Denied";

Use a clear, structured approach:

if (isAdmin) {
   userStatus = hasPermissions ? "Granted" : "Limited";
} else {
   userStatus = "Denied";
}

Readability always outweighs cleverness.

Conclusion: Think Like a Future Developer

Maintainability isn’t just about writing better code today—it’s about ensuring it’s usable, readable, and scalable for whoever interacts with it next. By keeping your code modular, self-documenting, and easy to read, you reduce future headaches while improving collaboration.

As developers, we’re not just solving problems—we’re designing systems that last. Write code today that even your future self will thank you for.