Open infu opened 2 weeks ago
Hey @Infu,
Thanks for reporting the issue. I'll take a look and update the example.
For the type issue, I can add fromICRC3Value()
and toICRC3Value()
methods to convert the resulting Candid type to an ICRC3 type. It would be an additional call on the decoded data. Is this okay?
Also, is it possible to not have to write down a list of fields, so it does them automatically?
No, it's not currently possible to convert without the list of fields.
The reason is the candid specification requires record fields to be hashed when encoding.
So internally when we use to_candid()
to get the serialized version of the given motoko type we only receive the hashed fields.
The list of fields the user adds to the decoding request allows us to match them with their hashed versions and name them properly when decoding.
Will it convert the whole nested structure recursively? Or it can only convert flat records
Yes, it will convert any number of nested records or arrays.
Thanks, it's okay to have another method
Hey @infu,
I've published the changes in version 3.2.1
on mops.
Try it out and let me know if there are any issues.
The ICRC3 example from https://raw.githubusercontent.com/NatLabs/serde/main/usage.md#icrc3-value doesn't work
There is one here https://github.com/NatLabs/serde/blob/main/tests/Candid.ICRC3.Test.mo that does work, but it's not converting the object to a ICRC3 Generic Value type, it's still Candid type. I am assuming it's only using the ICRC3 fields, but the type is incompatible when we try to use it. We need it to be with this type, without all the extra Candid variations
Also, is it possible to not have to write down a list of fields, so it does them automatically?
Will it convert the whole nested structure recursively? Or it can only convert flat records ?
The code we are trying to write is