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.

[surnr]

Is there any inbuilt way of accessing data through store like in zustand in react router?, I'm using context in middleware to store permissions and access in different route but eventually doing permission props drilling