🗺️ Loader + Action Context (Middleware) #9564
Replies: 31 comments 61 replies
-
|
From @jacob-ebey: I like this quite a bit. The parallels to React context are nice and should be easy to teach. Avoiding mutation of a a loadContext like object is also nice. |
Beta Was this translation helpful? Give feedback.
-
|
From @jacob-ebey Open Questions:
// could be utilitized for your app and not live in every test
let t = dataFunctionTestHelper(loader | action);
t.context.set(userContext, { id: "yay!" });
// options to call loader / action
// get
let res = await t.fetch("/route");
// post
let res = await t.fetch("/route", new FormData());
let res = await t.fetch(new Request("/route", {
method: "post",
body: new FormData(),
}));
|
Beta Was this translation helpful? Give feedback.
-
Yeah totally. Just get your translations once at the root and grab them for every loader from load context. I've seen i18n handled a lot of different ways (every string for one language, every string for a single page but all languages included in it 😱) |
Beta Was this translation helpful? Give feedback.
-
|
As for test helpers, we can table that until after Remix is on React Router 6.4. I've got some notes I should post as another RFC that will help both testing and storybook envs. |
Beta Was this translation helpful? Give feedback.
-
Right now the unit testing story for react router requires no shimming with // Create a global singleton context for your axios instance with its interceptors
const axiosClient = axios.create();
const axiosContext = createLoaderContext(axiosClient);
let routes = [
{ index: true, loader: indexLoader },
{ path: 'about', loader: aboutLoader },
];
let router = createMemoryRouter(routes, {
// Accept global contexts at router creation time
globalContexts: [axiosContext]
}
function indexLoader({ context }) {
let client = context.get(axiosContext);
let data = client.get('/api/index');
return json(data);
}
function aboutLoader({ context }) {
let client = context.get(axiosContext);
let data = client.get('/api/about');
return json(data);
}This approach has 2 main advantages:
I know we've chatted about this before, and yes a module-scoped import would work just fine client-side here. But once we provide this feature, people are just going to provide this type of global stuff from their root Given that this solves the unit test issue and provides a bit of DX enhancement compared to a root Open questions:
|
Beta Was this translation helpful? Give feedback.
-
|
From @jacob-ebey Another note, I think this is a breaking change and would require a major release. loadContext is currently totally open for whatever you want, if we make it have a get and set method we are potentially breaking apps and are restricting what you can do with loadContext. |
Beta Was this translation helpful? Give feedback.
-
|
not breaking for React Router, but for Remix, yeah, we'd need an opt-in flag to the new behavior or figure something out |
Beta Was this translation helpful? Give feedback.
-
|
agreed - |
Beta Was this translation helpful? Give feedback.
-
|
Scratch that - SSR loaders already have a context in |
Beta Was this translation helpful? Give feedback.
-
|
From @brophdawg11 The only thing I can think of from a prior-art standpoint is Vue Router's beforeEnter, since they also support nested routes. But they don't address data-fetching in the same way and there's no type of "context" for passing data down the hierarchy AFAIK. I like the proposal, and prefer the react-like approach - primarily due to the ease of providing inferred typings for the TS crowd. A few off the cuff questions: I assume beforeLoader will be subject to the exact same shouldRevalidate logic as the loader? |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about useBlocker/usePrompt a lot lately. We should get together with Michael and figure out if there's a way to add it back without the problems from before. Either way, I don't think beforeloader is the spot for that, the uses cases are more about component state (dirty forms, really). |
Beta Was this translation helpful? Give feedback.
-
|
what about instead of |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it works quite like middleware people are used to where the result of one goes to the next in the chain. This is simply called before the loader and that's it. A middleware abstraction could then be implemented inside of I don't want people assuming that the result of Instead of middleware, we have a |
Beta Was this translation helpful? Give feedback.
-
|
Related issue in RR that I think would be resolved with this functionality: #9324 |
Beta Was this translation helpful? Give feedback.
-
|
It'd be nice if we could determine the dependency graph of the loaders based on inputs / outputs so that we could optimally run things in parallel. E.g. if theres a page like Might be able to determine those dependencies between loaders in the compiler. 🎶 Don't fetch JSON waterfalls 🎶 |
Beta Was this translation helpful? Give feedback.
-
|
I think the issue is that the beforeLoader may be throwing a redirect to |
Beta Was this translation helpful? Give feedback.
-
|
I like more the React approach over the Express-like approach, but I think it shouldn't be for loaders only, it should also include actions, this would allow me to define a middleware to protect nested route to only be accessible for authenticated users or users with a role, regardless of the HTTP method used to reach that route. |
Beta Was this translation helpful? Give feedback.
-
|
Totally will work in actions too, forgot to mention it! |
Beta Was this translation helpful? Give feedback.
-
|
how about |
Beta Was this translation helpful? Give feedback.
-
|
I think it'd be great if we could set/update response headers such as Set-Cookie in that new function. Will it be possible? |
Beta Was this translation helpful? Give feedback.
-
|
The challenge with this is if you do this in the I'd much rather have this work in the |
Beta Was this translation helpful? Give feedback.
-
|
Afaik. |
Beta Was this translation helpful? Give feedback.
-
|
There is the optional |
Beta Was this translation helpful? Give feedback.
-
|
Note that I believe with this change we'd have what we need: remix-run/remix#2045 |
Beta Was this translation helpful? Give feedback.
-
|
Made a discussion topic for this: https://github.com/remix-run/react-router/discussions/10004 |
Beta Was this translation helpful? Give feedback.
-
|
the context get/set functionality reminds me strongly of this library (cls-hooked), maybe it is something that can help you design this! will this before loader stuff work with client side transition in Remix? |
Beta Was this translation helpful? Give feedback.
-
Yes |
Beta Was this translation helpful? Give feedback.
-
|
This comment in vercel/micro is related: vercel/micro#8 (comment) I like the react approach more although I wonder if you could remove the Something like this: function createMiddleware(fn){
let weakMap = new WeakMap();
return function (ctx) {
if (weakMap.has(ctx)) return weakMap.get(ctx);
let promise = fn(ctx);
weakMap.set(ctx, promise);
return promise;
}
}
const getUser = createMiddleware(ctx => {
if (!token) throw new UnauthorizedErrors();
return user; // or whatever
});
function loader({ context }){
let user = await getUser(context);
return json({});
}You'd still need something like |
Beta Was this translation helpful? Give feedback.
-
|
How would you add these middleware to a router? |
Beta Was this translation helpful? Give feedback.
-
|
The router file would need a way to run functions before loaders and actions like you mentioned: // run all matched guards before running the action or loader.
// guards take the same `DataFunctionArgs` object as loaders and actions.
const matchesWithGuards = matches.filter((m) => m.route.guard);
await Promise.all(matchesWithGuards.map((m) => m.route.guard!({
request,
params: params,
context: requestContext,
})));
// run loader(s) for this request like normal.I don't think there's anything special here. Just a way to define a function that runs before loaders and actions for a route. The word beforeLoader implies that it runs before loaders, but I think it'd be helpful if it ran before actions too. For that reason, I'll use the word For example, if you had three routes that had a structure like this: <Route path="a" guard={guardA} loader={loaderA} action={actionA}>
<Route path="b" guard={guardB} loader={loaderB} action={actionB}>
<Route path="c" guard={guardC} loader={loaderC} action={actionC}/>
</Route>
</Route>The loaders would have these guard dependencies:
The "middleware" piece comes from the weakmap. If the guards use a weakmap to associate the promise back to the request, it doesn't matter what order the guards are called in. You could call them in parallel with const getToken = createGetter(async request => {
return await db.getToken(request.headers.get('authorization'));
})
const getUser = createGetter(async request => {
const token = await getToken(request); // <- explicit dependency
if (!token) throw new redirect('/login');
return await db.getUserFromToken(token);
})
// guard for GuardA at /a
export async function guard({ request }) {
const token = await getToken(request) // <- explicit dependency
if (token) db.renewToken(token);
}
// guard for GuardB at /b
export async function guard({ request }) {
const user = await getUser(request); // <- explicit dependency
if (!user.canAccess('/a/b')) throw redirect('/safe');
}
// guard for GuardC at /c
export async function guard({ request }) {
const user = await getUser(request); // <- explicit dependency
await logAccess(request.url, user);
}If you routed from const beforeLoader = async ({ context }) => {
context.user = await fakeSdk.getUser();
};
// say this is a child loader
const loader = async ({ context }) => {
context.user; // where does this come from? Can I jump to where this is assigned?
};Perhaps that's a long winded example of how it would work. Here are some noodlings of an implementation: Synvox#1 There are a number of issues with this PR. Consider it only concept art but it boils down to this:
/**
* @private
* Creates a memoized version of a guard that persists it's cache
* for the lifetime of a request.
*/
function createGuard(fn: GuardFunction): GuardFunction {
let weakMap = new WeakMap<Request, Promise<void>>();
return function (args: GuardFunctionArgs) {
const key = args.request;
if (weakMap.has(key)) {
return weakMap.get(key)!;
}
let promise = Promise.resolve(fn(args)).then(() => {
// make sure promise returns undefined.
});
weakMap.set(key, promise);
return promise;
};
}
// then elsewhere when a route is being initialized:
function initRoute(route) {
if (route.guard) route.guard = createGuard(route.guard);
return route;
}
type GetterFn<T> = (args: DataFunctionArgs) => T;
export function createGetter<T>(fn: GetterFn<T>) {
let weakMap = new WeakMap<AppLoadContext, T>();
return function (args: DataFunctionArgs) {
const key = args.context;
if (weakMap.has(key)) {
return weakMap.get(key)!;
}
let result = fn(args);
weakMap.set(key, result);
return result;
},
}
|
Beta Was this translation helpful? Give feedback.
-
|
I think this context-keyed (1) This feels like it's most beneficial when things run in parallel, like current loaders. Then I can absolutely see the benefit of being able to calling (2) I'm also struggling to see why this would need to live in the framework code? In the examples above the API for |
Beta Was this translation helpful? Give feedback.
-
|
Ignoring implementation code, I meant "how does an app add a middleware" with what you're proposing, and it looks like <Route path="a" guard={guardA} loader={loaderA} action={actionA}>I think that's exactly what I'm proposing here except I called it Everything else you're doing looks interesting but I don't think has anything to do with React Router. |
Beta Was this translation helpful? Give feedback.
-
I agree, and it's possible to do it right now with getLoadContext in Remix for example, there's an example using dataloaders for this, so you can re-use promises. I imagine in React Router it should be simpler since you're running inside the user browser (unless you setup SSR yourself) so you could keep the WeakMap in-memory or use something like TANStack Query as your cache layer. |
Beta Was this translation helpful? Give feedback.
-
|
Digging this proposal. Has there been consideration for how getting data from hooks will factor into this |
Beta Was this translation helpful? Give feedback.
-
|
The use case I'm imagining here revolves around setting anonymous user ids for a/b testing, feature flagging, and other frontend analytics. I suspect that the root route would need a Assuming I'm following this correctly, it seems like the root This gets to my question: would it be feasible to invoke |
Beta Was this translation helpful? Give feedback.
-
|
I think rather than calling So you could const beforeLoader = async ({ request, params, context }) => {
if (condition) return; // early return and do nothing
// do something that may take time
}; |
Beta Was this translation helpful? Give feedback.
-
|
Are there any special considerations that need to be taken for middlware with the recent addition of stream'd responses in Remix (ex: using |
Beta Was this translation helpful? Give feedback.
-
|
I don't think so? These will all execute prior to loaders so there won't yet be anything deferred in flight? |
Beta Was this translation helpful? Give feedback.
-
|
I think the only consideration is that because they run before loaders if you do slow things there it will block your response, so even if all loaders returned a |
Beta Was this translation helpful? Give feedback.
-
|
@ryanflorence For example, if you had a resource route to generate a PDF file, you may not need/want the i18n You could of course exit early from the i18n |
Beta Was this translation helpful? Give feedback.
-
|
@sergiodxa - that makes sense to me (I'm assuming most people have fewer resource routes than UI routes) |
Beta Was this translation helpful? Give feedback.
-
|
@sergiodxa then those apps that offer both UI and APIs through Remix miss out on the benefit of not having duplicated authentication middleware logic across all of their resource actions/loaders. Seems like there should still be a middleware approach that is available to all routes and not just UI routes. |
Beta Was this translation helpful? Give feedback.
-
|
I think your UI routes are most likely going to need middlewares that your API not, even common things like auth will most likely work differently, in an API you may want to check the Authorization header while on the web app you will check the session/cookie. |
Beta Was this translation helpful? Give feedback.
-
|
Even if the methodology is different, I think a form of middleware (even if it's different) should also be brought to the resource routes. You still may have 50+ resource routes that all check authentication the same way (whether or not is by cookie or auth header). |
Beta Was this translation helpful? Give feedback.
-
|
From a react router standpoint, I think the choice is entirely up to you. If you want Remix changes this slightly since it enforces a root route, but you could work around that with a pathless layout route for all your app routes and a sibling resource route that wouldn't have any |
Beta Was this translation helpful? Give feedback.
-
|
Just to confirm, if I've got a I'm also curious how this plays into |
Beta Was this translation helpful? Give feedback.
-
|
That's my understanding (and how it works in my current branch). Every single time a loader or action is called (regardless of document, data, resource, etc.) - it will sequentially call the before* method for all ancestor matches and itself. Since |
Beta Was this translation helpful? Give feedback.
-
|
Great 👍 Agreed. |
Beta Was this translation helpful? Give feedback.
-
|
What would be the best approach to set response headers with |
Beta Was this translation helpful? Give feedback.
-
|
I don't know that this would be the "best" way yet but this came up above and I think the current proposed context API could support it through a factory: #9564 (reply in thread). |
Beta Was this translation helpful? Give feedback.
-
|
@ryanflorence regarding your first open question:
Have you considered
Or, if you have considered it, but deem it too risky for now (the TC39 proposal is still in Stage 0 and the other implementations are behind some kind of feature flags or are marked experimental), it's at least worth keeping it in mind for future iterations of the API. |
Beta Was this translation helpful? Give feedback.
-
|
Btw, TC39 proposal has now advanced to stage 1! |
Beta Was this translation helpful? Give feedback.
-
|
Just to expand on React.cache using it, Nextjs also says to use React.cache to dedupe custom fetch calls (that don't use fetch) https://nextjs.org/docs/app/building-your-application/data-fetching/caching#react-cache |
Beta Was this translation helpful? Give feedback.
-
|
Would Remix use this API on the client or server side? Or both? I'm still hoping for a stable Remix API that would allow me to dynamically load additional blocking data/styles/scripts alongside a route's module and loader-data. (ref remix-run/remix#3355). |
Beta Was this translation helpful? Give feedback.
-
|
I think you're looking for |
Beta Was this translation helpful? Give feedback.
-
|
Wow! Thanks for making me aware of this! you're linking twice to the same discussion but searching for |
Beta Was this translation helpful? Give feedback.
-
|
Oops! Thank you for making me aware of that haha 🤦 |
Beta Was this translation helpful? Give feedback.
-
|
Is there a version of this that could be created that adds the hooks, but not the mutable context API? I'm not a huge fan of the mutable API being baked into remix/rr itself. What about leaving this up to the reader to attach their stores to the context themselves? This would allow users to take advantage of longer lived caching if required, as well as use |
Beta Was this translation helpful? Give feedback.
-
|
I think without the mutable context API most will not implement it correctly if they need to, and most of the time you will need to pass data from middleware to loaders/actions, for example to pass the authenticated user. |
Beta Was this translation helpful? Give feedback.
-
|
Seems pretty simple to do something like |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I agree, but this is more than dependency injection, it's more about re-using code for certain routes, for example you could put authentication in the HTTP server itself but then that would run on every route and not only the routes that require authentication. |
Beta Was this translation helpful? Give feedback.
-
|
What you would middleware composition look like with this new API? Recently stumbled upon this lib which takes a
|
Beta Was this translation helpful? Give feedback.
-
|
With this API, would beforeLoader be able to return deferred promises that all downstream loaders could individually decide to await for? |
Beta Was this translation helpful? Give feedback.
-
|
That should be fine - it's all Just Javascript™️ so sending a promise downstream should be fine so long as someone awaits it so you don't have dangling unhandled promises. |
Beta Was this translation helpful? Give feedback.
-
|
Note you can already do this in Remix export const onRequest: RequestHandler = createPagesFunctionHandler({
// @ts-expect-error -- https://github.com/remix-run/remix/issues/5466
build,
getLoadContext: (context) => {
// Make sure every loader gets the same request context object
let requestContext: Promise<RequestContext> | null = null;
return {
getRequestContext: async () => {
if (requestContext == null) {
requestContext = createRequestContext(context);
}
return requestContext;
},
};
},
mode: process.env["NODE_ENV"] ?? "production",
});Now each of your loaders can call It's not true middleware, but for this specific scenario I think it might offer everything that middleware could. |
Beta Was this translation helpful? Give feedback.
-
|
@aaronadamsCA - Do you know of a way to do this if the deployment target isn't Cloudflare Pages? Looks like your open issue (and subsequently, this example) is importing from |
Beta Was this translation helpful? Give feedback.
-
|
@EvanHammond Sorry for the delayed response. No, this part is not well-documented right now! I had no idea there was no equivalent to I can only say this much about how this appears to work on Cloudflare:
So I guess my "almost-middleware" solution is only possible on Cloudflare for now, at least until somebody can figure out how to make an entry point script work on another platform in the absence of real Remix middleware support. |
Beta Was this translation helpful? Give feedback.
-
|
I wish we could run certain functions "on our way in" and others "on our way out." For example, we can already run Today each loader/action must currently commit its own changes to the remote KV store, which increases load at both ends. (Edit: One question this idea raises is whether middleware cleanup should work like |
Beta Was this translation helpful? Give feedback.
-
|
I like this proposal, but I think it might miss the "afterLoader" middleware ? (or maybe it was planned for later) My use case: I want to wrap all my loaders and actions automatically in order to log the errors before forwarding them to the client. Currently I am doing this manually for each of them: export const loader = async ({ request }: LoaderArgs) => {
return errorHandler((request) => {
...
})
})Maybe I missed a better way ? |
Beta Was this translation helpful? Give feedback.
-
|
I do like the approach of "lifecycles" for routes from :
But what about adding a "middleware" to multiple routes? I think something like the layout route but for middlewares might work as well |
Beta Was this translation helpful? Give feedback.
-
|
I am attempting to integrate React Router into an existing project that utilizes Redux for state management, and I find it necessary to have a
To give a very simple example for the second case, it might look something like this: const beforeLoader = async ({ context }) => {
// assign new store for next page
context.store = createStore();
};
const loader = async ({ context }) => {
const { store } = context;
await Promise.all([
store.dispatch(fetchTheme()),
store.dispatch(fetchArticle()),
store.dispatch(fetchUser()),
]);
return { store };
};
const Root = () => {
const { store } = useLoaderData();
return (<Provider store={store}><Root /></Provider>);
}In both scenarios, it is crucial to have the But I am not asking for a Redux-specific feature. rather, just explaining that |
Beta Was this translation helpful? Give feedback.
-
|
FWIW for (1), the let store = createReduxStore();
staticHandler.query(request, { requestContext: { store } } );
// Then in your loader:
async function loader({ request, context }) {
// Redux store available in context.store
} |
Beta Was this translation helpful? Give feedback.
-
|
I think I can implement it as you suggested. However, I need to initialize the redux store in CSR for each page navigation, and SSR also needs to initialize the redux store by default, so I think the logic can be used together. I think beforeLoader is also important because the same logic can work in CSR and SSR. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, we definitely still need middleware and will be adding it as soon as Remix v2 is out, but I just wanted to point out that you can solve some of what you mentioned above currently during SSR in case that was of any use 😄 |
Beta Was this translation helpful? Give feedback.
-
|
@brophdawg11 is there a WIP PR for this now that v2 is out? would love to see a middleware in remix! :) |
Beta Was this translation helpful? Give feedback.
-
|
Can I just check that this proposal would mean that we could avoid having to inject the react-query client into our loaders like Dominik suggests here? https://tkdodo.eu/blog/react-query-meets-react-router#querifying-the-example. I'm assuming that the loader would have a context passed to it and when setting up the routes we can just add the QueryClient to that context. If that's the case, it unlocks a whole bunch of nice-to-haves (as far as I can tell) like being able to use lazy routes because you can just import the loader from the route module. Note that I'm asking in a react-router sense and not a remix one. |
Beta Was this translation helpful? Give feedback.
-
|
@charliematters I had this exact use case, and put up a proof of concept over here that aligns browser router functionality w static router (ability to pass request context that is passed to loaders). #10895 While it's a tiny code change, and seems to make sense since it just aligns functionality available on the server to also be available on client (request context), I don't know if it aligns with react-router maintainer's plans. |
Beta Was this translation helpful? Give feedback.
-
|
That looks like exactly the sort of API we'd benefit from, but as long as we can do something like that then I'd be really happy |
Beta Was this translation helpful? Give feedback.
-
|
👋 Hey folks! Now that v2 is out, middleware/context are back on the radar and being tracked in the Roadmap via remix-run/remix#7643 and remix-run/remix#7645 |
Beta Was this translation helpful? Give feedback.
-
|
Hiya, Just had a look at the two issues, and they both seem centred around remix and the server-side aspect of this. I came to this issue from a react-router SPA and not wanting to use a singleton to access things from loaders - #9856. Is that still going to be possible with these new features? |
Beta Was this translation helpful? Give feedback.
-
|
React Router should get middleware, per the RFC: 
I'm not sure about server context, feel free to leave a comment on that RFC! |
Beta Was this translation helpful? Give feedback.
-
|
This would be really, really nice. React Router 6 solves a very nice issue in being able to resolve data requests outside of React, avoiding the " We can make these even uglier if someone decides the best way to architect their app to avoid DRY concerns would be to use a React provider to hold rendering the application until the auth session call has completed, and additionally write to something like local storage to access the session outside of React. |
Beta Was this translation helpful? Give feedback.
-
|
Do we know if this RFC still going ahead? :) |
Beta Was this translation helpful? Give feedback.
-
|
Most recent talk of Middleware March 13, 2024 from Remix Roadmap planning Summary:Remix team has something working internally, but there working on things like:
There exploring how middleware concept will transfer over between what were use to (loader & action) + how it will work with React Server Components. They're trying to make the concept transferrable and the DX around it be straight forward 🙏 |
Beta Was this translation helpful? Give feedback.
and others
-
Background
There are some patterns in v5 that don't have a clear cognate in v6.
Patterns in v5
v6.4 loaders
With v6.4 loaders, there are no similar patterns, loaders just have to repeat the same code down the route hierarchy.
It's easy to miss one of these and in the case of Remix, accidentally expose a route to the public.
Remix
Remix users are begging for middleware for things like global redirects, protecting routes, and more. Even our own sites need it. This would serve as the base for that.
Passing data
There's no way to pass data from a parent loader to a child loader. You can use React context or
<Outlet context>to share data while rendering, but that only works for components, not loaders.Proposal:
beforeLoaderIt is proposed we add a
beforeLoaderhook to routes.The primary concern for us has always been that we want loaders to run in parallel to avoid waterfalls and therefore artificial performance issues.
This proposed API keeps most data loading parallelized, but adds the ability for apps to opt-in to serial data loading among route hierarchies when the need arises.
For example:
Protecting Routes
beforeLoaderfunctions will be called seriallybeforeLoadershave been been called, all matchingloaderswill be called in parallel (no change)Sharing Data
Before loader can be used to make data available to a route's own loader as well as the loaders of its child routes.
I have two API proposals here: express-like, and react-like.
Express-like middleware
This API already exists in a small way inside of Remix with
getLoadContext. Each loader/beforeLoader would receive acontextobject (like an expressreq) that beforeLoaders can mutate.context, so piggy back therecontexttypesloaders is wrong, and will make the values available in other loaders depending on the async timing of all of them running parallelReact-like context API
Calling a handful of unknown loaders in a hierarchy is basically the same thing as calling a bunch of components in a hierarchy. We could use a context API similar to
react-broadcastReact.createContext.React.createContextcontext.set/getTradeoffs
Open Questions
I'm pretty sure we need the
context.set(userContext, val)instead of the simpleruserContext.setso that multiple requests in Remix won't be colliding.context.setis ourReact.createElement(). It's what gives us control of a single request's context, instead of a global value shared by all users. That said, maybe there's a way to get around this that I'm not thinking of?This complicates testing loaders in isolation. While
createLoaderContexttakes a default value, might be useful to provide a test helper? As we get into implementation it might become more clear what, if anything, we should provide here.Is there prior-art to look to? The weasel here is nested routes. It's one thing to have middleware in a web framework like express where a single route handles a single request. Our task is different. A single URL matches multiple nested routes, we're not just trying to share data from one middleware to the next, we're trying to share it with arbitrary set of other matched routes. I can't think of any prior-art besides React.context.
Details
beforeLoaderare called serially beforeloadersloadersshould still be called in parallelcontext.get()should throw if the value has never been setcontext.set(type, undefined)should throwcontext.set(type, null)and any other falsey values (exceptundefined) should be allowedBeta Was this translation helpful? Give feedback.
All reactions