Wrap FormData effects.

[i-am-tom]

As the FormData manipulations are effectful, they should live within the
ST monad. This commit exposes the methods for mutating the object behind
the ST wrapper!

[hdgarrood]

I'm not generally much involved with this repo but since you mentioned it on Slack I thought I might do a quick drive-by review...

Often for an API based on ST you'll want to provide two versions of things: a mutable and immutable version. The mutable version should have a type variable which will match the type variable given to ST, so e.g. FormData for the immutable version and STFormData h for the mutable one: this is necessary to ensure that references to the mutable variable don't escape the scope of the ST computation. Also, with a function like toFormData, the mutation you're doing within the function isn't observable from outside it, so I don't think the consumer needs to know you're using ST internally, and therefore I would recommend not having the ST effect in the type signature.

[hdgarrood]

I think there are some other APIs in this repo which make use of mutation but don't use ST though, so perhaps DOM is enough..?

[garyb]

I'm afraid this isn't quite right. We'll need a FormDataST type too, to carry the h, and then have a freeze/thaw to convert the mutable FormDataST into FormData, and then only provide the mutation functions for the FormDataST type. Take a look at the STArray and STStrMap stuff for an example of what I'm talking about... if that doesn't make sense still, well, see you on Slack 😄

[garyb]

Damn it Harry 😆

[hdgarrood]

lmao