DEV Community: Ogasawara Kakeru

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.

React.js ~The landscape of data fetching in React~

Ogasawara Kakeru — Wed, 27 May 2026 08:32:05 +0000

The landscape of data fetching in React has more options than ever. Here is when each one is the right choice:

Scenario	Approach
Server Component fetching data	`async` / `await` directly in the component
Passing async data from Server to Client Component	Create promise on server, `use()` on client with Suspense
Simple client-side fetch (popup, dialog, one-off display)	`use()` with a cached promise + Suspense
Complex client state (auto-refetch, pagination, mutations)	TanStack Query or SWR
Computed/derived state from props or other state	`useMemo` or direct calculation during render
Reading context conditionally	`use(SomeContext)`
Reading context unconditionally	`useContext(SomeContext)` : simpler, more familiar
Subscribing to an external store (Redux, Zustand, browser API)	`useSyncExternalStore`
DOM measurements, event listeners, timers	`useEffect` : this is what it's actually for

React.js ~use() for Context~

Ogasawara Kakeru — Mon, 25 May 2026 23:28:42 +0000

use() can also read Context, and this is where it breaks a rule that every other hook follows.

Every React hook must be called at the top level of a component, never inside conditions, loops, or early returns. use() is the exception. It can be called conditionally:

function Greeting({ showFormal }: { showFormal: boolean }) {
  if (showFormal) {
    const { locale } = use(I18nContext);
    return <p>{locale === "de" ? "Guten Tag" : "Good day"}</p>;
  }
  return <p>Hey!</p>;
}

With useContext, this code would violate the rules of hooks. With use() lets you skip reading it entirely when the condition is false. With useContext, the component subscribes to that context unconditionally, even when it doesn't need the value.

React.js ~use() hook for Caching Problem~

Ogasawara Kakeru — Sun, 24 May 2026 01:26:26 +0000

This is where most tutorials stop. But if you try to use use() with a promise created inside a Client Component, you will hit a subtle and frustrating bug.

// Bug: creates a new promise on every render
function UserProfile({ userId }: { userId: string }) {
  const user = use(fetchUser(userId)); // new promise every render
  return <ProfileCard user={user} />;
}

fetchUser(userId) returns a new Promise object on every render. React sees a new promise, suspends again, and the component re-renders, creates another new promise, suspends again, infinite loop.

use() does not fetch data. It reads a promise. The promise must have a stable identity across renders. If you create a new promise on every render, you get an infinite suspension loop.

How to Stabilize the Promise
There are several approaches, each suited to a different archtecture:

1. Create the promise in a parent component or Server Component

// Server Component - promise created once, stable across renders
export default function UserPage({ params }: { params: { id: string } }) {
  const userPromise = fetchUser(params.id);

  return (
    <Suspense fallback={<Skeleton />}>
      <UserProfile userPromise={userPromise} />
    </Suspense>
  );
}

No async/await needed, the promise is passed down unresolved. The Client Component unwraps it with use(). Server Components don't re-render, so the promise reference is inherently stable.

2. Use a module-level cache

For Client Components that need to initiate fetches, cache the promise so the same reference is returned on subsequent calls:

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

function fetchUserCached(id: string): Promise<User> {
  if (!cache.has(id)) {
    cache.set(id, fetchUser(id));
  }
  return cache.get(id)!;
}

function UserProfile({ userId }: { userId: string }) {
  const user = use(fetchUserCached(userId));
  return <ProfileCard user={user} />;
}

Same arguments produce the same promise reference. No infinite loop.

Avoid async in Cache Wrappers

Do not mark your cache function as async. The async keyword always creates a new promise, even if you return a cached value. Use a synchronous function that stores and returns the original promise object.

3. Use a data fetching library

Libraries like TanStack Query or SWR handle caching, deduplication, and revalidation out of the box. They predate use() and solve a much broader problem - but they also add ~13kB gzipped and a provider wrapper. For a simple "fetch once, display result" pattern, use() with a 5-line cache function (option 2 above) does the job without the extra dependency. The library earns its keep when your UI has long-lived client state that needs to stay fresh: think dashboards that refetch on tab focus, lists with pagination, or mutations that should optimistically update related queries.

4. Use React's cache() in Server Components
React provides a built-in cache() function for Server Components. It memoizes a function's return value for the lifetime of a single server request:

import { cache } from "react";

const getUser = cache(async (id: string): Promise<User> => {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
});

Multiple components calling getUser("123") during the same render will share one fetch. The cache is scoped to the request, it resets on every new page load.

cache() vs. useMemo
Both memoize. But cache() works across components in a server render (deduplication), while useMemo works within a single component across re-renders. cache() is for data fetching. useMemo is for computations. Different tools, different jobs.

React.js ~use() hook for loading/error guards~

Ogasawara Kakeru — Thu, 21 May 2026 04:13:16 +0000

The Pattern It replaces

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

  useEffect(() => {
    /* ... fetch, cancelled flag, setState ... */
  }, [userId]);

  if (isLoading) return <Skeleton />;
  if (error) return <ErrorMessage error={error} />;
  if (!user) return null;

  return <ProfileCard user={user} />;
}

Three state declareations, one effect, three conditional returns: all before you reach the actual UI.Every component that fetches data repeats this structure.

Here is the same component with use():

// Client Component - only the happy path
"use client";

import { use } from "react";

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

// Server Component - creates the promise and defines the boundaries
import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";

export default function UserPage({ params }: { params: { id: string } }) {
  const userPromise = fetchUser(params.id);

  return (
    <ErrorBoundary fallback={<ErrorMessage />}>
      <Suspense fallback={<Skeleton />}>
        <UserProfile userPromise={userPromise} />
      </Suspense>
    </ErrorBoundary>
  );
}

The loading state is handled by <Suspense>.The error state is handled by <ErrorBoundary>(from the react-error-boundary package). The component itself only contains the happy path - the code that runs when data is available. The state machine has been moved from your code into React's runtime.

Because UserPage is a Server Component, it does not re-render. The promise reference is created once and passed down as a stable prop, no caching gymnastics needed.

Separation of Concerns

Notice how the component that uses the data (UserProfile) is separated from the component that initiates the fetch and defines the loading/error UI (UserPage). This is intentional. The consumer doesn't know where the promise came from or what to show while waiting.