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)
}

[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