Closed davidyuk closed 1 year ago
There is the same issue with decoding, I see only typeless decoding exported https://github.com/aeternity/aepp-calldata-js/blob/82b5a98f9b308482627da8d7484d213e9cf87151/src/api/ContractByteArrayEncoder.js#L27
by the way, shouldn't decodeWithType
accept arguments in the same order as encode
? 🙃
https://github.com/aeternity/aepp-calldata-js/blob/82b5a98f9b308482627da8d7484d213e9cf87151/src/ContractByteArrayEncoder.js#L80
Any proposal for the API? I prefer to stick to the ACI interface/protocol as much as possible.
I prefer to stick to the ACI interface/protocol as much as possible.
Sure, it should accept a subset of ACI defining a value to encode/decode.
Other than that a would prefer a functional approach 🙄
@davidyuk please take a look #223 if that suits your needs
This library follows basic OOP approach for it's public API.
For example
I want to get the corresponding fate-encoded bytecode ('cb_KxF0ZXN0VANAuWU=') for my implementation of EIP-712 🙄
Currently, I'm doing it this way