Race condition: useEffect without cleanup

Reactmid

New UserProfile component in the project. A colleague adds it — fetch data when userId changes, show loading, then the profile. When switching quickly, UX testers notice "flashes" of old data. Walk the diff and explain the cause.

PR: lesson.tsx +35 −03 проблем

1-// UserProfile.tsx — new component

1+import { useEffect, useState } from 'react'

2+

3+interface User {

4+ id: string

5+ name: string

6+ email: string

7+}

8+

9+interface Props {

10+ userId: string

11+}

12+

13+export function UserProfile({ userId }: Props) {

14+ const [user, setUser] = useState<User | null>(null)

15+ const [loading, setLoading] = useState(false)

16+

17+ useEffect(() => {

18+ setLoading(true)

19+ fetch(`/api/users/${userId}`)

20+ .then((r) => r.json())

21+ .then((data) => {

22+ setUser(data)

23+ setLoading(false)

24+ })

25+ }, [userId])

26+

27+ if (loading) return <div>Loading...</div>

28+ if (!user) return <div>No user</div>

29+

30+ return (

31+ <div>

32+ <h2>{user.name}</h2>

33+ <p>{user.email}</p>

34+ </div>

35+ )

36+}

Шаг 1 из 5

How UI race conditions work

Any request with a changing parameter (userId, filter, page) is vulnerable to a race. Classic scenario: 1. Effect starts request A. 2. Parameter changes → effect starts request B. 3. Responses arrive in unpredictable order. 4. If A arrives second — it overwrites B. Fix — a cleanup function in useEffect that marks the previous request as cancelled. Scan the code and find where this wasn't done.

ArchCase

ArchCase

Race condition: useEffect without cleanup

How UI race conditions work