The maybe_async macro makes the function signature of each method different depending on whether the dependency is compiled for wasm32 or not. This isn't ideal for libraries that might be used in isomoprhic app frameworks like iced, which can compile to either web or desktop-native targets.
I'm not sure what the best approach would be to fix this since Rust's async story is so complex right now. If at some point we enter the shiny future, we can just remove usage of the bdk-macros crate altogether.
For now, I think it's possible to bypass this issue by also using the bdk-macros crate, but this is imperfect because it essentially perpetuates the problem, and "infects" all upstream dependents.
The
maybe_asyncmacro makes the function signature of each method different depending on whether the dependency is compiled for wasm32 or not. This isn't ideal for libraries that might be used in isomoprhic app frameworks like iced, which can compile to either web or desktop-native targets.I'm not sure what the best approach would be to fix this since Rust's async story is so complex right now. If at some point we enter the shiny future, we can just remove usage of the bdk-macros crate altogether.
For now, I think it's possible to bypass this issue by also using the
bdk-macroscrate, but this is imperfect because it essentially perpetuates the problem, and "infects" all upstream dependents.