---
schema_version: "1"
id: d2af4e6ebcb4c69062152446ee311bafb21470da362ef5f01d25b7330a32d673
title: State Management Differences with PWA Kit
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/commerce-cloud/sfnext/guides/sfnext-pwa-state-management.md
canonical_url: https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/sfnext-pwa-state-management.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 27a1258d8e2288d7790fdb133f5987a3a9a50874c631d5c82acf04ff6942e4d8
products:
  - Composable Storefront
  - Salesforce APIs
---
# State Management Differences with PWA Kit

PWA Kit's state management is React Query-centric, treating the API as the source of truth with sophisticated caching. Storefront Next takes a server-first approach where loaders provide data and client state is minimal and feature-specific. The shift eliminates the need for a dedicated server state library, simplifying the mental model while enabling better streaming and Suspense integration.

## Key Differences

| Aspect           | PWA Kit                      | Storefront Next                    |
| ---------------- | ---------------------------- | ---------------------------------- |
| Primary Approach | React Query for server state | React Router loaders               |
| State Library    | React Query + Context        | React Router Context + React State |
| Caching          | React Query in-memory cache  | Router revalidation                |
| Server State     | Managed by React Query       | Managed by React Router            |
| Persistence      | localStorage                 | Cookies                            |
| Architecture     | Centralized (React Query)    | Decentralized                      |

## Server State Management

PWA Kit uses React Query for all server state:

```javascript
// PWA Kit: Data fetched in component via hooks
const ProductPage = ({ productId }) => {
  const { data, isLoading } = useProduct({ parameters: { id: productId } });
  // Component handles loading state
};
```

Storefront Next uses loaders for server state:

```typescript
// Storefront Next: Data fetched before component renders
export function loader({ params, context }) {
  return { product: fetchProduct(params.productId) };
}

const ProductPage = ({ loaderData }) => {
  const product = use(loaderData.product); // Suspends if not ready
};
```

## Key Similarities

1. React Context for distribution: Both use Context to make state available to components.
2. Provider pattern: Both wrap the app in provider components.
3. Hooks for consumption: Both expose custom hooks (useAuth, useBasket, etc.).
4. Persistence considerations: Both handle localStorage/cookies for persistence.
5. SSR awareness: Both handle server vs client rendering differences.

## Storefront Conversion Considerations

Keep these considerations in mind when converting your storefront from PWA Kit to Storefront Next.

- React Query to Loaders

  - Move data fetching from component hooks to route loaders.
  - Replace `isLoading` checks with Suspense boundaries.
  - Remove React Query configuration and providers.

- Context Simplification

  - Simplify contexts to just hold values (no complex logic).
  - Move complex state to Zustand if needed.
  - Use middleware for initialization instead of provider effects.

- State Persistence

  - Migrate localStorage usage to cookies for SSR compatibility.
  - Use middleware to read persisted state during request processing.

- Derived State
  - Move derived calculations from hooks to selectors (Zustand) or loaders.
  - Use `useMemo` sparingly; prefer computed values in state stores.
