Add FormData under melange.dom

[davesnx]

Moved and adapted FormData from https://github.com/melange-community/melange-fetch/blob/master/src/Fetch.ml

Since reasonml/reason-react#846, React would benefit to have FormData as part of melange.dom rather than their own bindings

PS. Fixes a documentation typo in the first commit.

[davesnx]

I'm not really happy with the classify, but I haven't seen any other way to achieve support for File

[anmonteiro]

Can you show me examples of why classify is needed?

[anmonteiro]

I'm reading it in reasonml/reason-react#846, but I wonder whether this is needed at all or if folks can classify it downstream, or even use Js.Types.classify.

Besides, if we were to keep this, I'd rather call it Blob than File, since File is a subclass of Blob.

[davesnx]

Totally, the discussion for 0 runtime goes away if we remove this. If it's needed can be added in webapi

[davesnx]

it's a bit weird that entryValue is provided by this module but unnaccessible from this module, but it's simpler to keep it like this

[anmonteiro]

How is this working in DOM? my understanding is that this code is being added to melange.belt:

melange/jscomp/others/dune

Lines 8 to 20 in dd13b62

	(modules
	:standard
	\
	node
	node_buffer
	node_child_process
	node_fs
	node_module
	node_path
	node_process
	node_process
	dom
	dom_storage)

this code doesn't compile locally:

        melc jscomp/others/.dom.objs/melange/dom.{cmi,cmj,cmt} (exit 2)
File "jscomp/others/dom.ml", line 296, characters 18-30:
296 | module FormData = Dom_formData
                        ^^^^^^^^^^^^
Error (warning 49 [no-cmi-file]): no cmi file was found in path for module Dom_formData

[anmonteiro]

One issue with form data here is that it sort of breaks the assumption that melange.dom only has types, and no functions.

What do you think about adding the necessary types in this PR and then making a small library for form data using those types?

[anmonteiro]

append also takes a ?filename

[davesnx]

append can't have a filename when it's a string. appendBlob or appendFile is used and have the ?filename there

[anmonteiro]

this function doesn't return entryValue option, but rather null when not found. we should use [@@mel.return null_to_opt]

[anmonteiro]

set also takes ?filename

[davesnx]

same as append. Can't have a filename when it's a string. setObject or setFile or setBlob can be used and have ?filename

[davesnx]

Do you prefer to keep bindings outside of melange.dom?

There's currently dom_storage (and this PR adds FormData and future prs add Blob and File). Moving those into another lib sounds good melange.web, maybe? Better inside this repo or outside?

[davesnx]

As far as I know dom is just a dependency of melange.belt, and there's a library (name melange.dom).

[anmonteiro]

I think that FormData isn't really specific to JS environments that have a DOM, so this could rather be added to Js.FormData. what do you think?

[davesnx]

That make sense, moved also https://github.com/melange-re/melange/pull/1218/files into js

[davesnx]

Don't understand why opam macos fails while ubuntu is ok

[anmonteiro]

@davesnx what do you think of the new API for set and append? I think we can get away with a single function for each and use @mel.unwrap for polymorphism.

[anmonteiro]

@davesnx what do you think of the new API for set and append? I think we can get away with a single function for each and use @mel.unwrap for polymorphism.

in 32cf627 I changed it again to take the distinction between blobs / primitives into account (the functions only accept filename as a third argument if the 2nd arg is a Blob).