wasm `save_file`

[Easyoakland]

Solving https://github.com/PolyMeilex/rfd/issues/88.

Create new rfd::FileHandle::write(data: Box<[u8]>) which should be able to be implemented for all targets including Wasm.

Currently only implemented for Wasm target and everything is in one function. It should almost certainly be be moved out to WasmDialog

I won't bother finishing this if it's indicated that this is an unwanted way to solve the issue, so feedback is welcome.

The other solution indicated appears to be

There is also a chrome specific API that lets you open a file save dialog and get a file handle that way, this aligns with how paths work on native so we would just have to wrap those in a new type.

but that sounds like it won't work on Firefox.

[PolyMeilex]

So the way I see this being used would be:

On native:

• Call to save dialog would return FileHandle(Path) alike struct, just like pick dialog does now
• Users can either extract the raw path or call save method, that does the writing

On web:

• Call to save dialog would return fake/empty FileHandle alike struct, the dialog would not be opened
• When calling save on the handle the dialog would pops up and users could download the file that way.

On IOS/Andoird:

• I have to take a look at those APIs, to check if in the future that would do the trick there as well.

Does this sound like a reasonable usage of this POC?

[Easyoakland]

Call to save dialog would return FileHandle(Path) alike struct, just like pick dialog does now

I think that is already how it works as well in save_file. Did you mean save_file when you wrote save_dialog?

Users can either extract the raw path or call save method, that does the writing

Yes, though I named it write to match the read method.

Call to save dialog would return fake/empty FileHandle alike struct, the dialog would not be opened

Yes. AsyncFileDialog::save_file

When calling save on the handle the dialog would pops up and users could download the file that way.

Yes.

I have to take a look at those APIs, to check if in the future that would do the trick there as well.

Sure.

Does this sound like a reasonable usage of this POC?

Yes.

[PolyMeilex]

I think that is already how it works as well in save_file

Yep, I forgot that I already did that

In that case this sounds awesome to me, I don't have any concerns.

[Easyoakland]

@PolyMeilex FileHandle is now an enum over either web_sys::File (for reading) or FileDialog (for writing). Attempting to call write or read on a FileHandle that was created incorrectly will panic. Its unfortunate that it can't be prevented at compile time, but I don't currently see a way to add a compile time check to FileHandle while also being the same on native where both read & write can happen from a FileHandle. Another option could be to use the state pattern to make all FileHandle either FileHandle<Read> or FileHandle<Write> or FileHandle<RW> and implement write, read, and other methods on particular FileHandle states but I don't know if that's a good change to make. If this implementation is good I'll look next at implementing on Windows as I don't have a Linux machine to test with.

[Easyoakland]

Done for native (0345e44)

[PolyMeilex]

Thanks!

[ZeWaka]

Thank you so much for this, actually made my day not having to implement this myself 😅