Data Context

[ryanflorence]

Data context allows you to create a value in one place and share it across loaders, actions, and middleware.

import { createDataContext } from "react-router"

// create a context
const DbContext = createDataContext<SomeDBType>()

// set a context in a middleware
function DbMiddleware({ context, request }) {
  let db = getDBFromRequest(request)
  context.set(DbContext, db);
}

// get a context in a loader
export async function loader({ context }) {
  let db = context.get(DbContext)
  // ...
}

[GiveMe-A-Name]

I prefer this one:

import { LoaderFunctionArgs } from 'react-router';

type Vars = {
  db: OutDb;
}

function DbMiddleware({ context, request }: LoaderFunctionArgs<Vars>) {
  let db = getDBFromRequest(request)
  context.set('db', db);
}

// get a context in a loader
export async function loader({ context }: LoaderFunctionArgs<Vars>) {
  let db = context.get('db')
  // ...
}

We don't need to import runtime code for type systems, Type System should not be invaded by runtime code.

[kiliman]

Your method makes it difficult to use third-party middleware with custom context. If they expose context for use in your loader, a string key may collide with another. By using an object as the key, you ensure that each middleware can export its own context.

[GiveMe-A-Name]

Yes, agree with you.
It's would occur, when user use many third-party middleware.

[sergiodxa]

What will happen on Remix/RRv7 when context is AppLoadContext?

[kiliman]

I think as long you don't have a get/set prop on your existing context, I think they'll co-exist. I support it in my middleware/context implementation.

[kiliman]

Here, I extend AppLoadContext with ServerContext

import { ServerContext } from 'remix-create-express-app/context'

declare module '@remix-run/server-runtime' {
  export interface AppLoadContext extends ServerContext {
    // custom app load context
    sayHello: () => string
  }
}

export {}

https://github.com/kiliman/remix-express-vite-plugin/blob/main/example/remix-vite-express/app/types/context.d.ts

[sergiodxa]

That is also supposing AppLoadContext is a plain object I imagine, recently I have been trying with using a class instance as my AppLoadContext, if they did { ...getLoadContext(), ...serverContext } it would break the code.

I think AppLoadContext should either become more strict to what it supports or be left as "this is an app thing" and separate ServerContext from AppLoadContext, even if it means adding a new key, maybe the current context can be named loadContext like it comes in entry.server.

[kiliman]

If they keep it separate, then they'll also need to pass in a different context to your loader, action, middleware.

Since it is RR 7 (a major change), I think they should make it so you have to create your own context and set it. The context going forward should only have get/set props and not a naked object.

// server.ts
const MyAppContext = createDataContext<AppLoadContext>()
function getLoadContext(context) {
  context.set(MyAppContext, { ... }
}

// routes/some-route.tsx
export function loader({ context }) {
  // context is now type of DataContext
  let appContext = context.get(MyAppContext)
}

[rossipedia]

A bit late to the discussion, but why not attach this to the request rather than AppLoadContext?

// create a context
const DbContext = createDataContext<SomeDBType>()

// set a context in a middleware
function DbMiddleware({ context, request }) {
  let db = getDBFromRequest(request)
  context.set(DbContext, db);
}

// get a context in a loader
export async function loader({ request }) {
  let db = context.get(request)
  // ...
}

Or better yet, allow for passing either context or request.

This would preserve backwards compatibility with existing AppLoadContext usage (I've got a ton of that going on here at Docker), and allow an incremental migration to the new pattern.

[ryan0x44]

When run on Cloudflare Pages/Workers, will a React Router 'Data Context' be a per-request instance, or will it be a global/potentially shared across multiple requests? (the latter behaviour would match env on Fetch Handler)

[sergiodxa]

Even outside CF I understand this is per request

[mebble]

What's the status of this? I'm looking to set values to a context but can't find createDataContext in react-router v7

[sergiodxa]

Since v7.3.0 this was added as createContext, which is part of the middleware feature

import { unstable_createContext } from "react-router";

[ziimakc]

Api is a bit confusing, I wanted to do auth before loaders in middleware:

export const serverAuth: Route.unstable_MiddlewareFunction = async (
	args,
	next,
) => {
	const res = await next(); // this will cause a loaders call which will error because context is not set

	const auth = getAuthFromCookieHeader(args.request.headers.get("cookie"));
	if (!auth) {
		return res;
	}

	if (!auth.userId || !auth.refreshToken) {
		AuthHelper.removeAuthCookiesInServerResHeaders(res.headers);
		return res;
	}

	if (!auth.accessToken) {
		const newTokens = await GqlClient.exchangeTokens(auth.refreshToken);
		if (!newTokens) {
			AuthHelper.removeAuthCookiesInServerResHeaders(res.headers);
			return res;
		}
		AuthHelper.setAuthCookiesInServerResHeaders({
			serverResHeaders: res.headers,
			accessToken: newTokens.accessToken,
			refreshToken: newTokens.refreshToken,
			userId: newTokens.userId,
		});

		args.context.set(authMiddlewareContext, {
			accessToken: newTokens.accessToken,
			refreshToken: newTokens.refreshToken,
			userId: newTokens.userId,
		});

		return res;
	}

	args.context.set(authMiddlewareContext, {
		accessToken: auth.accessToken,
		refreshToken: auth.refreshToken,
		userId: auth.userId,
	});

	return res;
};

export async function loader(args: Route.LoaderArgs): Promise<LoaderData> {
	return args.context.get(authMiddlewareContext);
}

But got an error No value found for context because await next() skips to loaders where args.context.get throws an error because context is not set.

I did a refactoring to make it work, but this is a bit counter-intuitive:

export const serverAuth: Route.unstable_MiddlewareFunction = async (
	args,
	next,
) => {
	args.context.set(authMiddlewareContext, null); // ensure that error is not thrown for loader getters

	const auth = getAuthFromCookieHeader(args.request.headers.get("cookie"));
	if (!auth) {
		return;
	}

	if (!auth.userId || !auth.refreshToken) {
		const res = await next();
		AuthHelper.removeAuthCookiesInServerResHeaders(res.headers);
		return res;
	}

	if (!auth.accessToken) {
		const newTokens = await GqlClient.exchangeTokens(auth.refreshToken);
		if (!newTokens) {
			const res = await next();
			AuthHelper.removeAuthCookiesInServerResHeaders(res.headers);
			return res;
		}

		args.context.set(authMiddlewareContext, {
			accessToken: newTokens.accessToken,
			refreshToken: newTokens.refreshToken,
			userId: newTokens.userId,
		});

		const res = await next();
		AuthHelper.setAuthCookiesInServerResHeaders({
			serverResHeaders: res.headers,
			accessToken: newTokens.accessToken,
			refreshToken: newTokens.refreshToken,
			userId: newTokens.userId,
		});

		return res;
	}

	args.context.set(authMiddlewareContext, {
		accessToken: auth.accessToken,
		refreshToken: auth.refreshToken,
		userId: auth.userId,
	});

	return;
};

Can we expose response in middleware without calling loaders to make it a bit simpler?

[sergiodxa]

If you need the response you have to call next, the response is created based on the loader/action response, RR doesn't work like Express where you receive both request and response already created.

If you want to do something before the loader/action runs do it before calling next.

Also this is the RFC for the proposal, for issues with the final implementation it's better to open a new issue.