Replies: 2 comments
-
|
If the request comes with files cloning it will mean cloning that too, so just by adding this middleware the memory consumption of any request with files will double, if those are large files that can become a huge issue. If you need to read FormData, I would recommend to:
I would probably do the first option. |
Beta Was this translation helpful? Give feedback.
-
|
This makes sense - Thanks for the quick follow-up. While exploring out various things, I ran into one usecase that still seems odd. I'd be curious to find out why it works the way it does: // we have a custom function somewhere
// contact.server.ts
export async function handler() {
// note: we use the request from our helper fn
const request = getRequest();
const formData = await request.formData();
}
// this is a resource route that exports an action that can handle different forms based on their "intent".
// it imports our contact handler and executes it.
// routes/api/forms/submit
import { handler } from "./contact.server";
// note: we use the "raw" request from the actions params
export const action = async (ctx: Route.ActionArgs) => {
const formData = await ctx.request.formData();
const intent = formData.get("__intent");
// some more code
handler();
}Now, this obviously breaks: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi!
I am not sure whether this deserves to be a bug report, but I figured I start it as a discussion. When using the
requestfromcreateContextStorageMiddleware.getRequest, I sometimes run into the situation that the body has already been consumed. eg. if I need to read the formData twice. However, if Iclonethe request, I get yet another error saying the body is unusable.I wonder if we should store a clone right away? I patched my local package with this and it seems to work as expected. Not sure if this has other implications though?
Beta Was this translation helpful? Give feedback.
All reactions