-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Babbage utilities #81
Conversation
|
||
utxos: Vec<InputBuilderResult>, | ||
collateral_return: Option<TransactionOutput>, | ||
total_collateral: Option<Coin>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: currently no good way to set this. Will have to be done in a follow-up PR
@@ -3698,6 +3698,63 @@ impl Deserialize for NetworkId { | |||
} | |||
} | |||
|
|||
impl cbor_event::se::Serialize for Datum { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rooooooooob I'm not sure what was up with this TxOutputData
type. The datum_option
type is part of the binary spec so I just replaced it with this and manually added the (de)serialization for it
During #81 `utils.rs` was refactored into many places and some wouldn't be using `error::JsError` which in wasm builds is a typedef for `js_sys::JsValue` and is its own struct for rust builds (to avoid panics in JsValue when used from non-wasm builds). Howeve, some places couldn't see these types and would pull it in directly from `wasm_bindgen::prelude` from the wildcare import in `lib.rs`. This caused an issue when bumping `wasm_bindgen` as the `from_str()` method is no longer in `js_sys::JsError` but still is in `JsValue`. Between now and #81 this would have also led to panics if many places when an error was returned when using CML from rust instead of wasm. In the future we should deprecate the direct usage of `js_sys::JsValue` and remove our `JsError` type on rust in favor for real rust errors (not just string wrappers). See rustwasm/wasm-bindgen#2710 >Expands the acceptable return-position types to Result<T, E> where T: IntoWasmAbi, E: Into<JsValue>, so you can easily throw your own custom error classes imported from JS which will greatly improve error handling from the rust side but this should be done after the rust/wasm split.
During #81 `utils.rs` was refactored into many places and some wouldn't be using `error::JsError` which in wasm builds is a typedef for `js_sys::JsValue` and is its own struct for rust builds (to avoid panics in JsValue when used from non-wasm builds). Howeve, some places couldn't see these types and would pull it in directly from `wasm_bindgen::prelude` from the wildcare import in `lib.rs`. This caused an issue when bumping `wasm_bindgen` as the `from_str()` method is no longer in `js_sys::JsError` but still is in `JsValue`. Between now and #81 this would have also led to panics if many places when an error was returned when using CML from rust instead of wasm. In the future we should deprecate the direct usage of `js_sys::JsValue` and remove our `JsError` type on rust in favor for real rust errors (not just string wrappers). See rustwasm/wasm-bindgen#2710 >Expands the acceptable return-position types to Result<T, E> where T: IntoWasmAbi, E: Into<JsValue>, so you can easily throw your own custom error classes imported from JS which will greatly improve error handling from the rust side but this should be done after the rust/wasm split.
This PR adds in a bunch of Babbage utility functions