AEX 6 - Strategic Semantic Syntax: Contract Interaction Wrapper

Hey people, I want building on aeternity to be so simple, one could learn it in less than 2 hours.

tl;dr : If you think the following is something that everyone could understand…

const ae = require("aepp-sdk");

// connect to a node
const myMainnetNode = ae.nodeProvider(“http://publicNode.aeternity.com/”, “ae_mainnet”, “cors-params”) 

// create contract reference
TokenContract = ae.fromArtifact(require(./MyToken.json)); // automatically taking latest deployment address for current net

// define which node to use
TokenContract.options.setNodeProvider(myMainnetNode);

//do a transaction
var oneTransaction = await TokenContract.methods.transfer("ak_xyz", 1337, {...tx params...})

//read data from latest contract state
var myTokenBalance = await TokenContract.methods.checkBalance("ak_xyz")

…and you want to find out what other advantages it brings for developers (no breaking changes, always latest features without code change & many more), you are welcome to express support for my AEX 6 ! :cowboy_hat_face: (Reading time: 10 minutes)

AEXs/aex_SSS.md at 956e06ef25c3088f0ff8c1012fcd510c56c0e5da · aeternity/AEXs · GitHub (link will change after pull to repo, will update)

4 Likes

Hey @nikitafuchs.chain, I think that is great thing and could make everyone’s work a lot, a lot easier than the current state, because the current state (sorry but this is the harsh truth) is a shitty one.

I suggest you to take a look at the best Ethereum library. It takes literally (I have personally tested it on several people with no blockchain background) half an hour to learn how to use it. I’m taking about: ethers.js - Legacy Documentation

Hello @nikitafuchs.chain,

what is the rationale not to support the high-level syntax as proposed by the js-sdk?

// different stamps can allow for different functionality to be imported
// e.g. there could be a sdk implementation that supports more complicated features if integrated with the middleware
const Ae = require('@aeternity/aepp-sdk').Universal;

// constructor syntax as a client is constructed seems more logical than a function call to get a node instance
const client = await Ae({ // a simpler choosing between networks could be implemented or some of the variables can default to mainnet 
    url: config.host,
    internalUrl: config.internalHost,
    keypair: ownerKeyPair,
    networkId: 'ae_mainnet',
    compilerUrl: config.compilerUrl
});

// get an stateful instance of the contract, from its source (or interface) not using additional aci definition file
// can also be initialized with already deployed contract
const contract = await client.getContractInstance(require(./Contract.aes))

// deploy the contract via instance, which updates the instance with the deployed address
await contract.deploy()

// call the deployed contract via instance, where args can be a js object {} representation of the sophia records
// return value will be a sophia record as js object
// could be further optimized to use ACI to generate prototype functions to not pass strings
await contract.call('transfer', args);

Why is there the need in your example to define node provider twice? ae.nodeProvider and TokenContract.options.setNodeProvider but the TokenContract was initialized using the defined ae.

Why is calling contract functions abstracted inside .methods.?

Why are options (if even needed) not set during initialization, but using TokenContract.options.?

I think abstracting over the blockchain functions e.g. “call” and “deploy” in prototype function syntax is bad of transparency of what happens when using these functions.

I feel this follows the ethereum implementations to closely without considering the progress already made in aeternity sdk implementations. Also I think this promotes a JS codestyle that is not in line with modern proposals, mixing stateful instances and mutation of attributes using function calls.

As already discussed with you @nikitafuchs.chain, it would still be helpful to know some arguments behind the statement that the proposed format will incur less breaking changes in the future, than the syntax as it is currently.

Just follow Uncle Bob’s principles and you will be fine :stuck_out_tongue_winking_eye: