-
Notifications
You must be signed in to change notification settings - Fork 87
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
wasm_bindgen support for fuel-tx #645
Conversation
Size of fuel-tx wasm blob is just under 200 KiB at 74a4d2b. |
And after further size reduction, at 9d89fbc it's 187 KiB. If the allocator is also replaced with The command used to determine the size is: cargo rustc -p fuel-tx --target wasm32-unknown-unknown --no-default-features --features typescript --crate-type=cdylib --profile web-release && wasm-bindgen --typescript --target web ./target/wasm32-unknown-unknown/web-release/fuel_tx.wasm --out-dir tmp/src && wasm-opt tmp/src/fuel_tx_bg.wasm -o tmp/src/fuel_tx_bg.wasm -Oz && wc -c tmp/src/fuel_tx_bg.wasm |
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.
It would be nice to use snapshots in JS unit tests to see that deserialisation/serialisation works=)
impl Output { | ||
#[cfg(feature = "serde")] | ||
#[wasm_bindgen(js_name = toJSON)] | ||
pub fn to_json(&self) -> String { |
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.
Do we want to add fromJSON
method? (the same for Input)
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.
Possibly, but I'd leave that as a follow up that can be done if anyone requests it. This is mostly for debugging anyways, and I don't expect the production version to enable serde
feature anyway.
@@ -53,6 +53,7 @@ pub(crate) struct ScriptMetadata { | |||
|
|||
#[derive(Clone, Derivative)] | |||
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] | |||
#[cfg_attr(feature = "typescript", wasm_bindgen::prelude::wasm_bindgen)] |
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.
How does it work if Input
and Output
are enums?
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.
The fields are private and not directly accessible from outside, so there's no interface to generate.
hashbrown = { version = "0.14", optional = true } | ||
itertools = { version = "0.10", default-features = false, optional = true } | ||
js-sys = { version = "0.3", optional = true } |
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.
The same here, why do we need it?
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.
js-sys
is used to return proper js error types, for instance here:
fuel-vm/fuel-tx/src/tx_pointer.rs
Lines 117 to 121 in 8124114
#[wasm_bindgen(constructor)] | |
pub fn typescript_new(value: &str) -> Result<TxPointer, js_sys::Error> { | |
use core::str::FromStr; | |
TxPointer::from_str(value).map_err(js_sys::Error::new) | |
} |
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.
Why do we return JsValue
in one cases and js_sys::Error
in another?
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.
I had missed those since I searched for JsValue>
to find use in Result
types, but I had left inline comments so that it looked like this Result<..., JsValue /* Comment */>
instead.
Fixed in 10ac139.
It don't think adding snapshot tests for the frontend side is necessary, since we already do that on the native side, and this uses the exact same serialization code. Maybe we should rather compare that the wasm and native versions produce the same output for an input? Such a test is quite annoying to write, but I can do that if it seems useful to you. |
I definitely don't want us to create the same tx on JS side and compare serialized bytes=) I meant to deserialize tx on the JS side using serialized bytes from snapshot files. But if it is hard to extract serialized bytes, then we can skip it. This move proves that deserialization and serialization are the same on both sides. |
Wasn't too hard. Added the snapshot comparison cases in ff9329b. |
#[cfg(feature = "typescript")] | ||
use self::{ | ||
input::typescript as input_ts, | ||
output::typescript as output_ts, | ||
}; | ||
|
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.
It seems we can move it into typescript
module
Closes #579
I'm not sure if we need to add serialization and deserialization support to more types, but this should at least provide a good starting point.
Also, this is still missing some datastructure manipulation, for instance you cannot modify
Policies
easily.