Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «client-side state VS server-side state». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

## Визначення

| Термін | Що це таке |
|---|---|
| **Client-side state** | Дані, які живуть лише в браузері, керуються самим React і існують незалежно від сервера. |
| **Server-side state** | Дані, які зберігаються **на сервері** (у базі, API тощо) і мають бути **завантажені, оновлені або синхронізовані** з клієнтом. |

---

## 1. Client-side state (клієнтський стан)

Це все, що існує **лише на фронтенді**,
і React сам це контролює через `useState`, `useReducer`, `useContext` тощо.

### Приклади client state:

- Чи відкрита модалка (`isModalOpen`)
- Поточний фільтр або сортування
- Обрана вкладка
- Текст, введений користувачем, але не відправлений
- Валідація форми
- Стан теми (`dark` / `light`)
- Дані в localStorage

Ці дані **не потрібно синхронізувати з сервером**.
Вони живуть у пам'яті браузера і зникають при перезавантаженні сторінки.

---

## 2. Server-side state (серверний стан)

Це дані, які **належать серверу**,
а клієнт лише **завантажує їх, відображає і іноді змінює**.

Приклади:

- Список користувачів з API
- Товари в магазині
- Дані профілю користувача
- Коментарі під постом
- Баланс рахунку
- Будь-яка інформація, що зберігається в БД

Такі дані:

- отримуються асинхронно (`fetch`, `axios`, `graphql`, `react-query`, `trpc`),
- можуть **змінитися на сервері без відома клієнта**,
- вимагають **оновлення (рефетчингу)** за певних подій.

---

## 3. Ключові відмінності

| Характеристика | **Client-side state** | **Server-side state** |
|---|---|---|
| Де зберігається | У пам'яті браузера | На сервері / API |
| Хто "власник" даних | Клієнт | Сервер |
| Як оновлюється | Одразу через `setState` | Через HTTP-запит (fetch, axios тощо) |
| Чи може змінитися "само по собі"? | Ні | Так (інші користувачі, процеси) |
| Чи потрібно синхронізувати | Ні | Так (через рефетч або веб-сокети) |
| Приклади | модалки, фільтри, поточна вкладка | список товарів, пости, профіль користувача |
| Втратиться при перезавантаженні | Так | Ні (дані на сервері зберігаються) |

---

## Приклад для наочності

### Client-side state

```javascript
const [isModalOpen, setIsModalOpen] = useState(false);
```

Модалка відкривається і закривається - все живе в React.
Серверу все одно.

---

### Server-side state

```javascript
const [users, setUsers] = useState([]);

useEffect(() => {
  fetch("/api/users")
    .then(res => res.json())
    .then(setUsers);
}, []);
```

Тут дані приходять **із зовнішнього джерела (API)**.
Якщо хтось додасть нового користувача, сервер оновиться,
а клієнт - **ще не знає**, поки не зробить повторний запит (рефетч).

---

## 4. Чому це важливо розділяти

1. **Різні вимоги до оновлення**
  - Client state оновлюється миттєво через `setState`.
  - Server state вимагає мережевого запиту → асинхронно.
2. **Різні інструменти**
  - Client state → `useState`, `useReducer`, `useContext`, Zustand, Redux Toolkit.
  - Server state → `React Query`, `SWR`, `Apollo`, `tRPC`, `RTK Query`.
3. **Різне "життя даних"**
  - Client state - живе, поки відкритий компонент.
  - Server state - може кешуватися, рефетчитися, інвалідовуватися.
4. **Різна стратегія кешування**
  - Client state: немає сенсу кешувати, це локальні UI-дані.
  - Server state: обов'язково кешувати, щоб не навантажувати API при кожному рендері.

---

## 5. Сучасний підхід: "розділяй і володарюй"

**Тримай локальний стан якомога ближче до UI**
(`useState`, `useReducer`, `useContext`)

**А серверний стан - виноси у спеціалізовані інструменти**,
які вміють:

- кешувати запити,
- рефетчити при змінах,
- синхронізувати дані при фокусі вкладки,
- оптимістично оновлювати інтерфейс.

Приклади:

```javascript
React Query (TanStack Query)
SWR (Next.js)
Apollo Client (GraphQL)
RTK Query (Redux)
```

---

### Приклад з React Query

```javascript
import { useQuery } from "@tanstack/react-query";

function UsersList() {
  const { data, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: () => fetch("/api/users").then(res => res.json()),
  });

if (isLoading) return <p>Завантаження...</p>;
  if (error) return <p>Помилка!</p>;

return (
    <ul>
      {data.map(u => <li key={u.id}>{u.name}</li>)}
    </ul>
  );
}
```

Тут `data` - це **server-side state**,
але React Query керує його кешем, рефетчем і синхронізацією.

---

## Підсумок

|  | **Client-side state** | **Server-side state** |
|---|---|---|
| Де живе | У React / браузері | На сервері |
| Як оновлюється | Одразу (setState) | Через запит |
| Може застаріти без відома клієнта | Ні | Так |
| Інструменти | `useState`, `useReducer`, `useContext`, Zustand | React Query, SWR, RTK Query, Apollo |
| Приклади | модалка, фільтр, тема | пости, товари, профіль |
| Чи потрібно рефетчити | Ні | Так |
| Рендер при оновленні | Одразу | Після відповіді сервера |

---

## Проста аналогія

> **Client state** - це як "чернетка" на твоєму столі:
> ти пишеш нотатки, швидко редагуєш, нічого не синхронізується.
>
> **Server state** - це як документ у хмарі (Google Docs):
> він зберігається на сервері, може змінитися в інших користувачів,
> і тобі потрібен час, щоб отримати актуальну версію.

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати752 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.