Advertise with Us|Sign Up to the Newsletter

Real systems require service discovery, API gateways, centralized configuration, and built-in resilience. In this live, hands-on workshop, you’ll build a working microservices system end-to-end, define service boundaries, wire up discovery, configure a gateway, and handle failures properly.

📢 Important: WebDevPro is Moving to Substack

We’ll be moving WebDevPro to Substack soon.Once the transition is complete, all future issues will come from packtwebdevpro@substack.com.

To make sure the newsletter continues reaching your inbox, please add this address to your contacts or whitelist it in your mail client. No other action is needed. You’ll keep receiving WebDevPro on the same weekly schedule.

Substack will also give you more control over your subscription preferences if you decide to adjust them later.

Welcome to this week’s issue of WebDevPro!

If you’ve worked with React for a while, you’ve probably run into the same recurring question: how should we manage state in this application?

State management is one of those topics that almost every React team ends up debating sooner or later. Should everything live in context? Do we need a global store? Would something like Zustand make things simpler?

Those conversations usually focus on tools. But in many cases the real problem shows up earlier than that.

In practice, React applications rarely become difficult to maintain because the wrong library was chosen. They become difficult to maintain because different kinds of state get handled in the same way.

A form input, an API response, a UI filter, and a shared user object often end up managed with identical patterns. That is where complexity starts to creep in.

In this article, we will look at the main categories of state that appear in React applications and how each category is best managed. By the end, you will have a clearer way to decide where state belongs in a React app, whether that means local component state, shared state, server data tools, or even the URL itself.

State in React applications usually falls into a few clear categories.

Local state lives inside a single component. A dropdown menu, a modal visibility toggle, or a small UI interaction typically belongs here. Hooks such as useState or useReducer work well because the logic remains isolated.

Server state represents data fetched from APIs or databases. This includes user profiles, product listings, or analytics data. The key difference is that the source of truth lives outside the application.

Form state includes field values, validation errors, and submission status. Forms have their own lifecycle and benefit from specialized tools such as React Hook Form or React’s form hooks.

URL state stores small pieces of UI state in route or search parameters. Tabs, filters, pagination, and search queries often belong here.

Shared state exists when multiple components need access to the same data. Authentication details, application settings, or user preferences are common examples.

Understanding these categories clarifies an important point. React state is not a single problem. It is a set of related problems that require different solutions.

One of the most common sources of complexity in React applications comes from duplicated state.

Consider a list of items where the interface displays only active entries. A common pattern stores both the original list and a filtered version of it.

const [items, setItems] = useState([...])

const [filteredItems, setFilteredItems] = useState([])

useEffect(() => {

setFilteredItems(items.filter(item => item.active))

}, [items])

This introduces synchronization logic that React must maintain.

A simpler approach derives the filtered list directly from the original state.

const [items, setItems] = useState([...])

const filteredItems = items.filter(item => item.active)

The application now maintains a single source of truth. React calculates the derived value when needed.

Derived state reduces bugs and simplifies reasoning about data flow. Many React components become easier to maintain once unnecessary state variables disappear.

Local state remains predictable because it stays within a component. Shared state changes that dynamic because multiple components read and update the same values.

Developers often encounter this situation when user data, permissions, or global settings must appear across different sections of the interface.

The simplest approach begins with prop drilling. A parent component holds the state and passes it through props to child components.

This technique often receives criticism, yet it works well for a small number of adjacent components. It also keeps data flow explicit and easy to trace.

Problems appear when the component tree becomes deeper. Intermediate components may receive props they do not use, simply to pass them further down the hierarchy.

At this stage, many teams introduce React context.

Context allows components to access shared values without passing them through each level of the tree. A provider component stores the shared state and exposes it to any descendant component.

This pattern simplifies access but introduces a different trade-off. When context values change, every consumer beneath the provider may re-render. For small applications this rarely matters. In larger interfaces the rendering behavior becomes harder to control.

Libraries such as Zustand approach shared state from a different angle. Zustand creates a centralized store and allows components to subscribe only to the pieces of state they require.

const userName = useUserStore(state => state.userName)

Components update only when the subscribed value changes. This selective subscription reduces unnecessary renders and keeps the shared state logic compact.

Context and Zustand both solve shared state challenges, but they operate at different scales. Context works well for moderate application state. Zustand becomes attractive once shared state spreads across larger parts of the interface.

Data fetched from external services introduces a different category of state entirely.

Server data involves caching, background refetching, loading indicators, and stale data management. Handling these concerns with useState and useEffect often leads to repetitive code and fragile synchronization.

Libraries such as TanStack Query address this layer directly. They treat server data as cached resources rather than ordinary component state.

Components request data using a shared query key.

const { data } = useQuery({

queryKey: ['user', userId],

queryFn: fetchUser

})

TanStack Query stores the response in a client cache. Other components requesting the same query receive the cached result rather than triggering another network request.

This model separates server data concerns from UI logic. React components remain focused on rendering rather than managing asynchronous data lifecycles.

Another overlooked location for state is the browser address bar.

Interfaces often contain UI state that describes how a page is being viewed. Active tabs, filter selections, search queries, and pagination indexes all fall into this category.

Storing this information in URL search parameters creates several benefits.

The state becomes shareable through links. Refreshing the page preserves the interface configuration. Browser navigation also restores previous UI states naturally.

Framework hooks such as useSearchParams and routing utilities make this pattern straightforward.

const params = useSearchParams()

const activeTab = params.get('tab')

Many teams duplicate this information inside React state and attempt to synchronize it with the URL. Removing that duplication simplifies the architecture.

The address bar can act as a reliable source of truth for small pieces of UI state.

Modern React offers many tools for managing state, but the real skill lies in recognizing where each type of state belongs.

Local UI interactions usually remain simplest when handled with component state.

Values that can be computed from existing data should be derived instead of stored.

Data fetched from APIs benefits from tools designed for server state, such as TanStack Query, which handle caching and refetching automatically.

UI state that affects navigation, such as active tabs or filters, often works best when stored in URL parameters.

Shared client state can start with straightforward prop passing and evolve into solutions such as context or Zustand when multiple components need coordinated access.

The key takeaway is not which library to choose. It is learning to recognize the nature of the state problem in front of you. Once you can distinguish between local, shared, server, form, and URL state, the architecture decisions become much clearer. Instead of forcing every problem into the same pattern, each piece of state can live in the place where it is easiest to manage.

That shift in thinking leads to React applications that are easier to reason about, easier to scale, and far less prone to the state management issues that often slow teams down.

Build real skills in LLMs and agentic AI with this 20+ course Packt bundle, featuring titles like Learn Python Programming, 4E and The LLM Engineer’s Handbook. Learn how to design and deploy intelligent systems while supporting World Central Kitchen.

🛠️ VMPrint deterministic PDF generation without headless browsers

Print-to-PDF pipelines often rely on headless Chrome, bringing along browser quirks and inconsistent rendering. VMPrint takes a different approach with a pure TypeScript typesetting engine that bypasses the DOM entirely and computes layout through typographic math. The result is deterministic output across browsers, Node.js, and edge runtimes like Cloudflare Workers. Given identical input, VMPrint guarantees identical layout down to the sub-point position of every glyph. For teams building document generation pipelines or publishing systems, it offers a precise and reproducible alternative to browser-based rendering.

That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!

Cheers!

Editor-in-chief,

Kinnari Chohan