trunk-rs
Using WASI + Asyncify?
I've been working on building a webapp with egui and eframe, and the stock template comes with trunk. I've actually grown quite fond of trunk and would like to keep using it.
I have been going through a lot of headache for the past two days trying to deal with async functions from javascript in a completely synchronous codebase, all of which involve interacting with the filesystem. WASI provides functions for accessing the filesystem, which is quite amazing, and would save me a lot of time and headache if I could use it.
How can I use WASI? I've seen some discussion around a 'plugin system' but that idea seems to have gone nowhere.
UPDATE: I did some digging around and found out about Asyncify, which would quite useful here.
So, are you looking for FileSystem browser API access? If so, I would recommend sticking with web-sys: https://docs.rs/web-sys/latest/web_sys/struct.FileSystem.html
If you need to perform more structured FS manipulation, I would recommend building a server-side API to handle that. It really depends on what you are trying to do though.
Either way, from the browser, you are limited to the browser APIs.
If you need to perform more structured FS manipulation, I would recommend building a server-side API to handle that. It really depends on what you are trying to do though.
I'm trying to make a game engine editor that runs in the browser, that involves manipulating the local user filesystem.
So, are you looking for FileSystem browser API access? If so, I would recommend sticking with web-sys: https://docs.rs/web-sys/latest/web_sys/struct.FileSystem.html
I did look at this, but there's no synchronous way to pull up a directory picker from what I understand in webassembly without using Asyncify. web-sys has no bindings for window.showDirectoryPicker().
@Speak2Erase we have support for a few wasm-opt related args described in the docs here: https://trunkrs.dev/assets/#rust
We've discussed making this much more generic, so that we don't have to stay in step with other tools and the CLI options they support, but at this point in time, that is it.
PRs always welcome to support a more generic approach, or to support a new specific wasm-opt flag.