Is it reasonable to extract prefix_encoded data handling and tx building to a common package?

[davidyuk]

I've noticed that Calldata exposes FateApiEncoder which does the same as encode/decode SDK functions. Calldata can't depend on SDK, and SDK needs a more accurate type and a simpler interface 😛.

Also, ContractEncoder:decode looks like a special case of unpackTx from SDK.

[dincho]

I don't think it needs a common separate package, I plan to rename this package/repo to more general "serializer" like name, so it can solve more general serialization problems. That said, feel free to use FateApiEncoder from this package, and let me know if it's missing some prefix.

Also, ContractEncoder:decode looks like a special case of unpackTx from SDK.

Could you please point me with a link to unpackTx you're referring to ?

[dincho]

As of the title, yeah perhaps this package can implement TX serialization/deserialization, but definitely not "builder"

[davidyuk]

Could you please point me with a link to unpackTx you're referring to?

https://github.com/aeternity/aepp-sdk-js/blob/2358a0c0cfd0389657b0fca800bf7cdbe4591cb4/test/unit/tx.ts#L109-L116
https://github.com/aeternity/aepp-sdk-js/blob/2360cd2d70242f233857ada740a19f8d6834a52a/src/tx/builder/index.ts#L94
It is a function that converts tx-encoded string to an object of tx properties.

but definitely not "builder"

The difference from a plain serialization:

• it has some reasonable defaults (like min gas price)
• calculates some fields if the value is not provided (like fee)
• in async mode, it can fetch user nonce or so