Tại sao phải phân biệt UI state với server state?

Question

IT Interview Practice · Accepted Answer

**UI state** là dữ liệu mà app của bạn sở hữu và điều khiển cục bộ (toggle, input form, tab đã chọn). **Server state** là dữ liệu sống trên server và chỉ được *cache* trên client (user, sản phẩm, bài viết lấy về). Chúng có những đặc tính khác nhau về cơ bản và cần những công cụ khác nhau.

## Những khác biệt then chốt

```text
                  UI state                    Server state
Quyền sở hữu      bạn sở hữu (client)         server sở hữu; client chỉ cache
Độ mới            luôn hiện tại               có thể bị CŨ (stale) (server đã đổi nó)
Cần đồng bộ?      không                       có — refetch, invalidate, revalidate
Chia sẻ?         thường một client           chia sẻ giữa user/thiết bị/tab
Mối quan tâm     chỉ set/đọc nó              caching, loading, lỗi, retry, dedup
```

## Tại sao đối xử dữ liệu server như UI state lại sai

```jsx
// ❌ đối xử dữ liệu server như local state thường — bạn phải tự dựng mọi thứ
function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

useEffect(() => {
    fetch("/api/users")
      .then(r => r.json()).then(setUsers)
      .catch(setError).finally(() => setLoading(false));
  }, []);
  // và giờ: caching? refetch khi focus? dedup? retry? dữ liệu cũ? tất cả thủ công 😓
}
```

Bạn rốt cuộc phải tự cài lại việc theo dõi loading/error, caching, refetch, deduplication, và xử lý staleness — cho mỗi lần fetch.

## Công cụ đúng: một thư viện server-state

```jsx
// ✅ React Query / SWR / RTK Query lo caching, loading, error, refetch giúp bạn
function Users() {
  const { data: users, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: () => fetch("/api/users").then(r => r.json()),
  });
  // tự động: caching, background refetch, dedup, retry, stale-while-revalidate
}
```

Những thư viện này được xây dựng riêng cho bài toán server-state — giữ một local cache đồng bộ với một nguồn remote.

## Sự phân chia thực tế

```text
UI state    → useState / Zustand / Context / Redux
Server state→ React Query / SWR / RTK Query / Apollo (cho GraphQL)
```

## Tại sao điều này quan trọng

Nhận ra server state là một **cache của dữ liệu remote** — không phải local state thông thường — là một insight lớn cho kiến trúc frontend hiện đại.

Nó giải thích vì sao đổ dữ liệu API vào Redux/useState dẫn đến hàng núi code caching/loading thủ công, và vì sao các thư viện server-state chuyên dụng (React Query, SWR) tồn tại và được áp dụng rộng rãi đến vậy.

Tách hai loại — UI state trong local store, server state trong một thư viện caching — đơn giản hóa đáng kể các app nặng dữ liệu và loại bỏ một lượng lớn boilerplate cùng các bug do staleness.

Những khác biệt then chốt

Tại sao đối xử dữ liệu server như UI state lại sai

Công cụ đúng: một thư viện server-state

Sự phân chia thực tế

Tại sao điều này quan trọng

Câu hỏi liên quan