[bug] `HashMap` always empty when passed to `#[tauri::command]`

[bicarlsen]

Describe the bug

When passing a HashMap to a #[tauri::command] the contents is always empty. This seems to be the case regardless of the types associated with the HashMap. I have verified that the HashMap is correctly Serialized. I am using Yew as a front end.

Reproduction

MRE is located at https://github.com/bicarlsen/tauri-command-hashmap-mre.

Expected behavior

HashMap should arrive as was sent.

Platform and versions

Environment
› OS: Pop!_OS 22.04 X64
› Node.js: 19.4.0
› npm: 9.2.0
› pnpm: Not installed!
› yarn: Not installed!
› rustup: 1.25.1
› rustc: 1.66.0
› cargo: 1.66.0
› Rust toolchain: stable-x86_64-unknown-linux-gnu

Packages
WARNING: no lock files found, defaulting to npm
› @tauri-apps/cli [NPM]: 1.2.2
› @tauri-apps/api [NPM]: Not installed!
› tauri [RUST]: 1.2.3,
› tauri-build [RUST]: 1.2.1,
› tao [RUST]: 0.15.8,
› wry [RUST]: 0.23.4,

App
› build-type: bundle
› CSP: unset
› distDir: ../dist
› devPath: http://localhost:1420/
package.json not found

App directory structure
├─ .vscode
├─ src-tauri
├─ .git
├─ target
├─ dist
├─ public
└─ src

Stack trace

No response

Additional context

No response

[amrbashir]

The problem is that serde_wasm_bindgen::to_value will convert the rust HashMap into a js Map object, then tauri's invoke will call JSON.stringify on it which will result in an empty object {}. I am not sure what is the best approach here tbh. I don't think we can do anything about it since the Map could be nested deep down in the object passed to invoke.

[bicarlsen]

I am currently solving it by manually stingify-ing the HashMap sending it across as a String, then manually un-stringify-ing it. At least in my simple use case it works.

[amrbashir]

alright, I think I found an acceptable solution using JSON.stringify second argument (replacer function) to convert the map > object

[bicarlsen]

It doesn't seem this fix has been included in Tauri yet. Is it expected to be included in a future release?

[FabianLars]

this was part of tauri 1.3 - which version are you using? And is the MRE above after updating the versions to let's say 1.5 still accurate?

[bicarlsen]

Sorry, the issue was actually coming from an Option enum as described in Issue #5993.