Add http & http_client wasm bindings #130
Conversation
KendallWeihe
requested review from
nitro-neal,
shamilovtim,
diehuxx and
frankhinek
as code owners
* main: Add Missing Test Vectors (#128)
| use wasm_bindgen::prelude::*; | ||
| use wasm_bindgen::JsValue; | ||
|
|
||
| fn convert_to_object_recursive(value: &JsValue) -> Result<JsValue, JsValue> { |
There was a problem hiding this comment.
This replaces the mapToObject() which was removed in the typescript code, I figure it's a bit more robust to move this in to the rust layer. But also, I suspect in the future we may revamp our bindings code with the intent of improving maintainability, in which case this may go away.
| @@ -0,0 +1,36 @@ | |||
| { | |||
There was a problem hiding this comment.
@nitro-neal check it, vectors/ here
I generated these values from our kt example app, and checked them in here. They're here right now for sanity, so we may choose to move these to official vectors in due time, or maybe find a different testing solution altogether. Just making you aware.
There was a problem hiding this comment.
yup awesome, will add a task in our running list to add these to official test vectors basically
There was a problem hiding this comment.
probably have a new folder for end2end flow or something, maybe doesn't belong in official test vector spot but good to have
| @@ -430,6 +420,30 @@ export namespace InputDescriptor { | |||
| }; | |||
| } | |||
|
|
|||
| export type JsonSerializedMessage = { | |||
There was a problem hiding this comment.
some of our http types are multi-type so we json serialize over the ffi
| if (kind === "order") message = Order.fromJSONString(json); | ||
| else if (kind === "cancel") message = Cancel.fromJSONString(json); |
There was a problem hiding this comment.
is this the right spot to do logic?
shouldn't all logic basically be in rust?
There was a problem hiding this comment.
yeah good question, the TL;DR is the wasm FFI needs concrete types, and the UpdateExchangeRequestBody has a message property that can either be an Order or a Cancel, so JSON serialize it over the FFI. so we have to embed logic on the ts side to deserialize it back into the concrete type, such that then the DX has a true WalletUpdateMessage type, so they can do conditionals like if (message instanceof Order) { ... } else if (message instanceof Cancel) { ... }. this is one of those things I'd like to spend time optimizing if we ever have the time.
No description provided.