Recipe — Provider stack for a store module

Standard provider nesting for a Whisker module scoped to a single store with inventory, translations, analytics, and slide-outs.

When to use

New module or page that needs store context, product data, i18n, and slide-out product inquiry.

Provider order (outer → inner)

import {
  ModuleAnalyticsProvider,
  TranslationProvider,
  SlideOutProvider,
  NikeStoreProvider,
  InventoryProvider,
} from '@nike/whisker-component-library';

function StoreModule({ storeId, accessToken, isProd, bffUrl, isLoggedIn }) {
  return (
    <ModuleAnalyticsProvider moduleName="my-module">
      <TranslationProvider locale="en-US" fallbackLocale="en-US" team="sim-web">
        <SlideOutProvider>
          <NikeStoreProvider
            storeId={storeId}
            loggedIn={isLoggedIn}
            accessToken={accessToken}
            isProd={isProd}
            bffUrl={bffUrl}
          >
            <InventoryProvider
              storeId={storeId}
              accessToken={accessToken}
              loggedIn={isLoggedIn}
              isProd={isProd}
              bffUrl={bffUrl}
            >
              <ModuleRoutes />
            </InventoryProvider>
          </NikeStoreProvider>
        </SlideOutProvider>
      </TranslationProvider>
    </ModuleAnalyticsProvider>
  );
}

Store hooks after mount

• useNikeStore() — store info, config, athletes
• useInventory() — products; wait for isCpaReady / isPriceReady
• useTranslation() — t('key')
• useSlideOut() — open product panels

Pitfalls

• storeId must be UUID format for NikeStoreProvider.
• InventoryProvider is heavy — import only on pages that need product data.
• SlideOutProvider is an app-level singleton; only one instance per tree.
• Pass loggedIn={false} on login/session-expired pages to pause BFF fetches and prevent 401/403 errors.
• Host may already mount PlatformAnalyticsProvider; modules use ModuleAnalyticsProvider.