#Is there a good way to derive the type from the XDR via the soroban client?

1 messages · Page 1 of 1 (latest)

neon flicker
#

xdr.ScVal.fromXDR(Buffer.from(xdr_string, 'base64'))
Is there or will there be a good way to derive the type from the XDR when pulling in the value from the object we're getting in the object parameters from Horizon? I can't see anything in the resulting object besides the length of bytes. e.g. contract ids are 32 bytes and contract data or other arguments might be a different length.

#

What's Paul's Discord handle? This seems like a him question

drowsy kestrel
#

@naive solar

naive solar
#

You mean like how to figure out the type of an scval?

#

I normally chuck it into the futurenet laboratory. but in code you’d need to check the xdr discriminator (foo.armType if I remember right)

neon flicker
#

Hmm yeah I saw that but couldn't see anything in that object that was different between a contract id value and a contract code value. I just saw a list of different types not an actual assignment of which type the value was

neon flicker
#

I guess the core of the question is hinting at how to decode the values. Is this a contract id value? A wasm buffer? A byte string? Etc

#

I see a map of _switches and _arms but it's not clear to me what's what

opaque knoll
dire thunder
#

Ah so I think the thing you're getting at @neon flicker is that a Bytes for a contract id and bytes for contract code are just the same type "Bytes", is that the concern?

neon flicker
#

Yeah I think so? Just types in general. How is a UI or an app supposed to know how to interpret values that are generic byte arrays? Do we not expose type information anywhere beyond the most primitive types? Things like this is wasm contract code vs this is a contract id, vs this is an account id. Is the idea you'd read in contract metadata from like the footprint or the ABI for this?

urban nymph
#

can they be derived based on length?

dire thunder
#

An account id is a type, ScVal::Object(AccountId).