DEV Community: Faith Kimani

Why useEffect? no pun intended lol!

Faith Kimani — Sat, 22 Feb 2025 08:55:57 +0000

Understanding useEffect in React: Why You Can't Just Call a Function

A Saturday Morning Realization

So it’s a Saturday morning, and I’m basking in the sun, flipping through the last pages of The Psychology of Money by Morgan Housel. I just finished the final chapter. Not gonna lie, I was just floating the whole time because I'm not a US citizen, so understanding their economy with that well-detailed history workflow was very unrelatable. I am in Kenya, so we have completely different economies, but of course, there are some similarities here and there.

Anyway, enough about my side quests. I am here to talk about useEffect in React. Reading the last chapter felt like reading useEffect for the first time. When I first encountered it, I didn’t understand why I needed it. Why couldn’t I just call a function inside my component like in regular JavaScript? Say, for example, it's an API call—why not write the function directly in my component? If you’re wondering the same thing, give yourself a little pat on the back because that's a great question. What you need to understand is, React's rendering process is different from the normal execution of JavaScript functions. Let’s break it down.

The Problem: Why Not Just Call a Function?

In JavaScript, you can normally define and call functions inside your code. So why not just do this inside a React component?

function App() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState("");

  fetch("https://api.example.com/data")
    .then((response) => response.json())
    .then((data) => console.log(data));

  return (
    <div>
      <button onClick={() => setCount((count) => count + 1)}>
        I've been clicked {count} times
      </button>
      <input
        type="text"
        placeholder="Type away..."
        value={text}
        onChange={(e) => setText(e.target.value)}
      />
    </div>
  );
}

🚨 Issue: Every time the component re-renders (due to state changes like count or text updates), the API call runs again. This leads to unnecessary network requests, which slow down your app.

The Waiter Analogy: Explaining Multiple API Calls

Think of this problem like a restaurant scenario:

Without `useEffect`: The Overeager Waiter

Imagine you walk into a restaurant and place your order. Now imagine that every time you pick up your spoon or sip water, the waiter rushes back to the kitchen and places another order for you—even though you haven’t asked for it. By the end of the meal, you have ten unnecessary plates on your table.

That’s what happens when you place an API call inside a React component without useEffect. React re-renders every time state changes, triggering the API call multiple times when it’s not needed.

With `useEffect`: The Well-Trained Waiter

Now, imagine a properly trained waiter who only takes your order once when you arrive. They don’t keep reordering unless you explicitly ask for something new.

That’s what useEffect does—it ensures that side effects like API calls only run when needed, preventing unnecessary re-fetching.

Enter `useEffect`: The Solution

To control when our API call runs, we use useEffect. It consists of two parts:

A callback function that contains the logic for your side effect.
A dependency array that determines when the effect should re-run.

Basic Structure:

useEffect(() => {
  // Side effect logic
}, [dependencies]);

Example: Fixing Our API Call

import { useEffect, useState } from "react";

function MyComponent() {
  const [data, setData] = useState(null);
  const [count, setCount] = useState(0);
  const [text, setText] = useState("");

  useEffect(() => {
    fetch("https://api.example.com/data")
      .then((response) => response.json())
      .then((data) => setData(data));
  }, []); // Runs only once when the component mounts

  return (
    <div>
      <div>{data ? JSON.stringify(data) : "Loading..."}</div>
      <button onClick={() => setCount((count) => count + 1)}>
        I've been clicked {count} times
      </button>
      <input
        type="text"
        placeholder="Type away..."
        value={text}
        onChange={(e) => setText(e.target.value)}
      />
    </div>
  );
}

✅ Now, the API call only runs once, just like a well-trained waiter taking your order.

Controlling When `useEffect` Runs

You can control useEffect's behavior using the dependency array:

useEffect(() => {}) (No dependency array) → Runs on every render.
useEffect(() => {}, []) (Empty dependency array) → Runs only once when the component mounts.
useEffect(() => {}, [variable]) (Dependency array with values) → Runs whenever the specified variable changes.

Example: Fetch Data When a State Changes

useEffect(() => {
  fetch(`https://api.example.com/data?page=${page}`)
    .then((response) => response.json())
    .then((data) => setData(data));
}, [page]); // Runs only when `page` state changes

Cleaning Up: Avoiding Memory Leaks

Some side effects, like event listeners or timers, need to be cleaned up to prevent memory leaks. useEffect allows you to return a cleanup function:

useEffect(() => {
  const handleResize = () => console.log("Window resized");
  window.addEventListener("resize", handleResize);

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

✅ Now, the event listener is removed when the component unmounts.

What Are Side Effects?

If you're wondering what I mean by side effects, let's break it down:

In a pure function (ideal in React), given the same inputs, you always get the same output. Side effects are actions that occur outside of a component's rendering logic. These include:

Fetching data from an API
Modifying the DOM directly
Setting up event listeners
Using timers
Managing subscriptions

Wrapping Up: Full Circle Moment

Just like I pushed through The Psychology of Money despite feeling disconnected from some parts, learning useEffect felt unnecessary at first—until I understood the why behind it. Now, I see it as an essential tool for managing side effects in React.

Key Takeaways:

✅ Without useEffect, API calls run on every render, leading to performance issues.
✅ useEffect lets you control when a function runs, avoiding unnecessary re-renders.
✅ Using the dependency array helps optimize performance.
✅ Cleanup functions prevent memory leaks.

So next time you see an API call inside a React component, think of our overeager waiter. And remember—React re-renders more than you think! 😉

React Information Flow

Faith Kimani — Mon, 17 Feb 2025 20:54:28 +0000

Information Flow in React

Ever wondered how information flows in a React app? How do we pass data between siblings or from parent to child? What if I want to update state in the parent component due to an event in a child?

Understanding Information Flow

In React, data flows uni-directionally—from parent to child. This means that components pass data down via props. However, if a child component needs to modify the parent's state, it does so using a callback function passed as a prop.

Sibling components cannot communicate directly. Instead, data should be lifted to the nearest common parent, which then passes it down as props. This technique is called lifting state up.

fig1: Illustrates Information flow in React

Key Principles:

Props: Used to pass data down from parent to child.
Callbacks: Used to pass data up from child to parent.
State Lifting: When siblings need to share data, state should be stored in their closest common parent.
State Management: For larger applications, tools like Redux or React Context can help manage state globally.

Example 1: Passing Data from Parent to Child

function Parent() {
  const [message, setMessage] = React.useState("Hello from Parent!");

  return <Child message={message} />;
}

function Child({ message }) {
  return <p>{message}</p>;
}

Here, the Parent component holds a state variable message, which is passed down to the Child component via props.

Example 2: Passing Data from Child to Parent (Callback Functions)

function Parent() {
  const [color, setColor] = React.useState("blue");

  function changeColor() {
    setColor(color === "blue" ? "red" : "blue");
  }

  return <Child onChangeColor={changeColor} />;
}

function Child({ onChangeColor }) {
  return <button onClick={onChangeColor}>Change Parent Color</button>;
}

Here, the onChangeColor function is passed down from Parent to Child as a prop. When the child button is clicked, the function is invoked, updating the parent’s state.

Example 3: Synchronizing State Between Siblings

Since siblings cannot directly share state, we lift the state up to their common parent.

function Parent() {
  const [childColor, setChildColor] = React.useState("white");

  function handleColorChange() {
    const newColor = childColor === "white" ? "yellow" : "white";
    setChildColor(newColor);
  }

  return (
    <div>
      <Child color={childColor} onChangeColor={handleColorChange} />
      <Child color={childColor} onChangeColor={handleColorChange} />
    </div>
  );
}

function Child({ color, onChangeColor }) {
  return <div onClick={onChangeColor} style={{ backgroundColor: color, padding: '20px', margin: '5px' }}>Click Me</div>;
}

Here, clicking on any Child updates the state in Parent, which in turn updates both Child components.

Conclusion

Data flows down via props.
Data flows up via callback functions.
Sibling components share data through lifting state up.
For complex state management, consider React Context or Redux.

By following these principles, we can build efficient and scalable React applications with clear and predictable data flow.

Resources:
Lifting State Up.

Arrow Functions vs Function expressions

Faith Kimani — Mon, 20 Jan 2025 05:29:44 +0000

Introduction

Functions are the lifeblood of JavaScript, sort of like the baristas of the code world serving up your logic in neat little cups. But when it comes to brewing up functions, you pretty much have two big options: classic function expressions and sleek-and-modern arrow functions.

I mean, have you ever wondered how they differ? Is one faster, cooler, or plotting secretively against the other? Let's dive in and find out.

The Syntax Smackdown

All right, let's get things rolling with a small syntax comparison. Behold - the arrow function:

const functionName = (parameter1, parameter2) => "This is an implicit return";

It's like taking an anonymous function and giving it a cool alias. Notice something? No function keyword. No fluff. Just action. The magic in action here is called implicit return, which lets you bypass curly braces {} and the return keyword—if it's just a single expression.

Here's an example:

const playMovie = movie => "Playing some " + movie;
console.log(playMovie("action")); // "Playing some action"

One line, one return, zero drama.

But wait—what happens when your function needs to do a bit more heavy lifting? Enter the block body:

const playMusic = music => {
  return "Playing some " + music;
};
console.log(playMusic("Jazz")); // "Playing some Jazz"

If you forget the return keyword here, JavaScript will just shrug and say, "Undefined it is!"

const playMusic = music => {
``
"Playing some " + music;
};
console.log(playMusic("Jazz")); // undefined

So remember, curly braces come with strings attached: you need to explicitly return something.

The Parentheses Debate

Arrow functions also keep things minimal when dealing with a single parameter:

const playMovie = movie => "Playing some " + movie;

No need for parentheses—it's shorthand heaven! But as soon as there's more than one parameter, you're back to wrapping things up:

const readBooks = (book1, book2) => `I read '${book1}' and '${book2}'`;
console.log(readBooks("The Old Man and the Sea", "1984")); // "I read 'The Old Man and the Sea' and '1984'"

Try removing those parentheses there, and JavaScript will throw a Syntax Error, because apparently, it doesn't like ambiguity.

const readBooks = book1, book2 => `I read '${book1}' and '${book2}'`;
// Syntax Error

So, Where Do Arrow Functions Shine?

Arrow functions are the cool kids in JavaScript—they really come alive with modern use cases such as array iteration. For example:

const numbers = [1, 2, 3, 4];
numbers.map(num => console.log(`This is ${num}`));

Concise, readable, and just what you need when you want a quick function that does its thing once and then is discarded. They are almost like the hustle culture response to JavaScript: "Do more with less!"

When to Use Regular Functions

While arrow functions are great for simplicity, there are times when good old regular functions are your best bet:

Function Hoisting

Regular functions are hoisted, meaning you can call them before they’re defined in your code:

sayHello(); // "Hello, world!"

function sayHello() {
  console.log("Hello, world!");
}

Arrow functions, on the other hand, are not hoisted. Try calling one before its declaration, and JavaScript will throw a fit.

Methods

When defining methods on objects, regular functions are the way to go. Why? Because they get their own this context, which points to the object they belong to.

const person = {
  name: "Alice",
  greet: function () {
    return `Hello, I’m ${this.name}`;
  }
};

console.log(person.greet()); // "Hello, I’m Alice"

Arrow functions don’t have their own this. Instead, they inherit this from their surrounding scope, which can lead to unexpected results:

const person = {
  name: "Alice",
  greet: () => `Hello, I’m ${this.name}`
};

console.log(person.greet()); // "Hello, I’m undefined"

Unless you’re specifically looking for a this context from the outer scope, stick to regular functions for object methods.

A Quick Note on the `this` Keyword

One of the most distinctive features of arrow functions is that they bind this. Whereas normal functions have their own this, arrow functions borrow theirs from their surroundings. It's almost like they never RSVP'd to the function party so now they just chill with their closest lexical environment.

That makes them ideal for cases that require preserving context, such as working with class methods or callbacks in modern frameworks.

Wrap-Up

Well, there you have it: the showdown between arrow functions and function expressions. One of the standout differences is that arrow functions don't use the function keyword. They also offer an implicit return for single expressions, automatically inferring the return value without requiring the return keyword or curly braces {}. However, when using a block body with curly braces, you must include an explicit return to avoid unexpected results.

Another distinction lies in parameter handling: with a single parameter, parentheses can be omitted for a cleaner look. But if there are multiple parameters, parentheses become mandatory to ensure clarity and avoid syntax errors.

It's not a matter of which one wins the contest; it is about picking the right tool for the job. As I like to think:

Arrow functions are the shots of espresso in JavaScript: strong, fast, and to the point. Function expressions? They're cappuccino classic: reliable, full-bodied, perfect for when sipping every detail.

Now go out there and function like a pro!