search

fable-compiler / fable-fetch

Fable bindings for Browsers' Fetch API
MIT License
17 stars 8 forks source link

Form data support #4

Closed retendo closed 5 years ago

retendo commented 5 years ago

Hi, I noticed that form data support was commented out in one of the beta commits. Do you have any plans on putting it back in? Any recommendations what to use instead when you need to support form data?

MangelMaxime commented 5 years ago

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

alfonsogarciacaro commented 5 years ago

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 🤔

alfonsogarciacaro commented 5 years ago

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?

MangelMaxime commented 5 years ago

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](https://developer.mozilla.org/en-US/docs/Web/API/FormData/append#append()_Parameters)

alfonsogarciacaro commented 5 years ago

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