Motivation

React already has great primitives — Suspense, ErrorBoundary, lazy. But using them in real applications quickly exposes gaps. @suspensive/react fills those gaps.

Skip SSR for a Suspense boundary when you need to

React’s <Suspense> works with SSR and streaming. Sometimes you still want a boundary to render only on the client — show fallback on the server and mount children after hydration (client-only APIs, widgets, or gradual migration). React does not ship a built-in flag for that; teams often reach for dynamic(..., { ssr: false }) or manual guards.

With Suspensive’s <Suspense clientOnly/>, one prop declares that intent — no extra wrappers.

ErrorBoundary is too complicated

react-error-boundary offers three different fallback interfaces. With Suspensive’s <ErrorBoundary/>, you get one fallback prop, plus shouldCatch to filter which errors to handle.

Resetting ErrorBoundaries is painful

Managing resetKeys across multiple <ErrorBoundary/>s is tedious. With Suspensive’s <ErrorBoundaryGroup/>, a single call resets all of them.

Loading spinners flash

A spinner that appears for 50ms is worse than no spinner. With Suspensive’s <Delay/>, brief loading states are hidden so users only see spinners when they actually need to wait.

Client-only code causes hydration mismatches

With Suspensive’s <ClientOnly/> and useIsClient, you get safe client-side rendering — no more typeof window !== 'undefined' scattered across your code.

Same props, everywhere

Stop passing the same fallback to every <Suspense/>. With Suspensive’s <DefaultPropsProvider/>, you set defaults once for all Suspensive components.

React.lazy can’t preload or recover

With Suspensive’s lazy, you get .load() for preloading and automatic retry on chunk failures — the kind of thing you only discover you need in production.