When you say “converts between Motoko tuples and Blob”, would this not then apply to the record type?
The ability to Blob encode an record/object is especially important because initializing an actor canister class with a record better supports backwards compatibility when upgrading, as opposed to than a list of arguments.
Not having this feature in Motoko is borderline blocking, as it limit Motoko devs in the following ways:
- If we want to use values that already exist on the canister memory that would be rolling out the dynamic upgrades it makes sense that this would happen on the backend. Not being able to Blob encode a record forces Motoko developers who want to perform upgrades on the backend to simplify their instatiation arguments for an actor canister
Or
- It forces us to use @dfinity/candid to encode the arguments from the frontend using Javascript or tooling like
didcfor pushing out upgrades where the canister requires multiple instantiation arguments. This becomes awkward when an upgrade involves pulling down data to the client from one canister in order to retrieve the arguments necessary to rollout upgrades with the proper arguments to other canisters. It also means additional repeated development time where all Motoko development teams are building out custom tooling farther away from the canister rolling out the upgrades, and all of this could be solved with improved Motoko encoding capability.
I was looking at candid/tools/didc at master · dfinity/candid · GitHub, and would love a Motoko equivalent of
didc encode ...
There might need to be a type definition in there <T>, but how hard would it be to add something with this functionality to the Blob class in motoko-base?
The debug_show is amazing at converting types to Text, how difficult would it be to convert a well typed record to a Blob from the Motoko side?
Is there a prim functionality that I could leverage?