First Template
Introduction
CashConnect templates are JSON schemas that have a form like the following:
{
name: 'Example Template',
description: 'This is an example template',
actions: {
// ... methods that can be invoked.
},
scripts: {
// ... global scripts that are re-used by Actions.
// E.g. Lock/Unlock scripts.
}
}Items listed under actions can be thoguht of as the Public API of the template and, conceptually, are treated like functions in any other language: They have:
params- data that is passed ininstructions- pipeline of instructions to perform (analogous to function bodies)returns- data that is returned once executed
Defining an Action
Let's create a simple action that just sends sats to the provided address ("Locking Bytecode").
INFO
We will be using some tooling from the @cashconnect-js/templates-dev package to improve legibility, but this is not required: Templates can be written in pure JSON for those who might prefer it.
INFO
Click "Run Code" above to see the JSON-serialized template.
Testing the Action
Having to test each change to the template by establishing a new Wallet Session would be very painful. CashConnect ships with some tools to ease this and allow automated tests to be created.
If using CashScript (see next chapter), this tooling will also output debugging information (which CashScript line failed, etc).
Let's try executing the above action in a test environment.
Trying the Action in a Wallet
Now that we've tested our action, let's try executing it in our wallet.
First, we have to add some meta information to our action. This is what will display to the user.
{
meta: {
title: 'Send',
description: 'Send {{ <recipientSatsAmount> | satoshis }} to {{ <recipientLockingBytecode> | address }}',
},
// ...
}DANGER
This is currently being refactored to support control flows (e.g. looping over a list of recipients). The above is for demonstration only.
Let's then use the CashConnectDappConsole UI to establish a session with our wallet and execute the action.
What's happening under the hood?
Template Instances are stand-alone. Although some Transports may have additional methods (e.g. cancelRequest for WalletConnect) and may also inject specific context-level variables (e.g. __domain), for the most part, they just serve as proxies for executeAction on the templates.
A quick sequence diagram is given below to illustrate a typical flow.
Next chapter we'll look at how to use CashScript Contracts with CashConnect.