purescript-web / purescript-web-fetch

Types and low-level implementations for the Fetch API
MIT License
8 stars 6 forks source link

Add `RequestBody.fromFormData` #12

Open paluh opened 2 years ago

paluh commented 2 years ago

Hi,

As usual - thanks for providing and maintaining this lib!

fetch supports FormData as a payload:

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#uploading_a_file

I can provide a PR but it requires additional decision - FormData is a part of purescript-web/purescript-web-xhr:

garyb commented 2 years ago

I'd probably add a web-xhr dependency since FormData is defined in the spec for that.

garyb commented 1 year ago

Looks like we might want to extract it into a contrib repo or something after all, since fetch is now available in node too - fully supported without a runtime flag as of v18.

(There may also be some other aspects of this library or web that need similar behaviour, if there are other things that overlap fetch and xhr, etc.)

/cc @sigma-andex @i-am-the-slime

garyb commented 1 year ago

I've been pondering this yet again...

It's true that Blob, FormData, and fetch are now available in node, but they are still based on the W3C and WHATWG specs that the -web-file, -web-xhr, and -web-fetch libraries provide, so I'm not sure that disentangling them from those specs is necessarily the right approach.

It is true that some of the interface bindings that are provided won't work in node, but I'm not sure how much that really matters? It's arguable that not all of the API exposed by these libraries work in all browser situations either.

The most correct way to resolve this would probably be through some kind of capability-availability-providing mechanism (a typeclass I guess) to help document/enforce exactly which features are available in what situations, but that's perhaps overkill.

sigma-andex commented 1 year ago

One thing to keep in mind is that afaik the xhr on node requires a node dependency (xhr2, which is btw not maintained anymore). This is really a pain in SSR frameworks like nextjs. Since you suddenly need a node dependency which theoretically ends up in your front end code. This was also the original motivation to write yoga-fetch so it can be used with next.js without having to rely on a node dependency. I'm not sure if this can be mitigated for xhr, but given that xhr is basically legacy I personally would rather break this up than spending time on making the xhr work without node dependency.

garyb commented 1 year ago

Using FormData from web-xhr wouldn't require the dependency on xhr2 - FormData is already available in the global node scope in v18+.

I just did a quick test to confirm:

module Main where

import Prelude

import Debug (traceM)
import Effect (Effect)
import Web.XHR.FormData as FormData

main :: Effect Unit
main = do
  fd <- FormData.new
  traceM fd
FormData { [Symbol(state)]: [] }