4 posts tagged with "react"

Purpose​

React 18 was released in 2022, and the Next.js App Router was released in 2023, making this a somewhat outdated investigation. However, while using the Next.js page router and app router, I found an article explaining the differences and reasons for the changes, particularly why the app router was introduced. This document summarizes my understanding of that article.

Story​

Before reading the article, consider the following scenarios:

Imagine you're at a job interview for a Frontend Developer position and are asked the following questions. Or perhaps you're in a meeting trying to convince your team to use the Next.js app router for a new or existing project. Or maybe you're contemplating which technology is more suitable between the Next.js page router and app router.

While simply stating that the app router is a new technology and advocating for its use as a Frontend Developer can be persuasive, understanding the answers to the questions below can provide a more compelling argument.

If you know the answers to these questions, you might not need to read the full text. However, if you want a more reliable source, you can refer to the React 18 Architecture introduction. If you only want the answers, you can skip to the Result.

The following text is a summary of my understanding, mixed with my opinions, after reading the Architecture article.

Introduction​

When mixing React's event handler method with vanilla Javascript's event handler method, event propagation may not work as intended. For example, in a structure like button1, button2, clicking button2 can trigger the event handler of button1 as well.

const buttonEl = document.getElementById('button1');
buttonEl.addEventListener('click', () => {
  console.log('button1 clicked');
});

const handleClick = (e) => {
  e.stopPropagation();
  console.log('button2 clicked');
};

return (
  <button id='button1'>
    <button id='button2' onClick={handleClick}>Click me</button>
  </button>
);

// When button2 is clicked
button2 clicked
button1 clicked

Solution​

Event propagation in React differs from that in vanilla Javascript because React handles event propagation using a delegation method. (comment)

In React (post React 17), event listeners are registered on the rootDOM. Therefore, event listeners within React propagate as expected according to the DOM structure, but vanilla Javascript event propagation may not behave as anticipated.

While it's best to avoid mixing the two types of events, sometimes it's unavoidable when using third-party libraries or handling parts of the code you can't control. In such cases, you must block event propagation according to the behavior of each method.

// Unify event listener to vanilla Javascript
const buttonEl = document.getElementById('button1');
buttonEl.addEventListener('click', () => {
  console.log('button1 clicked');
});

const button2El = document.getElementById('button2');
button2El.addEventListener('click', (e) => {
  e.stopPropagation();
  console.log('button2 clicked');
});

return (
  <button id='button1'>
    <button id='button2'>Click me</button>
  </button>
);

// Or
// Unify event listener to React
const handleClick1 = (e) => {
  console.log('button1 clicked');
};

const handleClick = (e) => {
  e.stopPropagation();
  console.log('button2 clicked');
};

return (
  <button id='button1' onClick={handleClick1}>
    <button id='button2' onClick={handleClick}>Click me</button>
  </button>
);

Introduction​

During a project, I encountered an issue where unnecessary re-renders were occurring.

The problem was not just rendering, but the fact that the DOM was being completely redrawn with each render. The culprit was the use of nested components in the code.

In this article, I will explain why you should avoid using nested components.

Cheat Sheet​

// Bad
const List = ({ hasWrapper, borderStyle, children }) => {
  const Border = () => {
    return <p style={borderStyle}>{children}</p>;
  }

  if (hasWrapper) {
    return (
      <Wrapper>
        <Border />
      </Wrapper>
    );
  }

  return <Border/>;
};

// Good
const List = ({ hasWrapper, borderStyle, children }) => {
  if (hasWrapper) {
    return (
      <Wrapper>
        <Border borderStyle={borderStyle}>
          {children}
        </Border>
      </Wrapper>
    );
  }

  return (
    <Border borderStyle={borderStyle}>
      {children}
    </Border>
  );
};

const Border = ({ borderStyle, children }) => {
  return <p style={borderStyle}>{children}</p>;
}

As shown above, you might use a nested component to reuse the code for Border and the props of List. However, in such cases, the children are unnecessarily repaint in the DOM with each render.

In React, when passing a function as component props, one needs to be careful with managing references to avoid unnecessary re-renders. Although most case we use useCallback to prevent unnecessary re-renders, I found an alternative solution sharing.

The code that inspired this article is radix-ui/primitives's useCallbackRef. This article will discuss the use cases and logic of useCallbackRef.

Below is the useCallbackRef code we are going to discuss. Can you guess in what situations it might be used?

// useCallbackRef.js
import { useRef, useEffect, useMemo } from 'react';

export function useCallbackRef(callback) {
  const callbackRef = useRef(callback);

  useEffect(() => {
    callbackRef.current = callback;
  });

  return useMemo(() => ((...args) => callbackRef.current?.(...args)), []);
}