Server State vs Client State

Problem

Treating server data like local state leads to stale caches and unnecessary refetching. User profile data stored in Redux doesn’t update when changed on another device. Loading states and cache invalidation logic gets tangled with UI state. Developers manually implement refetching, polling, and optimistic updates for every API call, reinventing the wheel each time.

Solution

Distinguish between data fetched from servers (server state) and local UI state (client state). This clarifies which state needs synchronization and which is purely local.

Example

This demonstrates distinguishing between server state (cached data from APIs) and client state (local UI state), enabling specialized management strategies for each type of state.

// Server state - fetched from API, needs caching and synchronization
const { data: users } = useQuery('users', fetchUsers);

// Client state - purely local UI state, no server synchronization needed
const [selectedUser, setSelectedUser] = useState(null);     // Current selection
const [isModalOpen, setIsModalOpen] = useState(false);      // Modal visibility

Benefits

• Clarifies which state needs caching, synchronization, and invalidation strategies.
• Enables specialized tools for server state (React Query) vs client state (useState).
• Prevents treating temporary cached API data like permanent application state.
• Makes it clear when data needs to be refetched versus purely local.

Tradeoffs

• Requires learning different state management approaches for each type.
• Can blur when state is hybrid (local with server persistence).
• May lead to having multiple state management solutions in one app.
• Needs careful consideration of where derived state belongs.