Skip to content
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

Merged
merged 31 commits into from
Dec 17, 2023
Merged

wasm_bindgen support for fuel-tx #645

merged 31 commits into from
Dec 17, 2023

Conversation

Dentosal
Copy link
Member

@Dentosal Dentosal commented Dec 4, 2023

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.

@Dentosal Dentosal self-assigned this Dec 4, 2023
@Dentosal
Copy link
Member Author

Dentosal commented Dec 5, 2023

Size of fuel-tx wasm blob is just under 200 KiB at 74a4d2b.

@Dentosal
Copy link
Member Author

Dentosal commented Dec 6, 2023

And after further size reduction, at 9d89fbc it's 187 KiB. If the allocator is also replaced with wee_alloc, then the size is only 181 KiB. We could remove 44 KiB of that is just the signature validation in check_input, so if that's not needed we could go even lower.

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

@Dentosal Dentosal added the fuel-tx Related to the `fuel-tx` crate. label Dec 6, 2023
@Dentosal Dentosal requested a review from a team December 6, 2023 03:32
@Dentosal Dentosal marked this pull request as ready for review December 6, 2023 03:32
@Dentosal Dentosal marked this pull request as draft December 6, 2023 20:44
@Dentosal Dentosal marked this pull request as ready for review December 6, 2023 22:13
Copy link
Collaborator

@xgreenx xgreenx left a 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 {
Copy link
Collaborator

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)

Copy link
Member Author

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)]
Copy link
Collaborator

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?

Copy link
Member Author

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.

fuel-tx/Cargo.toml Outdated Show resolved Hide resolved
hashbrown = { version = "0.14", optional = true }
itertools = { version = "0.10", default-features = false, optional = true }
js-sys = { version = "0.3", optional = true }
Copy link
Collaborator

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?

Copy link
Member Author

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:

#[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)
}

Copy link
Collaborator

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?

Copy link
Member Author

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.

fuel-tx/Cargo.toml Outdated Show resolved Hide resolved
@Dentosal
Copy link
Member Author

It would be nice to use snapshots in JS unit tests to see that deserialisation/serialisation works=)

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.

@xgreenx
Copy link
Collaborator

xgreenx commented Dec 13, 2023

It would be nice to use snapshots in JS unit tests to see that deserialisation/serialisation works=)

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.

@Dentosal
Copy link
Member Author

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.

Comment on lines +35 to +40
#[cfg(feature = "typescript")]
use self::{
input::typescript as input_ts,
output::typescript as output_ts,
};

Copy link
Collaborator

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

@Dentosal Dentosal added this pull request to the merge queue Dec 17, 2023
Merged via the queue into master with commit ba08344 Dec 17, 2023
37 checks passed
@Dentosal Dentosal deleted the dento/wasm-bindgen-more branch December 17, 2023 23:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fuel-tx Related to the `fuel-tx` crate.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add wasm_bindgen support for fuel-tx
2 participants