State Management with @wordpress/data: Building Scalable Stores

Previously in this course, we built modular React Component Architecture using functional components. While local useState is sufficient for simple UI toggles, professional WordPress plugins require a centralized, predictable state container to handle complex, cross-block interactions.

Today, we dive into @wordpress/data, the WordPress implementation of the Redux pattern. This library allows us to treat the entire WordPress admin as a single source of truth, enabling your Knowledge Base blocks to communicate effortlessly.

Understanding the WordPress Data Architecture

At its core, @wordpress/data uses a store-based architecture. A store is composed of four main pillars:

1. State: The immutable data object representing the current status of your application.
2. Actions: Plain JavaScript objects describing what happened (e.g., SET_KB_CATEGORY).
3. Reducers: Pure functions that take the current state and an action, returning a new state.
4. Selectors: Functions that retrieve specific slices of state, often including derived data.

If you are new to this pattern, understanding the WordPress Data store architecture is the prerequisite for writing maintainable, bug-free plugin interfaces.

Creating a Custom Data Store

To manage our Knowledge Base plugin's configuration globally, we must register a custom data store. We use createReduxStore to define our namespace and initial state.

JAVASCRIPT
import { createReduxStore, register } from CE9178">'@wordpress/data';

const DEFAULT_STATE = {
    isSaving: false,
    settings: {
        theme: CE9178">'light',
        itemsPerPage: 10,
    },
};

const actions = {
    setTheme(theme) {
        return { type: CE9178">'SET_THEME', theme };
    },
};

const store = createReduxStore(CE9178">'kb-plugin/settings', {
    reducer(state = DEFAULT_STATE, action) {
        switch (action.type) {
            case CE9178">'SET_THEME':
                return { ...state, settings: { ...state.settings, theme: action.theme } };
            default:
                return state;
        }
    },
    selectors: {
        getTheme(state) {
            return state.settings.theme;
        },
    },
    actions,
});

register(store);

Implementing Selectors and Actions

We define actions and reducers to ensure state transitions are traceable. Selectors are particularly powerful because they can compute data on the fly, preventing "stale" state issues.

In your React components, you consume this data using the useSelect and useDispatch hooks. This pattern decouples your UI from the underlying data logic.

JAVASCRIPT
import { useSelect, useDispatch } from CE9178">'@wordpress/data';

const ThemeSwitcher = () => {
    const theme = useSelect((select) => select(CE9178">'kb-plugin/settings').getTheme(), []);
    const { setTheme } = useDispatch(CE9178">'kb-plugin/settings');

    return (
        <button onClick={() => setTheme(theme === CE9178">'light' ? CE9178">'dark' : CE9178">'light')}>
            Current Theme: {theme}
        </button>
    );
};

Managing Cross-Block State Flow

In our Knowledge Base plugin, we often need multiple blocks to react to a single change in settings. By using the global @wordpress/data store, we eliminate the need for complex prop-drilling or event bubbling.

When a user updates a plugin-wide setting, useSelect automatically triggers a re-render in every component subscribed to that selector. This ensures that your UI remains consistent, a critical step toward finalizing dashboard data flow.

Hands-on Exercise

1. Create a new file store.js in your plugin's assets/src/data directory.
2. Register a store named kb-plugin/ui that tracks a sidebarOpen boolean state.
3. Implement a toggleSidebar action and a isSidebarOpen selector.
4. In a React component, use useDispatch to trigger the toggle and useSelect to render an isOpen class on a wrapper div.

Common Pitfalls

• Mutating State Directly: Reducers must always return a new object (e.g., use the spread operator {...state}). Never modify the state object directly.
• Over-selecting: Only select the specific slice of state your component needs. If you select the entire state object, your component will re-render whenever any part of the state changes, leading to performance degradation.
• Async Logic in Reducers: Reducers must be pure functions. Perform your API calls (using apiFetch) inside action creators or via resolvers, not within the reducer.

Recap

We've moved from local state to global, reactive state management using @wordpress/data. By utilizing custom stores, we've enabled our Knowledge Base plugin to handle complex data synchronization across multiple blocks and admin screens, ensuring a consistent user experience.

Up next: Block API v2 Essentials, where we will define our block's metadata and implement the server-side rendering logic for our Knowledge Base blocks.