diff --git a/site/blog/2026-05-20-values-all-the-way-down.mdx b/site/blog/2026-05-20-values-all-the-way-down.mdx
new file mode 100644
index 0000000..5a81b65
--- /dev/null
+++ b/site/blog/2026-05-20-values-all-the-way-down.mdx
@@ -0,0 +1,248 @@
+---
+title: The missing prop
+authors: [oyvind]
+tags: [react, typescript, architecture]
+---
+
+# The missing prop
+
+Here's a claim that sounds too simple to be interesting: **if your component receives data as a prop, testing, SSR, and Storybook all become the same trivially easy operation.**
+
+{/* truncate */}
+
+Not easier. Not "easier with the right setup." Trivially easy. Three lines. No mocks, no providers, no async coordination, no timing tricks:
+
+```tsx
+// Test
+render();
+expect(screen.getByText('Alice')).toBeInTheDocument();
+
+// Storybook
+export const Loaded = () => ;
+export const Loading = () => ;
+
+// 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 ``. 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 ``. 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 `` needs a `userStore` prop just because some deeply nested `` 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:
+
+```tsx
+// Instead of this (drilling userStore through Layout)
+function App() {
+ const userStore = useRemoteData(() => fetchUser());
+ return ; // 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 (
+
+ {(user) => }
+
+ }
+ />
+ );
+}
+```
+
+`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:
+
+```tsx
+// 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:
+
+```tsx
+function Parent() {
+ const userStore = useRemoteData(() => fetchUser());
+ return (
+
+ {(user) => navigate(`/users/${user.id}/posts/${postId}`)} />}
+
+ );
+}
+```
+
+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:
+
+```tsx
+function UserCard({ store }: { store: RemoteDataStore }) {
+ return (
+
+ {(user) => (
+
+
{user.name}
+
{user.email}
+