Create a getRequest()
global function or similar
#6028
Replies: 5 comments 2 replies
-
Most JS runtimes can handle multiple requests at the same time, so it's not as simple as dumping the request in a global somewhere (the next request will override it). Might be able to do that in Node.js (in remix or just your app code) by creating a continuation local storage with Node's async hooks. I'm not sure the other runtimes like cloudflare, fastly, etc. have something like that though. |
Beta Was this translation helpful? Give feedback.
-
Looks like you're using Remix Auth // helpers/logActivity.server.ts
function logActivity(user){
// log activity logic based on the user
}
// route/some_route.tsx
export function loader({request}) {
const user = await authenticator.isAuthenticated(request);
logActivity(user);
} |
Beta Was this translation helpful? Give feedback.
-
@gabbanaesteban did you find any solution? I'm also looking for something similar. So I can access cookies on server side without explicitly passing the request object... |
Beta Was this translation helpful? Give feedback.
-
Recently saw that SolidJS's metaframework called solidStart has a similar concept to the proposed idea above called import { getRequestEvent } from "solid-js/web";
const event = getRequestEvent();
console.log(event.request.url);
event.response.headers.set("x-foo", "bar");
console.log(event.response.status);
event.response.status = 201; More details in their recent announcement:
Example usage of the API: |
Beta Was this translation helpful? Give feedback.
-
I need the request object inside the headers function to check an incoming cookie and weirdly enough it's not there in the params. There is all of this: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
What problem does this feature solve?
Currently, the only way to access the request object in a Remix application is through loaders/actions, which limits the ability to access request information deeper in the application.
Use-Case:
You need to filter an entity by the user id and log the activity (view, read, etc)
You can either have:
Fat loaders/actions: where all the business logic is consolidated, including retrieving query params, form data, and validating inputs before executing the business logic. While this can be a solution, it can also make the loader/action difficult to maintain and manage, especially as the application grows and becomes more complex.
Argument propagation: Pass the user down to all the functions/methods that require it, which can be cumbersome and tedious.
What does the proposed API look like?
The proposed API adds a new function, getRequest(), that can be used to get the current request object anywhere in the app. Here's an example of how it might be used:
or
By providing this global function, developers can access request information more easily and avoid the need to pass request objects or user object (in this case) around the application.
Beta Was this translation helpful? Give feedback.
All reactions