Skip to content

Add RequestBody.fromFormData #12

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

Open
paluh opened this issue Aug 6, 2022 · 5 comments
Open

Add RequestBody.fromFormData #12

paluh opened this issue Aug 6, 2022 · 5 comments

Comments

@paluh
Copy link

paluh commented Aug 6, 2022

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:

  • Do we want to extract this part into separate small lib like purescript-web/purescript-form-data?
  • Or depend on web-xhr?
@garyb
Copy link
Member

garyb commented Aug 6, 2022

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

@garyb
Copy link
Member

garyb commented Nov 20, 2022

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
Copy link
Member

garyb commented Nov 26, 2022

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
Copy link

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
Copy link
Member

garyb commented Nov 27, 2022

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)]: [] }

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