Add way to pass HTML form to FormData creation

[aronerben]

According to https://developer.mozilla.org/en-US/docs/Web/API/FormData/FormData, the constructor should be able to take an optional <form>/HTMLFormElement.

[aronerben]

As it is, this introduces a cirular dependency between Browser.Dom and Browser.Blob (therefore this is a draft), how should this be resolved? Should I extract FormData into its own file?

[MangelMaxime]

I suppose the only clean way to resolve would be to merge Browser.Blob and Browser.Dom together.

But if we go this way I wonder, if you should not merge back all the packages together. This would be easier for the consumer too because if he wants to target the Browser he would only have 1 package to import.

I think the original split was to make designing the API/Packages easier and also perhaps a faster compilation. I think faster compilation is false good idea in this case.

@alfonsogarciacaro What do you think?

[robitar]

I realise this has been idle for a while, but I would strongly agree with this (merging the packages).

As it is, it's a real hassle to find out which packages you should be referencing to bring in a specific platform feature. When you discover (as is often the case) that the feature you want hasn't been added yet, It also makes it more difficult to contribute bindings for it, because you have to create a new project and all that.

Having a single package would at least make that whole process less frustrating.

[MangelMaxime]

Hello @robitar,

There is a rework of Fable.Core planned for Fable 5.

I am ok with merging Fable.Browser into a single package, but it will be done once Fable.Core rework is done as the API are going to be changing slightly. And this way the new Fable.Browser package will use the new APIs directly without having to support multiple version of Fable (making the maintenance easier)

[robitar]

Any info on the rework ooc? I'm putting a bit of time aside this year to do some work on Fable, mostly around the bindings for the web platform.

I want to have 100% coverage based on the source WebIDL rather than the current setup of handwritten ones, or Typescript conversions. The idea is to make it low level and accurate, not ergonomic, no no DUs etc. I should be able to look at the MDN documentation, and be able to use the same API in F#, even if its a bit clunky, it exists.

Part of that is also covering over the ES/JS 'standard library' and making sure all those features are available. A lot of this is covered in Fable.Core, but its not always clear what's supported, or what form its in etc, or where it lives. In particular, I can never figure out if something is in Fable.Core, Fable.Core.JS or Fable.Core.JSInterop, and usually bring them all in until one of them lights up.

Because of the real issue of backwards compat, I was thinking of suggesting something like the --nomscorlib flag for csc.exe, back in the day. The idea is that it doesn't link in mscorlib, so you can provide you own version. This was useful for things like Silverlight and Script#. I'm guessing its not that simple here because presumably Fable will have a lot of hardcoded expectations about helpers being available and all that, but something along those lines might open things up for change.

[MangelMaxime]

Any info on the rework ooc? I'm putting a bit of time aside this year to do some work on Fable, mostly around the bindings for the web platform.

There is old issue on Fable, but it doesn't explains the gobal pictures and is missing examples of how it will look like / be used.

My plan is to create a PR starting this work during this month, so you can keep an eye on Fable repository for that.

Part of that is also covering over the ES/JS 'standard library' and making sure all those features are available. A lot of this is covered in Fable.Core, but its not always clear what's supported, or what form its in etc, or where it lives. In particular, I can never figure out if something is in Fable.Core, Fable.Core.JS or Fable.Core.JSInterop, and usually bring them all in until one of them lights up.

This is part of what the re-work will address, as this will create the foundation for all the languages supported by Fable and their interop APIs.

Because of the real issue of backwards compat, I was thinking of suggesting something like the --nomscorlib flag for csc.exe, back in the day. The idea is that it doesn't link in mscorlib, so you can provide you own version. This was useful for things like Silverlight and Script#. I'm guessing its not that simple here because presumably Fable will have a lot of hardcoded expectations about helpers being available and all that, but something along those lines might open things up for change.

Fable don't modify the compiler so I don't know if this is possible.

The way we are thinking of doing it is marking the old API as obsolete, and in a next major version remove everything. It should work ok because the news APIs are going to be under their own module and so people will not need to open the default Fable.Core making the obsolete APIs not available and so not polluting the global namespace. We need this transition phase as we don't want to break all the libraries in Fable 😅 and give time to people to migrate.

[robitar]

Fantastic, I'll keep an eye on things over there.

Do you have any idea of what shape the APIs will have? As I said up above, discoverability and predictability are not fantastic with the current setup. Even when I do know something exists, I can never figure out where it is and how to bring it in.

Re deprecated, yes thats much more straightforward! I assumed there wouldn't be an appetite for this even with major version jumps, because of all the churn it will cause.

[robitar]

Just looking at the linked comment, it looks like I laid out all the concerns there a few years back 😄

Mostly around the Core.JS and Core.JsInterop thing. It's a bit unintuitive and unconventional for .NET namespaces (which are hierarchical). I think this is why it never sticks in your memory.

It really should be Core.Js and Core.Js.Interop which is a lot more consistent.

Has there been any discussion around why it needs to be nested under Core at all? Is this to make sure things don't clash with bindings to other libraries which conventionally start with Fable? In an ideal world, you would have something as simple as open Fable.Js and open Fable.Js.Interop

[MangelMaxime]

The modules and namespaces will probably be Fable.Core.JavaScript, Fable.Core.JavaScript.Interop, Fable.Core.Python, Fable.Core.Python.Interop, etc. The full name is on purpose, to avoid conflict between potential languages and also to make the naming consisting between the different target from Fable.

I am not sure yet if .Core will be kept or not. It could be kept for historically reason, but removing it could also help into marking anything under .Core as deprecated from the module level directly.

Experimentation and proposition will be made, changing these modules/namespaces is not as simple as for any .NET libraries because we also need to update Fable internal mapping.

[robitar]

Yes that makes a lot of sense, and agreed with the full language name. Ironically, making things verbose and spelling them out tends to make it easier to remember imo.

I suppose there will also need to be some experimentation about what actually goes into these namespaces. What are the things that JavaScript brings in that isn't in the Fable namespace. Why would I think to open it, and so on.

Anyway, I'll keep an eye out for the proposals and perhaps we can continue the discussion there. Also happy to offer any help. I have a few bugs to post and I thought it might be a good opportunity to get involved by trying to fix some of them!