DEV Community: Ogasawara Kakeru

React.js ~useEffect~

Ogasawara Kakeru — Sat, 11 Jul 2026 00:55:13 +0000

Before thinking about useEffect, you have to understand purelity of component. This is an essential concept of React.

React is assumed as a pure function.

The pure function is the function that does nothing but calculation.
Here are features bellow:

Focuses on it's own bussiness. This doesn't modify existing object or valuable.
The same input produces the same output.Given the same input, a pure function always returns the same result.

React component is a function as well. you can apply those features to React component.

It is idempotent
It has no side effects during rendering
It does not modify anything other than local values

As a general rule, components should be pure. In React, this means that components do not affect anything outside the component and must always return the same output given the same input.

The inputs for a React component are props, state, and context, and the output is JSX.

const Counter = ({ count }: { count: nubmer }) => {
  return <div>Count: {count}</div>;
};

The component above is a simple component that accepts an input (prop) called count and displays it. Since this is a pure component, it always returns the same output when given the same count as an input (prop).
On the other hand, the following code is not a pure component.

let count = 0;

const Counter = () => {
  count = count + 1;
  return <div>Count: {count}</div>;
};

The component above modifies the count variable outside the component during rendering. As a result, if the component is called multiple times, the output will differ even though the input remains the same.
Such impure components can cause unexpected behavior and lead to bugs, so they should be avoided.
As we’ve seen so far, purity is an important concept in React. However, in real-world programming, side effects—such as accessing global variables, modifying the DOM, or updating data—are sometimes necessary.
While the component rendering process should always be pure, it’s impossible to completely eliminate side effects in programming. Therefore, we need a way to safely handle side effects while keeping the rendering process pure.

React provides two main methods for safely handling side effects:

Event handlers: Functions that React calls when a user action is triggered
useEffect: A React hook for handling side effects associated with rendering

Of the two, side effects typically belong in event handlers. Since this article focuses on useEffect, we won’t go into detail about event handlers here, but that doesn’t mean useEffect is inherently superior to event handlers for handling side effects.
Instead, keep in mind that useEffect is a last resort.

React.js ~useEffect event handler~

Ogasawara Kakeru — Thu, 02 Jul 2026 21:30:00 +0000

In case you want to manipulate DOM that can not be handled by React, useEffect is required. React is used for managing UI. So it is proper to use useEffect for manipulating DOM.

const Component = () => {
  const [h, setH] = useState(0);

  useEffect(() => {
    const handler = () => {
      setH(h => (h + 1) % 360);
    };
    window.addEventListener("pointermove", handler);
    return () => {
      window.removeEventListener("pointermove", handler);
    };
  }, []);

  return (
    <div
      style={{
        backgroundColor: `hsl(${h}, 100%, 50%)`,
        width: "100px",
        height: "100px"
      }}
    />
  );
};

React.js ~The principle of useEffect ~

Ogasawara Kakeru — Tue, 30 Jun 2026 01:17:31 +0000

I think the princile of React is that React is a UI library. React manages UI, but other roles. A developer who thinks React is difficult does everything in React. Application logic or state management is not React's role. You should manage them by using a third-party library such as Zustand.

This statement can be applied to useEffect. useEffect is used to manage UI, not others.

Another princile is that React is a component based lirary. React maneges UI through a component. So, codebases in a component should be maneged in the component including useEffect. In other words, it’s not a good idea to write logic that isn’t confined to that component, and useEffect is no exception.

In React, a component is by turns mounted and unmounted. When a conponent is unmounted, The effect of the componen that the component affected UI must be disappered, because the component disappers. Because of that, as a principle of coding, it can be said that useEffect without cleanup function is invalid. useEffect without cleanup function doesn't restore the effect of the component. This breaks the principle of the component based coding.

React.js ~The best practice for conditional statement~

Ogasawara Kakeru — Fri, 26 Jun 2026 00:27:46 +0000

We tend to write React as functional programming because the functional component is the mainstream.
In this era, one of the issues we often encounter is conditional statements. There are a variety of conditional statements, such as if, switch, and ternary operator.
We confuse when to use them properly.

Assign the result of the conditional statement into a variable
This makes it easy to read, test, and modify codebases.

The representative case is ternary operator

const userName = user ? user.name : 'No user found';

Of course, we can write the code another way.

const point = 80;
let result;

if (point >= 70) {
  result = 'passed';
} else {
  result = 'failed';
}

console.log(result);
// passed

In this way, we can not ensure the immutability of let, and this section with the conditional branch is written in a procedural style.

To solve this issue, we have to wrap this in a function.

const judge = (point: number) => {
  if (point >= 70) {
    return 'passed';
  }

  return 'failed';
};

In addition to wrapping that statement,
I suggest that you use early return to save the else statement.

Do not write conditional statements in the return value of tsx (the UI rendering portion)

** When there is only a single conditional statement, or there is no need for any execution in the conditional statement.

Let's use the ternary operation simply.

import { FC } from 'react';
import { useQuery } from '@tanstack/react-query';
import getUser from 'domains/getUser';

type Props = {
  userId: number;
};

const Profile: FC<Props> = (props) => {
  const { userId } = props;
  const getSpecificUser = async () => {
    const specificUser = await getUser(userId);

    return specificUser;
  };
  const { data: user } = useQuery(['user', userId], getSpecificUser);

  const userName = user ? user.name : 'User not found';

  return <p>User：{userName}</p>;
};

export default Profile;

const userName = user ? user.name : 'User not found';

In this statement, you only have to watch user, and you don't have any other execution.

Avoid writing this code in the <p> tag.

return <p>User：{user ? user.name : 'User not found'}</p>;

This code is unreadable. And this makes JSx complex to understand.
You have to separate logic from UI.

If conditional statements are later or more than 3 statements.
In this case, you had better use ifstatement.

/* eslint-disable no-nested-ternary */
import { FC } from 'react';
import { useQuery } from '@tanstack/react-query';
import getUser from 'domains/getUser';

type Props = {
  userId: number;
};

const Profile: FC<Props> = (props) => {
  const { userId } = props;
  const getSpecificUser = async () => {
    const specificUser = await getUser(userId);

    return specificUser;
  };
  const { data: user } = useQuery(['user', userId], getSpecificUser);

  const userName = user ? user.name : 'User not found';
  const genderColor = user ? (user.gender === 'male ? 'blue' : 'pink') : '';

  return <p className={genderColor}>User：{userName}</p>;
};

export default Profile;

It is unreadable if you write the ternary operator.
In this case, you had better wrap two layers of statements.

import { FC } from 'react';
import { useQuery } from '@tanstack/react-query';
import getUser from 'domains/getUser';

type Props = {
  userId: number;
};

const Profile: FC<Props> = (props) => {
  const { userId } = props;
  const getSpecificUser = async () => {
    const specificUser = await getUser(userId);

    return specificUser;
  };
  const { data: user } = useQuery(['user', userId], getSpecificUser);

  const userName = user ? user.name : 'User not found';
  const genderColor = () => {
    if (!user) {
      return '';
    }

    if (user.gender === 'male') {
      return 'blue';
    }

    return 'pink';
  };

  return <p className={genderColor()}>User：{userName}</p>;
};

export default Profile;

You can execute conditional statements within genderColor
In fact, you don't have to write code as a nest with return.
This is another merit of extracting a responsibility from the codebase.

When you want to display another UI
You should switch UI with if statement.

import { FC } from 'react';
import { useQuery } from '@tanstack/react-query';
import getUser from 'domains/getUser';

type Props = {
  userId: number;
};

const Profile: FC<Props> = (props) => {
  const { userId } = props;
  const getSpecificUser = async () => {
    const specificUser = await getUser(userId);

    return specificUser;
  };
  const { data: user } = useQuery(['user', userId], getSpecificUser);

  if (!user) {
    return <p>User notfound</p>;
  }

  const { name, gender, age } = user;
  const genderColor = gender === 'male' ? 'blue' : 'pink';

  return (
    <div className={genderColor}>
      <p>User：{name}</p>
      <p>Sex：{gender}</p>
      <p>Age：{age}</p>
    </div>
  );
};

export default Profile;

You can define UI that is displayed if user is undefined.

React.js ~useState Antipatterns~

Ogasawara Kakeru — Sun, 21 Jun 2026 01:06:41 +0000

1. Consider grouping related conditions together

Before

  const [x, setX] = useState(0);
  const [y, setY] = useState(0);

  const handlePointerMove = (e) => {
    setX(e.clientX);
    setY(e.clientY);
  };
  return (
      <div
        onPointerMove={handlePointerMove}
        style={{
          width: "100vw",
          height: "100vh",
        }}
      />
  );

After

 const [position, setPosition] = useState({ x: 0, y: 0 });

 const handlePointerMove = (e) => {
    setPosition({
      x: e.clientX,
      y: e.clientY,
    });
  };
  return (...
  );

Before

const [userName, setUserName] = useState("");
const [userAge, setUserAge] = useState(0);

After

const [userInfo, setUserInfo] = useState({name:"",age:0});

2. Avoid declaring conflicting states

Before

export default function Form() {
  const [text, setText] = useState('');
  const [isSubmitting, setSubmitting] = useState(false);
  const [isSubmit, setIsSubmit] = useState(false);

  async function handleSubmit(e) {
    e.preventDefault();
    isSubmitting(true);
    await sendMessage(text);
    isSubmitting(false);
    setIsSubmit(true);
  }

  if (isSubmit) {
    return <h1>I appreciate</h1>
  }

  function sendMessage(text) {
    return new Promise(resolve => {
    setTimeout(resolve, 2000);
   });
  }

  return (
    <form onSubmit={handleSubmit}>
      <textarea
        disabled={isSending}
        value={text}
        onChange={e => setText(e.target.value)}
      />
      <br />
      <button
        disabled={isSending}
        type="submit"
      >
        Submit
      </button>
      {isSubmitting && <p>Submitting...</p>}
    </form>
  );
}

After

export default function Form() {
  const [text, setText] = useState('');
  const [status, setStatus] = useState('TYPING');

  async function handleSubmit(e) {
    e.preventDefault();
    setStatus('SUBMITTING');
    await sendMessage(text);
    setStatus('SUBMITTED');
  }

  const isSending = status === 'SUBMITTING';
  const isSent = status === 'SUBMITTED';

　 return (...
  );
}

isSubmit and isSubmitting are conflicting and make it difficult to handle these states as it gets complex.
You have to group them into a single state.

3. Avoid redundant use

export default function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');
  const [fullName, setFullName] = useState('');

  function handleFirstNameChange(e) {
    setFirstName(e.target.value);
    setFullName(e.target.value + ' ' + lastName);
  }

  function handleLastNameChange(e) {
    setLastName(e.target.value);
    setFullName(firstName + ' ' + e.target.value);
  }

  return (
    <>
      <label>
        First name:
        <input
      name="firstName"
          value={firstName}
          onChange={handleFirstNameChange}
        />
      </label>
      <label>
        Last name:
        <input
      name="lastName"
          value={lastName}
          onChange={handleLastNameChange}
        />
      </label>
      <p>
        FullName: <span>{fullName}</span>
      </p>
    </>
  );
}

The fullName can be calculated when rendering by firstName + lastName.

  const [userName, setUserName] = useState({ firstName: "", lastName: "" });
  const fullName = userName.firstName + " " + userName.lastName;

  const handleUserNameChange = (e) => {
    setUserName({ ...userName, [e.target.name]: e.target.value });
  };

And props should not be held in the state.

function Text({ children, color }) {
  const [textColor] = useState(color);

  return <h1 style={{ color: textColor }}>{children}</h1>;
}

export default function Example() {
  const [color, setColor] = useState("red");

  return (
    <div>
      <p>
        Select Color
        <select value={color} onChange={(e) => setColor(e.target.value)}>
          <option value="red">Red</option>
          <option value="blue">Blue</option>
          <option value="green">Green</option>
        </select>
      </p>
      <Text color={color}>Color will be changed</Text>
    </div>
  );
}

The color seems to change at a glance, but doesn't change.
Because useState is initialized when first rendering.

Fixed

function Text({ children, color }) {
  const textColor = color;

  return <h1 style={{ color: textColor }}>{children}</h1>;
}

4. Avoid declaring the same state multiple times

const initialItems = [
  { id: 1, title: "taskA" },
  { id: 2, title: "taskB" },
  { id: 3, title: "taskC" },
];

export default function TaskList() {
  const [tasks, setTasks] = useState(initialItems);
  const [selectedTask, setSelectedTask] = useState(tasks[0]);

  function handleTaskChange(id, e) {
    setTasks(tasks.map((task) => (task.id === id ? { ...task, title: e.target.value } : task)));
    setSelectedTask((task) => (task.id === id ? { ...task, title: e.target.value } : task));
  }

  return (
    <>
      <h2>Task List</h2>
      <ul>
        {tasks.map((task, index) => (
          <li key={task.id}>
            <input
              value={task.title}
              onChange={(e) => {
                handleTaskChange(task.id, e);
              }}
            />
            <button
              onClick={() => {
                setSelectedTask(task);
              }}
            >
              Select
            </button>
          </li>
        ))}
      </ul>
      <p>Today's task {selectedTask.title}</p>
    </>
  );
}

The task and the selectedTask handle the same data.
When you edit the task, you have to update selectedTask.

So, fix the codebase to calculate the selectedTask by id

function TaskList() {
  const [tasks, setTasks] = useState(initialItems);
  const [selectedTaskId, setSelectedTaskId] = useState(0);

  function handleTaskChange(id, e) {
    setTasks(tasks.map((task) => (task.id === id ? { ...task, title: e.target.value } : task)));
  }

  const selectedTask = tasks.find((task) => task.id === selectedTaskId);

  return (
    <>
      <h2>Task List</h2>
      <ul>
        {tasks.map((task) => (
          <li key={task.id}>
            <input
              value={task.title}
              onChange={(e) => {
                handleTaskChange(task.id, e);
              }}
            />
            <button
              onClick={() => {
                setSelectedTaskId(task.id);
              }}
            >
              Select
            </button>
          </li>
        ))}
      </ul>
      <p>Today's Task {selectedTask.title}</p>
    </>
  );
}

React.js ~The principle of the hook~

Ogasawara Kakeru — Wed, 17 Jun 2026 22:13:52 +0000

Use only one useEffect per page

const [foo, setFoo] = useState("foo");

useEffect(() => {
  setFoo("bar");
});

useEffect(() => {
  setFoo("baz");
});

It is not clear which state would be updated.

Good

const [foo, setFoo] = useState("foo");

const onClickBar = () => setFoo("bar");

const onClickBaz = () => setFoo("baz");

Instead, you should do away with the useEffect to prevent multiple updates.

In many cases, useEffect is not required. In reality, you use only one useEffect per page.

Events that occur in the browser are as follows:

Page navigation, initial render, Path sifting, and so on.
User events: click, tap.
EventListner event: Connecting or disconnecting from the network.
Event from server: WebSocket, real-time update from Firebase.

User events are not only required in useEffect. While most applications require page navigation or user events.
As a result, in many cases, useEffect requires page navigation.

Add a comment on the dependencies array in useEffect

Bad: Load function

const [isLoaded, setIsLoaded] = useState<boolean>(false);
const [res, setRes] = useState();

const load = useCallback(async () => {
    try {
        if (isLoaded) {
            return;
        }
        const fooApiRes = await FooApi();
        setRes(fooApiRes);
    } finally {
        setIsLoaded(true);
    }
}, [isLoaded]);

useEffect(() => {
    load();
}, [load]);

If the props is a boolean, you should divide the component into different components

Bad: A component includes both create and update

const DialogContents: React.FC<{isAdd: boolean}> = ({
    isAdd: boolean,
}) => {
    ...
    const onSubmit = useCallback(async () => {
        if (isAdd) {
            await FooRegisterApi();
            return;
        }
        await FooUpdateApi();
    }, []);

    return (
        <>
            <form onSubmit={onSubmit}>
                <label>Name</label>
                <input value={name} onChange=>{onChangeName}/>
                <label>ID</label>
                <input disabled={!isAdd} value={id} onChange=>{onChangeId}/>
                {isAdd &&
                    <label>Email</label>
                    <input value={email} onChange=>{onChangeEmail}/>
                    <label>PhoneNumber</label>
                    <input value={phoneNumber} onChange=>{onChangePhoneNumber}/>
                }
            </form>
        </>
    )
}

This codebase increases conditional statements as the app grows.

Good: Divide the component into two components, such as a create component and an update component.

const RegisterDialogContents: React.FC = () => {
    ...
    const onSubmit = useCallback(async () => {
        await FooRegisterApi();
    }, []);

    return (
        <>
            <form onSubmit={onSubmit}>
                <label>Name</label>
                <input value={name} onChange=>{onChangeName}/>
                <label>ID</label>
                <input value={id} onChange=>{onChangeId}/>
                <label>Email</label>
                <input value={email} onChange=>{onChangeEmail}/>
                <label>PhoneNumber</label>
                <input value={phoneNumber} onChange=>{onChangePhoneNumber}/>
            </form>
        </>
    )
}

const UpdateDialogContents: React.FC = () => {
    ...
    const onSubmit = useCallback(async () => {
        await FooUpdateApi();
    }, []);

    return (
        <>
            <form onSubmit={onSubmit}>
                <label>Name</label>
                <input value={name} onChange=>{onChangeName}/>
                <label>ID</label>
                <input disabled={true} value={id} onChange=>{onChangeId}/>
            </form>
        </>
    )
}

React.js ~Clean Code Practical Use~

Ogasawara Kakeru — Sun, 14 Jun 2026 01:50:55 +0000

1. The codebase should be created for concentrating on <>JSX Section</>

-The JSX section can often be modified after release.

Separate a data-fetching section from the view section.

// NG🤔 You can not comprehend the important point intuitively.
const Area = () => {
  const [user, setUser] = useState();

  useEffect(() => {
    const fetchUser = async (): Promise<void> => {
      const response = await GetUser();
      setUser(response);
    };
    fetchUser();
  }, []);

  return <>{user.name}</>;
};

// Good😎 Separate a data-fetching section from the view section.
const useUser = (): User | undefined => {
  const [user, setUser] = useState<User>();
  useEffect(() => {
    const fetchUser = async (): Promise<void> => {
      const response = await GetUser();
      setUser(response);
    };
    fetchUser();
  }, []);

  return user;
};

// A component for showing data.
const Area = () => {
  const user = useUser();

  return <>{user?.name}</>;
};

2. Don't use too many useState for data-input

// NG🤔 What is going to happen if the `input` element continues to increase...
const UserForm = () => {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');

  const changeName = (e) => setName(e.target.value);
  const changeEmail = (e) => setEmail(e.target.value);

  return (
    <form onSubmit={onSubmit}>
      <input type='text' value={name} onChange={changeName} />
      <input type='text' value={email} onChange={changeEmail} />
      <input type='submit' value='Submit' />
    </form>
  );
};

// Good😎 Manage submit data in a user object.
const UserForm = () => {
  const [user, setUser] = useState({ name: '', email: '' });

  const changeName = (e) =>
    setUser((state) => ({ ...user, name: e.target.value }));

  const changeEmail = (e) =>
    setUser((state) => ({ ...user, email: e.target.value }));

  return (
    <form onSubmit={onSubmit}>
      <input type='text' value={name} onChange={changeName} />
      <input type='text' value={email} onChange={changeEmail} />
      <input type='submit' value='Submit' />
    </form>
  );
};

// Cool😎: Take advantage of useForm
const UserForm = () => {
   const { register} = useForm();

  return (
    <form onSubmit={onSubmit}>
      <input {...register("name")} />
      <input {...register("email")} />
      <input type='submit' value='Submit' />
    </form>
  );
};

3. Insert a default value to an optional one

type Props = {
  name: string;
  isDisplayNone?: boolean; // An optional props
};

// NG🤔: Defined as isDisplayNone = undefined
const UserCard: FC<Props> = ({ name, isDisplayNone }) => (
  <div style={{ display: isDisplayNone ? 'none' : 'block' }}>{name}</div>
);

// Good😎: Defined as isDisplayNone = false 
const UserCard: FC<Props> = ({ name, isDisplayNone = false }) => (
  <div style={{ display: isDisplayNone ? 'none' : 'block' }}>{name}</div>
);

//　When showing isDisplayNone　undefined -> false
<UserCard name='name' />;
//　When not showing isDisplayNone true
<UserCard name='name' isDisplayNone />;

4. Pay attention to import statement

/* NG🤔
├── Layout
    ├── Header.tsx
    └── Footer.tsx
*/
// page.tsx import files separately
import Header from './Layout/Header';
import Footer from './Layout/Footer';

/* Good🥴
├── Layout
    ├── Header.tsx
    ├── Footer.tsx
    └── index.tsx
*/
// index.tsx
export { default as Header } from './Header';
export { default as Footer } from './Footer';

// page.tsx　import as a chunk
import { Footer, Header } from './Layout';

Allow importing from the same path everywhere.

// NG:
import { Footer, Header } from '../../../../Layout';

// Good:😎
import { Footer, Header } from '@components/Layout';

5. Make use of array methods

const data = [1,2,10]
const isIncludedNumber2 = data.includes(2);
const isIncludedNumber2Or3 = data.some((item) => item === 2 || item === 3);
const number3= data.find((item) => item === 3);
const numbersLargerThan2 = data.filter((item) => item > 2);
const totalNumber = data.reduce((sum, num) => sum + num, 0);

6. Centerize how to manage unique values of the service

If values defined specifically for the service are written directly into the code, it becomes difficult to understand.
Is the code written in a way that prevents misunderstandings?

// NG🤔 status: What does the 0 mean?
const CheckStatus = (status: number) => {
  if (status === 0) {
    return true;
  }
  return false;
};

// Good🥴
const Status = {
  Invalid: 0,
  Valid: 1,
} as const;

type StatusLiteral = typeof Status[keyof typeof Status]; // 0 | 1

const CheckStatus = (status: StatusLiteral) => {
  if (status === Status.Invalid) {
    return true;
  }
  return false;
};

React.js ~Clean Code Intermediate~

Ogasawara Kakeru — Wed, 10 Jun 2026 22:08:27 +0000

1. Passing values simply
1-1. Receiving: Receive values as all in one.

const userInfo = {
  username: 'Jnjdunk',
  address: 'Tokyo',
  favorite: 'Travel',
};

// NG
const username = userInfo.username;
const address = userInfo.address;
const favorite = userInfo.favorite;

// 🥴 Good
const { username, address, favorite } = userInfo;

1-2. Insert: Use the abbreviation of the object.

// NG
const profile = {
  username: username,
  address: address,
  favorite: favorite,
  age: 88,
};

// 🥴 Good
//Variables must be configured above, and a value that has a specific value must be configured below.
const profile = {
  username,
  address,
  favorite,
  age: 88,
};

// 😎 Best
const age = 88;
const profile = {
  ...userInfo,
  age,
};

2. The function Component is more readable than the others

// NG　class component
class UserArea extends React.Component {
  render() {
    return <h1>Hello, {this.props.username}</h1>;
  }
}

// 🥴 Good　
const UserArea = (props) => {
  return <h1>Hello, {props.username}</h1>;
};

3. useEffect must have a single responsibility

// NG
useEffect(() => {
  const getApi1 = async () => {
    const response = await api('classinfo');
    order1(response);
  };

  const getApi2 = async () => {
    const response = await api('userinfo');
    order2(response);
    order3(response);
  };
  getApi1();
  getApi2();
}, []);

// 🥴 Good
useEffect(() => {
  const getApi = async () => {
    const response = await api('classinfo');
    order1(response);
  };
  getApi();
}, []);

useEffect(() => {
  const getApi = async () => {
    const response = await api('userinfo');
    order2(response);
    order3(response);
  };
  getApi();
}, []);

4. useEffect must be used as little as possible

// NG
// The typo can occur easily.
const [userId, setUserId] = useState();
const [userName, setUserName] = useState();
const [userAddress, setUserAddress] = useState();
const [userFavorite, setUserFavorite] = useState();

setUserId(props.userInfo.userid);
setUserName(props.userInfo.username);
setUserAddress(props.userInfo.address);
setUserFavorite(props.userInfo.favorite);

// 🥴 Good
const [userInfo, setUserInfo] = useState();
setUserInfo(props.userInfo);

// 😎 In case you want to insert a value into a specific key
const favorite = 'Eating';
setUserInfo((prevUserInfo) => ({ ...prevUserInfo, favorite }))

5. Visualizing Props

const userProfile = (props) => (
  <Box>
    {props.username}
    <span>{props.address}</span>
  </Box>
);

// 🥴 Good
const userProfile = ({ address, username }) => (
  <Box>
    {username}
    <span>{address}</span>
  </Box>
);

6. Dealing with data following a rule
useContext, props, and redux are able to create an application themselves.
You should understand each of these features.

Rules

useContext should be applied to shallow or wide-layered components.
-a) default style
-b) Header, Footer
-c) state for something, on/off
When you want to use an isolated component, you should not use useContext but props.
-a) The component depends on only it's parent component
-b) This makes it easy to extract and reuse the component
When dealing with a complex update pattern, you should use Redux

React.js ~Clean Code Basic~

Ogasawara Kakeru — Sun, 07 Jun 2026 23:20:23 +0000

The Basics

✅ Ensure that Prettier and formatter configurations are shared among developers
✅ Handle warnings and exceptions
✅ Avoid unnecessary console logs
✅ Be familiar with the minimum coding conventions

Good Code Examples
Here are seven key points I'd like you to keep in mind.

**1. The string line should be intuitively understandable.

// NG
const apiUrl = origin + '/api/v2/user/' + userId;

// Good🥴
const apiUrl = `${origin}/api/v2/user/${userId}`;

2. Abusing if statements causes too many code lines.

// NG
if (status == 'JPN') {
  return <JapaneseHeader />;
} else {
  return <EnglishHeader />;
}

// Good🥴
return status == 'JPN' ? <JapaneseHeader /> : <EnglishHeader />;

3. Whether there is a regularity about import statement

// NG
import React from 'react';
import { useState } from 'react';
import './style/logo.scss';
import logo from './image/logo.png';
import Button from '@material-ui/core/Button';
import useContext from 'react';

// Good🥴
/* Level 1: React */
import React, { useContext, useState } from 'react';

/* Level 2: UI framework, Third party library */
import Button from '@material-ui/core/Button';

/* Level 3: Original， Inner library */
import './style/logo.scss';
import logo from './image/logo.png';

4. AND/OR statements are suitable for React, but you should not use them too much

4.1 OR: In case you want to insert a value when the value exists.

if (temp) {
  text = temp;
} else {
  text = 'text doesn't exist';
}
// Good🥴
const text = temp || 'text doesn't exist';

4.2 AND: In case you want to insert a value after you check whether the value exists or not.

if (response) {
  text = response.text;
}
// Good🥴
const text = response && response.text;

// 🤔
const text = response && reponse.text || 'text doesn't exist';

5. Extract an event handler from a render

// NG
return (
  <Button
    onClick={(event) => {
      console.log(event.target);
    }}
  >
    Push
  </Button>
);

// Good🥴
const displayConsole = (e) => {
  console.log("target:", e.target);
};

return <Button onClick={displayConsole}>Push</Button>;

6. Extract a style from a render

// NG
return (
  <>
    <Box
      style={{
        height: '100%',
        color: warning,
        background: 'black',
      }}
    >
      {text1}
    </Box>
    <Box
      style={{
        height: '100%',
        color: warning,
        background: 'black',
      }}
    >
      {text2}
    </Box>
  </>
);

// Good🥴
const boxStyle = {
  height: '100%',
  color: warning,
  background: 'black',
};

return (
  <>
    <Box style={boxStyle} onClick={displayConsole}>
      {text1}
    </Box>
    <Box style={boxStyle} onClick={displayConsole}>
      {text2}
    </Box>
  </>
);

7. Make use of the object instead of the switch

// NG
switch (user.type) {
  case user:
    return <User />;
  case admin:
    return <AdminUser />;
  case host:
    return <HostUser />;
}

// Good🥴
const userView = {
  user: <User />,
  admin: <AdminUser />,
  host: <HostUser />,
};

return userView[user.type];

8. Utilize the UI library

✅ Should not rely on pure HTML
✅ Consider whether the codebase is able to be replaced with a UI library.

React.js ~use() hook in a Client Component~

Ogasawara Kakeru — Thu, 04 Jun 2026 01:06:26 +0000

What about Client-Side fetching for use() hook?
All examples so far start the fetch in a Server Component and pass the promise down. But what if you are already deep inside a client component, say a button opens a popup that needs fresh data?

You can't render a Server Component inside a Client Component. But use() + Suspense still works, you just have to manage promise identity yourself.

Start the Fetch in the Event Handler
The most straightforward approach: create the promise in the click handler, store it in state, and let use() read it.

"use client";

function DetailPopup({ dataPromise }: { dataPromise: Promise<ItemDetail> }) {
  const detail = use(dataPromise);
  return <div>{detail.description}</div>;
}

function ItemCard({ itemId }: { itemId: string }) {
  const [promise, setPromise] = useState<Promise<ItemDetail> | null>(null);

  const handleOpen = () => {
    setPromise(fetchItemDetail(itemId)); // fetch starts immediately
  };

  return (
    <>
      <button onClick={handleOpen}>Show Details</button>
      {promise && (
        <Suspense fallback={<Skeleton />}>
          <DetailPopup dataPromise={promise} />
        </Suspense>
      )}
    </>
  );
}

This is responsive, the fetch fires the instant the user clicks, not after React schedules a render. Each click creates a new promise, so you always get fresh data.

Use a Module-level Cache for Repeated Access
If the same popup might be opened multiple times with the same ID, a cache avoids redundant requests:

const cache = new Map<string, Promise<ItemDetail>>();

export function getItemDetail(id: string) {
  if (!cache.has(id)) {
    cache.set(
      id,
      fetch(`/api/items/${id}`).then((r) => r.json()),
    );
  }
  return cache.get(id)!;
}

const handleOpen = () => {
  setPromise(getItemDetail(itemId));
};

This is exactly the same caching pattern from the section above, it works identically whether the promise is created in a Server Component or a click handler. What matters is that use() always receives the same promise object for the same request.

When is use() Enough, and When Do You Need More?
For the popup scenario above, user clicks, data loads, popup displays it.　use() with a simple cache function is all you need. No extra dependency, no provider, no configuration. The 5-line Map cache from above handles deduplication just fine.

Consider TanStack Query or SWR when the data has a lifecycle beyond a single display:

The same data is shown in multiple places and a mutation in one place should update all of them.
Data goes stale and should silently refetch when the user returns to the tab.
You need paginated or infinite-scroll lists with cursor tracking.
You want optimistic UI that rolls back on server error.

If none of those apply, use() + a cache function is the simpler choice. You can always add a library later when the caching requirements grow, the mental model (promise in, data out, Suspense handles the wait) stays the same.

React.js ~use() hook Rules and Gotchas~

Ogasawara Kakeru — Sun, 31 May 2026 08:30:24 +0000

use() can be called conditionally
Unlike every other hook, use() works inside if, for, and after early returns. React's linter is aware of this exception.

use() cannot be called in try-catch
Rejected promises are caught by Error Boundaries, not by try-catch blocks. If you wap use() in a try-catch, React throws a "Suspense Exception" error.

// This will crash
try {
  const data = use(promise);
} catch (e) {
  // Never reaches here
}

If you need to provide a fallback value for a rejected promise, use .catch() on promise itself:

const safePromise = riskyFetch().catch(() => defaultValue);
const data = use(safePromise);

Resolved values must be serialization(Server to Client)
When passing a promise from a Server Component to a Client Component, the resolved value must be serializable, no functions, no class instance, no symbols, plain objects, and arrays are fine.

Don't mix patterns for the same data
If you read a promise with use(), don't also fetch the same data in a useEffect. Pick one source of truth for each piece of data.

React.js ~Migrating Away from useEffect + setState~

Ogasawara Kakeru — Fri, 29 May 2026 06:15:12 +0000

If you have an existing codebase full of useEffect-fetch-setState pattern, you don't need to rewrite everything at once. Here is a practical migration path:

**Step 1: Extract to a Custom Hook
Before changing the data fetching mechanism, encapsulate the exisiting pattern:

function useUser(id: string) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    let cancelled = false;
    setIsLoading(true);
    fetchUser(id)
      .then((data) => {
        if (!cancelled) setUser(data);
      })
      .catch((err) => {
        if (!cancelled) setError(err);
      })
      .finally(() => {
        if (!cancelled) setIsLoading(false);
      });
    return () => {
      cancelled = true;
    };
  }, [id]);

  return { user, isLoading, error };
}

**Step 2: Add Suspense Boundaries
Wrap the consuming components in Suspense and Error Boundaries. This is safe even before switching to use(): the boundaries just don't trigger yet:

<ErrorBoundary fallback={<ErrorMessage />}>
  <Suspense fallback={<Skeleton />}>
    <UserProfile userId={userId} />
  </Suspense>
</ErrorBoundary>

**Step 3:Swap the Internals
Now change the custom hook(or the component) to accept a promise and use use(). The consuming components don't change; they already have Suspense boundaries:

function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <ProfileCard user={user} />;
}

**Step 4:Move the Fetch Up
Push promise creation to Server Components or to a caching layer. This is the real architectural shift, data initiation moves from the component that needs it to the component(or server) that can create a stable reference.