You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The use case I have is pretty-printing wasm_bindgen::JsValues. Right now I always make a string by walking the object tree and passing that to tracing. If tokio-rs/tracing#905 were to happen, I think this crate could define an interface to pass nested values directly through to the backend without needing to teach the Value trait about all of the details of the APIs.
I'm not sure exactly what that would look like but I thought I'd gauge interest.
The text was updated successfully, but these errors were encountered:
Thanks for sharing the idea. It sounds like it's not too fun of a problem to solve.
I can say that we have not needed this functionality, yet since our usage from the web side is as complex as JSON-RPC from web to wasm & back. So, in our use-case, we don't really touch JsValues.
Perhaps this is what you were describing, here, but a common answer to problems like this is to try using a wrapper type like struct JsValueTracing(wasm_bindgen::JsValue); and impl tracing::Value for JsValueTracing.
Then, if it's common enough of a need, I'd end up putting a fn jt(js_value: wasm_bindgen::JsValue) -> JsValueTracing into my project prelude to be accessed everywhere easily.
The use case I have is pretty-printing
wasm_bindgen::JsValue
s. Right now I always make a string by walking the object tree and passing that to tracing. If tokio-rs/tracing#905 were to happen, I think this crate could define an interface to pass nested values directly through to the backend without needing to teach theValue
trait about all of the details of the APIs.I'm not sure exactly what that would look like but I thought I'd gauge interest.
The text was updated successfully, but these errors were encountered: