You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At compilation, most onchain languages like Aiken generate a plutus.json file, containing a specification of the Plutus contract interface. This file called a blueprint, is specified by CIP-57, and contains information such as:
the list of existing validators
the compiled code and hash of each validator
the names and types of the redeemer and the datum for each contract
Looking at that blueprint enables anyone to interact with these contracts relatively easily. But what would make it extra nice, would be a way to auto-generate an Elm module defining types and encoding/decoding for all of this.
One issue commonly faced when crafting the redeemer and the datum in the offchain code is to not encode them to the correct Data shape. Such a failure will crash the contract execution immediatly. If instead, the encoders/decoders and typed representations of these are auto-generated in an Elm module, any mistake on the user side will be catched directly at compile time, making it much more dev-friendly.
There is a great tool to auto-generate Elm code, called Elm CodeGen, initiated by Matthew Griffith. I’d highly suggest anyone taking this one, to use elm-codegen for that task.
The text was updated successfully, but these errors were encountered:
At compilation, most onchain languages like Aiken generate a
plutus.json
file, containing a specification of the Plutus contract interface. This file called a blueprint, is specified by CIP-57, and contains information such as:It looks like this:
Looking at that blueprint enables anyone to interact with these contracts relatively easily. But what would make it extra nice, would be a way to auto-generate an Elm module defining types and encoding/decoding for all of this.
One issue commonly faced when crafting the redeemer and the datum in the offchain code is to not encode them to the correct
Data
shape. Such a failure will crash the contract execution immediatly. If instead, the encoders/decoders and typed representations of these are auto-generated in an Elm module, any mistake on the user side will be catched directly at compile time, making it much more dev-friendly.There is a great tool to auto-generate Elm code, called Elm CodeGen, initiated by Matthew Griffith. I’d highly suggest anyone taking this one, to use elm-codegen for that task.
The text was updated successfully, but these errors were encountered: