Not easier. Not "easier with the right setup." Trivially easy. Three lines. No mocks, no providers, no async coordination, no timing tricks:

// Test
render(<UserCard store={RemoteDataStore.fromValue({ name: 'Alice' })} />);
expect(screen.getByText('Alice')).toBeInTheDocument();

// Storybook
export const Loaded = () => <UserCard store={RemoteDataStore.fromValue(alice)} />;
export const Loading = () => <UserCard store={RemoteDataStore.of(RemoteData.Pending)} />;

// SSR
const store = useRemoteData(() => fetchUser(id), { initial: RemoteData.success(serverData) });
// Renders on the server with real data. No hydration boundary. No dehydration.

These aren't three separate features. They're the same thing: a component that receives a value doesn't care where the value came from. A test manufactures it. Storybook manufactures it. A server manufactures it. The component renders identically in all three cases because its only dependency is its props.

What we're actually talking about​

When I say "value," I don't mean something pure or immutable in the strict functional programming sense. A RemoteDataStore from useRemoteData is, honestly, a mutable stateful object internally. It has abort controllers, request versioning, refresh timers. It changes over time.

But from the consumer's perspective, it has a value-like interface. You receive it as a prop. You pass it to <Await>. You can combine it with other stores via RemoteDataStore.all(). You can transform it with .map(). And critically, you can manufacture a fake one with RemoteDataStore.fromValue(data) that the consuming component cannot distinguish from a real one.

That's what matters. Not purity in the academic sense, but substitutability in the practical sense. Can I give my component a store without setting up the universe? If yes, the component is independent. If no, it's a fragment of a larger system pretending to be independent.

The infrastructure tax​

Most data-fetching libraries create an invisible dependency between your component and a global system. Your component calls useQuery, which talks to a QueryClient, which lives in a React context provider that must wrap your component tree.

This works fine in production. The provider is there, the cache is configured, everything connects. The cost shows up everywhere else:

Testing: You need a QueryClientProvider, a QueryClient instance, probably msw or nock to intercept HTTP requests, waitFor to handle the async state transition, and act() to flush updates. A 3-line test becomes a 30-line test. Not because the component is complex, but because the infrastructure is complex.

Storybook: You need the same provider setup, plus either a mock server running or interceptors configured, plus timing hacks to capture the loading state before data arrives. Many teams give up and only write stories for the "loaded" state.

SSR: You need to serialize the query client's cache on the server, ship it in the HTML, and restore it on the client inside a <HydrationBoundary>. This is conceptual overhead that exists because the cache is global state that must survive the server/client transition.

None of this infrastructure exists because your component is complex. It exists because your component has a hidden dependency on a global system, and recreating that global system in each context (test, story, server) takes work.

Remove the hidden dependency (make the store a prop) and the infrastructure vanishes. Not because you've done something clever, but because there was never an inherent reason for it to exist.

The prop drilling question​

The objection: "If stores are props, doesn't that mean prop drilling? Doesn't that mean a <PageLayout> needs a userStore prop just because some deeply nested <UserBadge> uses it?"

It doesn't have to. React already has the tools to solve this without hiding dependencies. You just have to use them.

Pass elements, not data​

The first tool is the one people forget about: ReactNode as a prop. Instead of drilling data through intermediate layers, build the component higher up and pass the element through:

// Instead of this (drilling userStore through Layout)
function App() {
    const userStore = useRemoteData(() => fetchUser());
    return <Layout userStore={userStore} />;  // Layout doesn't use it, just passes it down
}

// Do this: build the element at the top, pass it as a slot
function App() {
    const userStore = useRemoteData(() => fetchUser());
    return (
        <Layout
            sidebar={
                <Await store={userStore}>
                    {(user) => <UserBadge user={user} />}
                </Await>
            }
        />
    );
}

Layout doesn't know about users. It doesn't have a userStore prop. It just has a sidebar: ReactNode slot and renders it wherever it belongs. The user data stays at the level that owns it, and the rendered element flows down.

This is inversion of control, and React supports it natively. A component that accepts ReactNode props is saying "you decide what goes here, I decide where it goes." No data needs to pass through. No interface pollution.

Bundle props into objects​

The second tool is even simpler: data modeling. If you're passing five related props through multiple layers, that's not a drilling problem; it's a missing abstraction:

// Instead of drilling five props
function Page({ user, posts, stats, onSave, onDelete }: ...) { ... }

// Model the dependency
interface DashboardData {
    user: User;
    posts: Post[];
    stats: Stats;
}

interface DashboardActions {
    onSave: (data: FormData) => void;
    onDelete: (id: string) => void;
}

function Page({ data, actions }: { data: DashboardData; actions: DashboardActions }) { ... }

Five props become two. Give them a name that describes what they are. This is data modeling: grouping related things and naming the group. The same principle that makes a User type better than three loose strings applies to component interfaces.

Use callbacks for data the parent doesn't have​

Sometimes a child needs to combine parent data with data only it has, like a selected row ID, a form value, or a scroll position. That's a callback:

function Parent() {
    const userStore = useRemoteData(() => fetchUser());
    return (
        <Await store={userStore}>
            {(user) => <PostList onSelectPost={(postId) => navigate(`/users/${user.id}/posts/${postId}`)} />}
        </Await>
    );
}

The parent provides the user context via a callback. PostList doesn't need to know about users; it just calls onSelectPost with the data it has. The wiring happens at the boundary.

Between element slots, named prop objects, and callbacks, most "prop drilling" problems dissolve. The data stays at the level that owns it. The components below stay independent.

One interface, every context​

Here's the UserCard component:

function UserCard({ store }: { store: RemoteDataStore<User> }) {
    return (
        <Await store={store}>
            {(user) => (
                <div>
                    <h1>{user.name}</h1>
                    <p>{user.email}</p>
                </div>
            )}
        </Await>
    );
}

This component cannot tell the difference between:

• A store created by useRemoteData that fetched from an API
• A store created by RemoteDataStore.fromValue(testUser) in a test
• A store pre-filled with server data via the initial option
• A store shared across components via SharedStoreProvider
• A store combined from three other stores with RemoteDataStore.all()

In every case, the component receives a RemoteDataStore<User> and renders it. That's the contract. Everything outside that contract (how the data was fetched, whether it's cached, whether it's shared, whether it's server-rendered) is someone else's decision.

This is what makes the testing/Storybook/SSR story work. It's not a feature of the library. It's a consequence of the interface. When a component's only dependency is a value in its props, you can satisfy that dependency from anywhere.

Testing​

test('renders the user', () => {
    render(<UserCard store={RemoteDataStore.fromValue({ name: 'Alice', email: 'alice@example.com' })} />);
    expect(screen.getByText('Alice')).toBeInTheDocument();
});

test('renders loading', () => {
    render(<UserCard store={RemoteDataStore.of(RemoteData.Pending)} />);
    expect(screen.getByText('Loading...')).toBeInTheDocument();
});

test('renders error with retry', () => {
    const retry = vi.fn().mockResolvedValue(undefined);
    const store = RemoteDataStore.of(RemoteData.Failed([Failure.unexpected(new Error('timeout'))], retry));
    render(<UserCard store={store} />);
    expect(screen.getByText(/timeout/)).toBeInTheDocument();
});

No waitFor. No act(). No mock server. The store is already in the state you want, so the component renders synchronously. Three states, three tests, nine lines of assertions.

To be fair: you could achieve similar test simplicity with react-query by splitting your component into a "container" that calls useQuery and a "presentational" component that receives data: T as a prop. That's a valid pattern. The difference is that RemoteDataStore<T> carries all the states (loading, error, success, stale) as a single prop. You don't need to split your component to test the loading state. You don't need a separate wrapper to test the error state. The store is the complete async lifecycle in one value.

Storybook​

export const Loaded = () => (
    <UserCard store={RemoteDataStore.fromValue({ name: 'Alice', email: 'alice@example.com' })} />
);

export const Loading = () => <UserCard store={RemoteDataStore.of(RemoteData.Pending)} />;

export const Error = () => (
    <UserCard
        store={RemoteDataStore.of(
            RemoteData.Failed([Failure.unexpected(new Error('Server returned 500'))], async () => {})
        )}
    />
);

export const Refreshing = () => (
    <UserCard
        store={RemoteDataStore.of(RemoteData.StalePending(RemoteData.Success({ name: 'Alice (stale)' }, new Date())))}
    />
);

Four stories. Four states. No mock server. No interceptors. No delay hacks to catch the loading state before data arrives. The stale-data-during-refresh state, which is almost impossible to capture in a Storybook story with most libraries, is just another constructor call.

SSR​

const store = useRemoteData(() => fetchUser(id), {
    initial: RemoteData.success(serverData),
    refresh: RefreshStrategy.afterMillis(30_000),
});

<Await> sees Success on the very first render. The HTML includes the real data. After hydration, the refresh strategy kicks in. No <HydrationBoundary>. No dehydration step. No serialization config. SSR with other libraries is complex because they serialize a global cache across the server/client boundary. When stores are props initialized with data, there's nothing to serialize.

The complexity budget argument​

Global caches work. react-query is a good library. Teams ship production apps with it every day without cache key collisions or stale data bugs.

But a global cache is still one more thing in your complexity budget. It's a QueryClient to configure. A provider to wrap your tree in. Cache keys to name consistently. Stale times to tune. Invalidation logic to get right. Devtools to learn. Hydration boundaries for SSR.

Each of these is individually manageable. Together, they're a system, and systems have a cognitive cost even when they work correctly. Every new team member needs to understand the cache semantics. Every debugging session needs to account for what the cache might be doing.

The question isn't "does a global cache work?" It's "do you need one?" For most components, the answer is no. Data is fetched by a parent, consumed by children, and garbage-collected on unmount. Component-scoped stores handle this with zero configuration. For the cases where you genuinely need cross-component deduplication, opt-in shared state handles it without imposing cache semantics on the 80% of components that don't need them.

Where this leaves us​

The principle is simple: make data a prop, and every context becomes easy. Testing is easy because you can manufacture the prop. Storybook is easy because you can manufacture the prop. SSR is easy because you can manufacture the prop. The component doesn't know and doesn't care.

This isn't a new idea. It's React's original idea (components are functions from data to UI) applied to async state. The store-as-prop interface makes the components independent. The rest follows.

I won't pretend this is free. You give up automatic deduplication by default (though it's available opt-in). You give up devtools (though debug: console.warn traces every state transition). You accept that data flows through the tree as props, which sometimes means passing a store through a layer or two that doesn't use it directly.

In exchange, you get components that are genuinely independent. That work in tests without infrastructure. That render in Storybook without timing hacks. That support SSR without hydration boundaries. That compose into typed tuples with surgical retry.

Values compose. That's the whole post.