Use Cascading Providers to manage global logic (e.g., profile loading, error handling) instead of modifying Next.js middleware, especially in apps using Sitecore or service workers.
Start typing to search...
When building complex PWAs with Sitecore and Next.js, developers often reach for middleware to manage global state or load data. However, in highly integrated environments, modifying middleware can introduce risks, regressions, and maintenance headaches.
This article introduces the Cascading Providers Pattern — a modular, testable, and Sitecore-safe solution for managing global logic without middleware changes.
Not using Sitecore?
The Cascading Providers Pattern is still a great way to modularize global logic in large-scale React or Next.js apps — whether you’re building a SaaS dashboard, e-commerce site, or internal tool.
Sitecore comes with its own middleware stack that handles:
Modifying this can break critical functionality or create conflicts during Sitecore updates.
In Sitecore XM Cloud, the Next.js middleware often integrates with the Sitecore Experience Editor, layout resolution, or identity providers. Modifying it can break personalization, inline editing, or preview modes, especially in production or editing environments.
PWAs rely heavily on service workers for:
Middleware changes can interfere with these critical PWA features.
The Cascading Providers Pattern involves creating a hierarchy of React Context Providers that each handle specific concerns, cascading from general to specific functionality.
// Traditional approach - everything in one place
<App>
<Component /> // Has to handle its own data loading
</App>
// Cascading Providers approach
<PWAProvider>
<GlobalProfileProvider>
<AuthenticationProvider>
<App>
<Component /> // Data is automatically available
</App>
</AuthenticationProvider>
</GlobalProfileProvider>
</PWAProvider>
Here's how we implemented this pattern in our PWA:
// contexts/PWAContext.tsx
const PWAProvider = ({ children }) => {
const [profileEmail, setProfileEmail] = useState("");
const [currentAccount, setCurrentAccount] = useState(null);
const [isOffline, setIsOffline] = useState(false);
// PWA-specific functionality
const value = {
profileEmail,
setProfileEmail,
currentAccount,
setCurrentAccount,
isOffline,
// ... other PWA state
};
return <PWAContext.Provider value={value}>{children}</PWAContext.Provider>;
};
This provider acts like middleware by automatically loading user profile data after authentication.
We use the following custom hooks in this provider:
usePWAContext(): Accesses and updates PWA-specific global state (e.g., email, offline status)useProfileDetails(): Custom hook that fetches detailed profile data from our backenduseSession(): Comes from next-auth to manage authentication status// providers/GlobalProfileProvider.tsx
export const GlobalProfileProvider = ({ children }) => {
const { profileEmail, showError } = usePWAContext();
const { triggerProfileDetails, isProfileDetailsLoading } =
useProfileDetails();
const { data: session, status } = useSession();
const hasTriggeredRef = useRef(false);
const loadProfile = useCallback(async () => {
try {
await triggerProfileDetails();
} catch (error) {
showError({
title: "Profile Load Error",
message:
"Failed to load profile details. Please try refreshing the page.",
retryAction: () => loadProfile(),
});
}
}, [triggerProfileDetails, showError]);
useEffect(() => {
// Only trigger if user is authenticated and we don't have profile data
if (
status === "authenticated" &&
session?.user &&
!profileEmail &&
!isProfileDetailsLoading &&
!hasTriggeredRef.current
) {
console.log("GlobalProfileProvider: Loading profile data...");
hasTriggeredRef.current = true;
loadProfile();
}
}, [status, session, profileEmail, isProfileDetailsLoading, loadProfile]);
return <>{children}</>;
};
// pages/_app.tsx
function App({ Component, pageProps }) {
return (
<PWAProvider>
<GlobalProfileProvider>
<SessionProvider session={pageProps.session}>
<I18nProvider lngDict={dictionary} locale={pageProps.locale}>
<Component {...pageProps} />
<GlobalErrorModal />
<OfflineHandler />
</I18nProvider>
</SessionProvider>
</GlobalProfileProvider>
</PWAProvider>
);
}
Each provider handles a specific responsibility:
PWAProvider: Core PWA state managementGlobalProfileProvider: Automatic profile data loadingSessionProvider: Authentication stateI18nProvider: Internationalization// Components just use the context - no middleware knowledge needed
const MyComponent = () => {
const { profileEmail, currentAccount } = usePWAContext();
// Profile data is automatically available!
return <div>Welcome, {profileEmail}</div>;
};
The GlobalProfileProvider acts like middleware by:
// Test individual providers in isolation
<PWAProvider>
<GlobalProfileProvider>
<TestComponent />
</GlobalProfileProvider>
</PWAProvider>
| Aspect | Middleware | Cascading Providers |
|---|---|---|
| Sitecore Safety | ❌ Risk of conflicts | ✅ No conflicts |
| PWA Compatibility | ❌ May interfere with SW | ✅ PWA-friendly |
| Testing | ❌ Hard to isolate | ✅ Easy unit testing |
| Debugging | ❌ Complex stack traces | ✅ Clear component tree |
| Team Collaboration | ❌ Backend knowledge needed | ✅ Frontend-only changes |
| Maintenance | ❌ Framework updates risky | ✅ Safe updates |
const ConditionalProvider = ({ children, condition, fallback }) => {
if (!condition) return fallback || children;
return <SpecializedProvider>{children}</SpecializedProvider>;
};
const AppProviders = ({ children }) => (
<PWAProvider>
<GlobalProfileProvider>
<OfflineProvider>
<ErrorBoundaryProvider>{children}</ErrorBoundaryProvider>
</OfflineProvider>
</GlobalProfileProvider>
</PWAProvider>
);
const LazyProfileProvider = lazy(
() => import("./providers/GlobalProfileProvider")
);
// In _app.tsx
<Suspense fallback={<Loading />}>
<LazyProfileProvider>{children}</LazyProfileProvider>
</Suspense>;
Each provider should have a single responsibility:
// ✅ Good - focused responsibility
const ProfileProvider = () => {
/* handles only profile data */
};
const OfflineProvider = () => {
/* handles only offline state */
};
// ❌ Bad - mixed responsibilities
const MegaProvider = () => {
/* handles profile, offline, auth, etc. */
};
const hasTriggeredRef = useRef(false);
useEffect(() => {
if (shouldTrigger && !hasTriggeredRef.current) {
hasTriggeredRef.current = true;
triggerAction();
}
}, [shouldTrigger]);
const ProviderErrorBoundary = ({ children, onError }) => {
// Handle provider-specific errors
return <ErrorBoundary onError={onError}>{children}</ErrorBoundary>;
};
const loadProfile = useCallback(async () => {
// Expensive operation
}, [dependencies]); // Minimal dependencies
const PWAContext = createContext();
const ProfileContext = createContext();
// Split contexts to prevent unnecessary re-renders
const value = useMemo(
() => ({
// Only compute when dependencies change
expensiveValue: computeExpensiveValue(data),
}),
[data]
);
The Cascading Providers Pattern is a clean, modular alternative to modifying middleware in Next.js applications — especially those integrated with Sitecore and built as PWAs. It offers:
For teams managing complex Sitecore integrations or PWA-specific workflows, Cascading Providers deliver middleware-like power without middleware-related risk — making it an ideal pattern for scalable, production-ready apps.