-3

I have a smart contract written in Rust. In it there's a function which accepts an Option<u128> as one of it argumments.

How can I pass that argument from a client-side? Namely, from a JS, Python or any other language. Or even via Curl. For there's no description anywhere.

duman
  • 11
  • 2
  • You could create a wrapper function around it that takes a `u128` and passes it to the function with `Some`? Maybe in JavaScript since that number's way too large you can also take a string and parse that into a `u128`. – kelsny Oct 30 '22 at 19:18
  • @caTS what "wrapper"? It has nothing to do with JS because JS is only an example. How and why on Earth that wrapper would translate to Rust code properly? – duman Oct 31 '22 at 00:49
  • The wrapper is in Rust - it would probably be something like `fn wrapped_fn(value: u128) { real_fn(Some(value)) }`. – kelsny Oct 31 '22 at 01:47
  • I am not sure what question you're asking. `curl` is a command line program for issuing HTTP requests. Do you have a HTTP interface to the program? How does it look like? What kind of data is transferred? JSON, XML? – Richard Neumann Oct 31 '22 at 18:07

1 Answers1

1

The representation of Option<T> in JSON/JS is T | null.

Assuming you're using the near-sdk which serializes the parameter as an object or sequence, in this Option<u128> case if the only parameter has a name of value. Examples of the representation will look like this:

{"value":80}

or

{"value":null}

or

[9]

or

[null]

However you'd like that to be represented in each language.

Keep in mind, though, that most languages might not support deserializing 128-bit integers into native numbers, and you'll get an overflow. For example, JS max integer is 2^53-1, and python will have a 2^64-1 max for 64-bit runtimes and a 2^32-1 max for 32-bit runtimes. This means that for these, you will have an overflow at this larger range.

The common workaround for using large integers like this is to use some big integer implementation in each. Commonly the default serialization for these is a string rather than an integer, which is common in the ecosystem and in NEAR tooling. Just check what format each side uses and use whatever fits your use case.

I'd recommend using big integers on the client side and serializing as a string and could use a wrapper type like U128 from near-sdk, but there is no restriction at a JSON level to serialize and deserialize these big integers as a number if you'd prefer to do that.

Edit: This was assuming that the parameters are serialized as JSON. If you decided to use a different serialization protocol, let me know in the comments, and I can explain what the representation looks like for Option types.

Austin
  • 106
  • 3