[Feature]: access loadContext from handleDocumentRequest

[JimLiu]

What is the new or updated feature that you are suggesting?

access loadContext from handleDocumentRequest

  createRequestHandler({
    getLoadContext(req, res) {
      // this becomes the loader context
      return { expressUser: req.user };
    }
  })

// entry.server.js

export default async function handleRequest(
  request: Request,
  responseStatusCode: number,
  responseHeaders: Headers,
  remixContext: EntryContext,
  loadContext: LoadContext
) {
  const { expressUser } = loadContext;
  // ...
}

Why should this feature be included?

For custom express services, it is very important to be able to access req and res, not only in the loader function, but also in handleDocumentRequest!

[ryanflorence]

I've thought about adding load context here, maybe one day we will, but you should be able to do anything you need to do inside the root.js loader. handleRequest is just about calling the right React APIs to send a response.

[JimLiu]

I've thought about adding load context here, maybe one day we will, but you should be able to do anything you need to do inside the root.js loader. handleRequest is just about calling the right React APIs to send a response.

Thanks for the reply, but it may still not solve my problem.

My application scenario is a bit complicated, so let me explain it briefly.

First we have a public layout, but this layout is not a local component, but a remote service that needs to send an http request and needs to pass in different parameters to get the layout needed for the current page.

e.g.
a page with layout:

<Layout showLiteHeader platform="mobile">
  <MyPageContent />
</Layout>

it sends a request to a server to get the layout:

https://remote-layout.xxx/layout?showLiteHeader&platform=mobile

So the challenge is that I need to get the parameters of the layout first and then send the http request before rendering the page content.

So my current approach is relatively simple and straightforward, which is rendering twice, getting the parameters for the first time, then sending a layout request, and rendering twice after getting the layout results.

  const layoutManager = new LayoutManager();

  // pre-render to get layout options
  renderToString(
    <LayoutContext.Provider value={layoutManager}>
      <RemixServer context={remixContext} url={request.url} />
    </LayoutContext.Provider>
  );

  await layoutManager.fetchLayout(request); // it needs the original `req` of express

  const markup = renderToString(
    <LayoutContext.Provider value={layoutManager}>
      <RemixServer context={remixContext} url={request.url} />
    </LayoutContext.Provider>
  );

The request in handleDocumentRequest is not the original req object of express, so many of our internal plugins can't be used properly, and it would be too costly to rewrite it, which leads to us not being able to send layout requests properly in handleDocumentRequest.

The main problem with root.js solution is that I can't pass the parameters of the layout (e.g. showLiteHeader&platform=mobile) into the loader if this layout request is put into the root.js loader.

Is there anyway to pass params to a loader from a component instead of url params? e.g.

let products = useLoaderData({ productId: 123 });

Thanks

[guillaumervls]

Hi @ryanflorence and thanks for the great work on Remix !

If I understand it right, there's actually (at least) one big difference between handleRequest and root.js's loader : handleRequest runs after every loader (and also not when one of the loaders redirects). So that's really relevant to access the context in handleRequest to avoid race conditions (since it typically is a shared object).

My use case is to commit the session (and save it to my remote session store). If I do this in root.js, it'll be committed every time, including when another loader is redirecting (e.g. when the page for a list of items is empty, I redirect to the item creation page). But in root.js I also read flash messages from the session (to show a notification). So upon redirection the root.js loader removes the flash message (because it's reading it and committing) so it never makes it to the UI (it's just a redirection).

For now I'm using a global LRU cache, to access the session in handleRequest but I'm wary about this, and would rather have a proper per-request cache/context.

Am I missing something ?

Cheers !

[luishdz1010]

I need to inject a logger object (with Request information enclosed, so it can't be a global like console.log) during SSR. On the client it is replaced by a brand new logger instance. This is my express-based workaround to pass objects from the express context into the server rendering phase. This is a very hacky one but using a LRU cache is not feasible in my case. Proceed with caution:

// server.ts
// first inline createRemixRequest, we need access to the request returned by createRemixRequest
const request = createRemixRequest(req)
request.__my_custom_logger = ... // use request instead of loadContext, as it is not currently supported
const response = await handleRequest(
  request,
  loadContext,
)
...

// entry.server.ts
// we can't do remixContext.__my_custom_logger = value because the context is destructured
// before being passed to RemixEntryContext/
// so we tunnel it through appState 
remixContext.appState.__my_custom_logger = request.__my_custom_logger

// root.tsx
 const remixContext = useContext(RemixEntryContext) // RemixEntryContext is exported from /dist,
                                                    // the export could break at any time
 const serverLogger = remixContext?.appState.__my_custom_logger 

[incepter]

I missed this discussion until I created a similar one.

+1