Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DataCloneError: FormData object could not be cloned #861

Closed
jed-meyer opened this issue Jun 14, 2019 · 7 comments
Closed

DataCloneError: FormData object could not be cloned #861

jed-meyer opened this issue Jun 14, 2019 · 7 comments

Comments

@jed-meyer
Copy link

jed-meyer commented Jun 14, 2019

Trying to add FormData to IDB using Dexie on Angular results in the above error. This is the case even if FormData is empty so it has nothing to do with contained items.

The MDN structured clone docs mention that FormData cloning is supported. Is this due to Angular messing with FormData objects then? console.log(formData) displays an empty object which seems weird. Iterating over formData's properties won't show anything accordingly.

@dfahlander
Copy link
Collaborator

Hard to tell. You're right FormData should be clonable and storable in IDB according to spec, but I have no explicit test for it. I think you need to find out whether the formdata is an actual FormData instance or an NG-specific FormData.

@jed-meyer
Copy link
Author

jed-meyer commented Jul 2, 2019

Seems like it's native FormData we're talking about.

Created a stackblitz showing the issue: https://stackblitz.com/edit/angular-issue-repro2-k5dtnx

Chrome 75: "FormData object could not be cloned"
FF 67: same

Since a native IDB call results in the same error, it's probably not a bug in Dexie but MDN/specs/virtually all implementations. Or I'm doing something stupid.

@dfahlander
Copy link
Collaborator

I think I was wrong about FormData. It's not part of the structured cloning algorithm: whatwg/html#633 so behavior is expected in IndexedDB.

@jed-meyer
Copy link
Author

jed-meyer commented Jul 3, 2019

MDN is wrong then, see the FormData entry in Supported types table (in row Object) at https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm

@angelaki
Copy link

angelaki commented Nov 8, 2022

Any news on this? Suffering the same issue. FormData doesn't seam to be cloneable The structured clone algorithm. Guess it should get supported, it's nothing but a {[key: string]: File | string } where File is almost a Blob.

@dfahlander
Copy link
Collaborator

Any news on this? Suffering the same issue. FormData doesn't seam to be cloneable The structured clone algorithm. Guess it should get supported, it's nothing but a {[key: string]: File | string } where File is almost a Blob.

This is a limitation in the W3C standard and nothing that dexie should work around IMHO.

@angelaki
Copy link

angelaki commented Nov 8, 2022

Yeah, your totally right! Just wanted to take part in this discussion. Here my solution right now:

    if (serializedRequest.body instanceof FormData) {
        serializedRequest.body = Array.from(request.body.entries());
        serializedRequest.bodySerializationType = 'form';
    }

    switch (request.bodySerializationType) {
        case 'form': {
            const formData = new FormData();
            for (const e of <[string, FormDataEntryValue][]>body) { formData.append(e[0], e[1]); }
            body = formData;
        } break;
    }

and put this object in the store.

@dfahlander, where to bring up the idea to natively support FormData by W3C? Do you have an idea?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants