Form data support about fable-fetch HOT 5 CLOSED

Hello,

I think it's commented because when writing this library we didn't port the FormData type yet. Now it has been ported in Browser.XMLHttpRequest.

I don't know if we want a deps over that library or not for Fable.Fetch? cc @alfonsogarciacaro

For now, you can temporarily use dynamic typings using ? operator from Fable.Core.JsInterop body?formData

from fable-fetch.

Ah, you're right @MangelMaxime, I think that was the reason. Hmm, the main problem of Browser.XMLHttpRequest is it also pulls the Browser.Dom dependency, and I was thinking of making this package independent of it so it's a better fit for non-DOM environments like web workers or node (with a fetch polyfill).

Maybe we could just add the FormData definition to this package. It won't be compatible with Browser.XMLHttpRequest.FormData but hopefully it's not an issue.

Hmm, it seems FormData only makes sense in combination with HTMLFormElement so it would need a DOM dependency anyways 🤔

from fable-fetch.

Well, I guess the Browser.Dom dependency shouldn't do much harm even if you're in a non-DOM environment, so we could add FormData from Browser.XMLHttpRequest anyways. Thoughts?

from fable-fetch.

Hmm, it seems FormData only makes sense in combination with HTMLFormElement so it would need a DOM dependency anyways

I am pretty sure some people made it work even on node.js side for whatever reason ^^(speaking of raw JavaScript here).

Also, HTMLFormElement is an optional argument as you can see here

Well, I guess the Browser.Dom dependency shouldn't do much harm even if you're in a non-DOM environment, so we could add FormData from Browser.XMLHttpRequest anyways. Thoughts?

I suppose having it as a peer dependency is ok. In theory, the user should know that in a non-browser env he can't use all the Browser. modules same as in JavaScript.

Another solution I see is to move FormData to Browser.Blob add here the constructor without HTMLFormElement arguments. And then make Browser.XMLHttpRequest dependant over Browser.Blob and add in this package a version of the constructor with HTMLFormElement.

It seems to make sense to have it under Browser.Blob because of FormData.append accepting blob as one of the valid type. That's probably why we have value: obj in the definition.

The field's value. This can be a USVString or Blob (including subclasses such as File).

MDN

from fable-fetch.

That's a good idea, let's do that!

from fable-fetch.