Re-introduce AppLoadContext as ServerBindings

[sergiodxa]

The new RouterContextProvider is great for middleware as you can safely read and write there

But AppLoadContext is great for cases where the HTTP server does need to inject things into RR apps, this is more common in CF apps where you receive D1, KV, R2, etc. bindings from AppLoadContext in your RR app, but it's also something apps may need to do with getLoadContext in other servers, for multiple reasons, specially when supporting older infrastructure.

This is why I thought that to keep both ideas, context can be repurposed for RouterContextProvider for middleware usage, and introduce a bindings argument (typed as ServerBindings interface) that can be used by server adapters

So in CF or another server you can do

let response = await handler(request, bindings)

Where bindings here is a ServerBinding object, and the server is in charge of typing it

declare module "react-router" {
  export interface ServerBindings {
    db: D1Database;
    kv: KVNamespace;
  }
}

But I would do a difference here, I would type loader, action and middleware args as Readonly<AppLoadContext>, and at runtime freeze the object too.

Then in one of those functions you will do:

export async function loader({ request, params, context, bindings }) {
  // bindings are ServerBindings
}

To ensure this bindings are considered something that RR apps only can read, but not change at runtime, if you want that use RouterContextProvider.

This is not only useful for CF apps that will be able to keep accessing CF bindings this server, but also other apps like Express that may need to support old code like maybe a data layer and inject it into RR

---

I know I can do this with RouterContextProvider by returning a Map in getLoadContext.

But AppLoadContext is just simpler to use, and gives a better DX for any code that doesn't need to be in a middleware.

As you don't need to import anything (e.g. import the context object), and you can just do context.something, and you know something will be there because your HTTP server is in charge of passing it

The RouterContextProvider should be limited to only middleware functions and not for the HTTP server usage instead.

[brophdawg11]

But AppLoadContext is just simpler to use, and gives a better DX for any code that doesn't need to be in a middleware.

I don't think the DX is much worse? It's 2 main changes for route files, assuming you stick your server context into a single object in the context provider:

• A new import for your context instance (import { serverContext } from "...";)
• context.db -> context.get(serverContext).db

The DX for appLoadContext was a tiny bit simpler at the cost of a worse typesafety and discoverability story.

The RouterContextProvider should be limited to only middleware functions and not for the HTTP server usage instead.

I personally think of the getLoadContext as sort of "just another middleware" that runs before the root route. In one of original implementations (before we tabled it for single fetch), opting into middleware replaced getLoadContext with an adapterMiddleware function to make that association clearer. But bubbling/handling errors from next becomes trickier at that level since you're outside of Remix.

Having separate context and bindings feels more confusing to me (plus more to maintain/document) when they are both "data injected earlier in the request flow".

[firxworx]

"at the cost of a worse typesafety and discoverability story"

You nailed it right there @brophdawg11!!

---

When I read that it was for "similarity to React.createContext" I couldn't understand why for a back-end / server-side functionality one would take inspiration from React and ultimately context of all things.

As I understand it, React Context benefits from Map-like approaches for performance -- zillions of components to render, lots of reading and writing going on, etc.

Meanwhile server-side context touched perhaps a handful of times during the servicing of a request by maybe some middleware and then finally in a loader or action.

Given that, I think the discoverability and type-safety wins out as well as the aforementioned developer familiarity , especially since back-end concepts and patterns are very stable and well-established; lots of solved problems unlike with front-end.

I think for remix/RR new devs should find that it builds on concepts from web development that they might already know.

Beyond being a curveball to backend devs, I think the pattern will confuse many front-end devs too. I don't think most could talk about how map and context are related as much as they can speak to how useState is really useReducer.

I argue that the average rank-and-file devs exposure to React context is using hooks like useAuth() or useTheme() with custom providers that encapsulate and abstract away the context API. These days they don't even see it or touch it a lot of the time.

The obscure take also means LLM's are unlikely to be very helpful to struggling devs.

---

I tried the new middleware in a playground app and vs. my previous project (first project ever in remix/RR) where I had a hono back-end and populated type-safe context (and also have full access to it via async local storage) it felt like a lot was missing.

A degree of type safety was gone, IntelliSense suggestions were gone, and I actually had more code in my actions and loaders vs. when I could e.g. be in an action and type context: { and have IntelliSense and auto complete for my db, i18n, etc.

Especially coming from hono where types just work and get passed down auto-magically and just work it felt less elegant.

RR has me editing .d.ts files and casting things... IDK. with hono I can change something in a middleware and poof there it is all the way over in my route with everything inferred or derived along the way.

---

Where does this lead ?

Discussions like this one, I get where Sergio is coming from (at least I think I do).

I think overall there's a risk of tending towards more complexity, and RR becoming more esoteric and obscure vs. easy and intuitive to pick up.

I'd benchmark against patterns with custom back-end and would challenge if the dev X is not as smooth than a pure RR solution for context + middleware then its a sign.

[rossipedia]

I have some strong opinions on this topic, I'll probably be adding more comments after this one, but my biggest disagreement is with this:

The DX for appLoadContext was a tiny bit simpler at the cost of a worse typesafety and discoverability story.

I don't think that AppLoadContext had either of those things. I'll even go further and state that RouterContextProvider has a demonstrably worse discoverability story, and since a picture is worth 1000 words, so to speak:

With RouterContextProvider, there is zero tooling assistance to help you understand what's available on context. You have to move away from the function you're writing to go find out what's there. You have to know where to import it from. You have to add more code to use things on context.

Granted, there is limited flexibility/composability with AppLoadContext, but I'd argue that in many cases you don't want that. Especially in an enterprise environment where you're providing a well-known set of primitives/tools to your engineers that they all must use.

However, I want to make clear that I don't think these things are mutually exclusive. I believe both approaches have their strengths and weaknesses, and more importantly serve different purposes.

AppLoadContext is critical in its current form for the apps I'm supporting. It's used to provide common tools that are guaranteed to be available in every loader/action across all of our applications.

Engineers can create a new route and immediately have access to the entire toolkit, no extra imports needed. This is not something I can provide with RouterContextProvider, and indeed if I have to tell my engineers that they need to add both a new import and an extra call to context.get(...) to retrieve the same toolkit that was previously available to them... that's gonna be a hard sell. And if I don't see the benefit, then I'm not going to be able to convince them otherwise, to be honest.

Regardless of whether or not there's a separate "bindings" or whatever you want to call it, the ability to provide a common set of... things... that are immediately available without any ceremony (import { blahContext } from 'somehwere'; and context.get(blahContext)) is, in my opinion, critical for a good DX. At least for the apps and devs I'm supporting.

Removing that ability for little to no benefit would leave a bad impression on both me and my engineers.

[purplesquirrels]

DX and type safety aside, the new context API changes mean we can no longer inject external dependencies into RR which is critical functionality that has been removed. It needs to be reinstated through the bindings proposal or some other form to avoid needlessly breaking or preventing the ability to update RR apps

[brophdawg11]

Why not? You still have getLoadContext in which you return an initial Map of contexts/values.

[purplesquirrels]

Because getLoadContext now requires returning a map where the key is a context created by unstable_createContext so the context needs to be imported on both sides. This isn't possible unless both the RR app and the external environment (eg Express server) are bundled together, which isn't necessarily a viable solution.

[gustavopch]

As a workaround, you can bundle them together like this: remix-run/remix#9790 (reply in thread)

[purplesquirrels]

thanks @gustavopch, after a bit of faff I was able to kind of get it working based on the comment in that thread. I say kind of because while the context and middleware is working, it has broken HMR - I have to restart the server if I change any actions or loaders, and I get hydration errors in components when they are changed if I reload the page.

when editing a loader:
Error: [react-router:hmr] No module update found for route...

when editing a component:
Warning: Text content did not match. Server: "old text" Client: "hmr updated text"

I'll keep digging, but it seems like providing an equivalent API to what existed before would be much simpler.