feat: guide user to call a contract

[AlexD10S]

PR that parses the contract metadata and guides the user in interacting with the smart contract

┌   Pop CLI : Call a contract
│
◇  Where is your project located?
│  ./
│
◇  Paste the on-chain contract address:
│  15XausWjFLBBFLDXUSBRfSfZk25warm4wZRV4ZxhZbfvjrJm
│
◇  Select the message to call:
│  get 
│
◇  Where is your contract deployed?
│  wss://rpc1.paseo.popnetwork.xyz
│
◇  Signer calling the contract:
│  //Alice
│
◓  Calling the contract...                                                                                                                                            ⚙  Result: Ok(false)
│  
▲  Your call has not been executed.
│  
◆  Do you want to do another call?
│  ○ Yes  / ● No 
└  

Apologies for the large PR; it grew bigger as we needed to test user interactions in the pop-cli crate.
This required adding more code for testing purposes, including changes to the CLI module and the introduction of a new init_tests file which contains reusable methods for various tests.

Ideally, these changes should have been introduced in #315, but they were included here due to the necessity of testing the current implementation.

Another note, for testing purposes it has introduced a testing.json file. This file is the metadata of a modified flipper contract, which includes an extra message, to effectively test argument parsing and payable functions.

/// A message for testing, flips the value of the stored `bool` with `new_value`
/// and is payable
#[ink(message)]
#[ink(payable)]
pub fn specific_flip(&mut self, new_value: bool) {
    self.value = new_value;
}

[codecov]

Codecov Report

Attention: Patch coverage is 78.29978% with 291 lines in your changes missing coverage. Please review.

Project coverage is 72.01%. Comparing base (258a4b2) to head (a6f8247).

Files with missing lines	Patch %	Lines
crates/pop-cli/src/commands/call/contract.rs	84.80%	33 Missing and 72 partials ⚠️
crates/pop-contracts/src/utils/metadata.rs	75.45%	72 Missing and 22 partials ⚠️
crates/pop-cli/src/cli.rs	56.58%	50 Missing and 6 partials ⚠️
crates/pop-contracts/src/up.rs	71.42%	0 Missing and 14 partials ⚠️
crates/pop-contracts/src/call.rs	79.06%	0 Missing and 9 partials ⚠️
crates/pop-cli/src/common/build.rs	72.00%	1 Missing and 6 partials ⚠️
crates/pop-contracts/src/testing.rs	68.42%	0 Missing and 6 partials ⚠️

@@            Coverage Diff             @@
##             main     #306      +/-   ##
==========================================
+ Coverage   70.47%   72.01%   +1.54%     
==========================================
  Files          54       57       +3     
  Lines        9250    10464    +1214     
  Branches     9250    10464    +1214     
==========================================
+ Hits         6519     7536    +1017     
- Misses       1737     1835      +98     
- Partials      994     1093      +99     

Files with missing lines	Coverage Δ
crates/pop-cli/src/commands/up/contract.rs	18.46% <100.00%> (-5.42%)	⬇️
crates/pop-contracts/src/errors.rs	100.00% <ø> (+100.00%)	⬆️
crates/pop-contracts/src/testing.rs	68.42% <68.42%> (ø)
crates/pop-cli/src/common/build.rs	72.00% <72.00%> (ø)
crates/pop-contracts/src/call.rs	80.52% <79.06%> (+1.89%)	⬆️
crates/pop-contracts/src/up.rs	80.33% <71.42%> (+2.44%)	⬆️
crates/pop-cli/src/cli.rs	67.36% <56.58%> (-4.89%)	⬇️
crates/pop-contracts/src/utils/metadata.rs	75.45% <75.45%> (ø)
crates/pop-cli/src/commands/call/contract.rs	82.78% <84.80%> (+82.78%)	⬆️

... and 1 file with indirect coverage changes

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[brunopgalvao]

Overall it LGTM. Some feedback:

┌   Pop CLI : Call a contract
│
◇  Where is your project located?
│  ./
│
◇  Paste the on-chain contract address:
│  5DYs7UGBm2LuX4ryvyqfksozNAW5V47tPbGiVgnjYWCZ29bt
│
└  Unable to fetch contract metadata.
Error: Anyhow error: Cannot infer the root project id

It would be nice if “error” was not repeated. Something like this:

│
◇  Where is your project located?
│  ./
│
◇  Paste the on-chain contract address:
│  5DYs7UGBm2LuX4ryvyqfksozNAW5V47tPbGiVgnjYWCZ29bt
│
└  Unable to fetch contract metadata.
Error: Cannot infer the root project id

Same with this:

◇  Do you want to execute the call? (Selecting 'No' will perform a dry run)
│  Yes 
│
Error: Rpc error: RPC error: Error when opening the TCP socket: Connection refused (os error 61)

Caused by:
    RPC error: Error when opening the TCP socket: Connection refused (os error 61)

Change to this:

◇  Do you want to execute the call? (Selecting 'No' will perform a dry run)
│  Yes 
│
Error when opening the TCP socket: Connection refused (os error 61)

Caused by:
    RPC error: Error when opening the TCP socket: Connection refused (os error 61)

◇  Where is your project located?
│  ./flipper

Autocomplete when typing the contract's location would be useful.

Looking up RPC URL's can be cumbersome. It would be nice to be able to select commonly used RPC URL's such as Pop Network or localhost.

So this:

◇  Where is your contract deployed?
│  wss://rpc1.paseo.popnetwork.xyz

Could be something like this:

◆  Where is your contract deployed?
│  ● Pop Network TestNet (wss://rpc1.paseo.popnetwork.xyz)
│  ○ Local on Port 9944 (ws://localhost:9944) ○ Custom (Specify)

Change this:

◆  Do you want to do another call?
│  ○ Yes  / ● No 

To something like this:

◆  Do you want to do another call?
│  ● No
│  ○ Yes, with the same contract
│  ○ Yes, with another contract on the same chain

If this change will not be incorporated then at least don’t clear the screen when I say “yes” to call another contract so that I can copy the address and chain URL. Regardless, the default for pop call contract should be to never clear the screen when it is ran because I find it useful to have a “log” of calls that I have done either for copying info to use again or simply to remember the order of calls that I have done and with which parameters.

Change this:

◆  Select the message to call:
│  ● flip ( A message that can be called on instantiated contracts.  This one flips the value of the stored `bool` from `true`  to `false` and vice versa.)
│  ○ get 
└  

I would imagine these Rust Doc comments can easily be 4+ lines for a more sophisticated contract.
For example:

/// Use the new `call_v2` host function via the call builder to forward calls to
/// the other contract, initially calling `flip` and then `get` to return the
/// result.
///
/// This demonstrates how to set the new weight and storage limit parameters via
/// the call builder API.

• https://github.com/use-ink/ink-examples/blob/682605fb39f4d9a2d69a48ffc0ce042602386ad9/cross-contract-calls/lib.rs#L75C1-L80C34

Therefore I would have it be displayed underneath the function call making sure to preserve the same formatting that was presented in the Rust Doc comment e.g.:

◆  Select the message to call:
│  ● flip_and_get_invoke_v2_with_limits
|  
│   Use the new `call_v2` host function via the call builder to forward calls to
│   the other contract, initially calling `flip` and then `get` to return the
│   result.
│   
│   This demonstrates how to set the new weight and storage limit parameters via
│   the call builder API.
|  
│  ○ get 
└  

◇  Signer calling the contract:
│  //Alice

For a custom account, I was not sure what to input so I pasted my account’s address:

◇  Signer calling the contract:
│  16hkVKMehgVjTP7AsUvhU8rsYQhK9JDirPWWhpAwHaFTHRfc

Error: Failed to create keypair from URI: Cannot parse phrase: mnemonic has an invalid word count: 1. Word count must be 12, 15, 18, 21, or 24

It was not intuitive to me that it was expecting a mnemonic phrase like so:

│  car pocket team home penalty leg forget attend draft width blush lettuce

[AlexD10S]

Thanks for the feedback @brunopgalvao
Nice catch on the error messages.
I’ve improved the error message you mentioned, but error handling needs a proper refactor in all the project. Since it could become a larger task for this PR, I’ve opened a new issue to address it separately: #309

Great point about placing the message docs below the message name I’ve fixed that:

◆  Select the message to call:
│  ○ flip
 
│  ● get
 ( Simply returns the current value of our `bool`.)
│  ○ specific_flip
 
└ 

Same for clearing the screen when prompting for another call. I liked your idea of reusing the contract information, but I reduced it to two options instead of the three you suggested. If want to call another contract, the user should start again:

◆  Do you want to do another call using the existing smart contract?
│  ○ Yes  / ● No 

Autocomplete for the path and a list of addresses for me are nice-to-have features we can add in the future, feel free to create issues if you think they are needed.

As for the signer, I’m not sure how to improve that right now, but we’ll be working on a better process for signing transactions soon, so hopefully that will make things clearer.

Another piece of feedback from @peterwht that has been implemented is showing the user the call that will be executed after all the values are prompted:

⚙  pop call contract --path ./ --contract 5GumB5XDPMT7i1JAFTApxhEneWqRyLaBGdJb8CVXngb4ngTX --message get --url ws://localhost:9944/ --suri //Alice
│  
◐  Calling the contract...                                                                                                                                            ⚙  Result: Ok(false)

The option to skip the dry-run and submit the call directly is a new feature. I’d prefer to address this in a separate PR. I’ve opened an issue for it: #310.

[Daanvdplas]

Some thoughts;

• Improving the amount of clicks required to call a contract for testing:

1. when I was deploying my contract and testing it I don't want to think about the gas limit or proof size limit. So if we can call contracts with a flag that prevents always having to specify that it would be really nice and decreases the amount of clicks.
2. The last question; whether or not to call the contract again, is unnecessary maybe, just immediately ask for which message to call again and if the user wants to stop it can simply do ctrl c. Again, the fewer clicks the better the devex tmo.
3. The question whether or not to dry-run the call also seems unnecessary for testing. So perhaps a flag dev will prevent the weight limit question described in 1. and also this dry run question

• Improving the functionality and usefulness of the pop cli:
  It would be amazing if we could return the value of the message, this is decoding it and printing it out in the console. Then the dev really doesn't have to use the contracts ui anymore. This is the successful return value, error type, even returning the event would be a requirement here I think.
• Potential bugs:
  I couldn't deploy a new contract while using --salt.

[AlexD10S]

Some thoughts;

• Improving the amount of clicks required to call a contract for testing:

1. when I was deploying my contract and testing it I don't want to think about the gas limit or proof size limit. So if we can call contracts with a flag that prevents always having to specify that it would be really nice and decreases the amount of clicks.
2. The last question; whether or not to call the contract again, is unnecessary maybe, just immediately ask for which message to call again and if the user wants to stop it can simply do ctrl c. Again, the fewer clicks the better the devex tmo.
3. The question whether or not to dry-run the call also seems unnecessary for testing. So perhaps a flag dev will prevent the weight limit question described in 1. and also this dry run question

• Improving the functionality and usefulness of the pop cli:
  It would be amazing if we could return the value of the message, this is decoding it and printing it out in the console. Then the dev really doesn't have to use the contracts ui anymore. This is the successful return value, error type, even returning the event would be a requirement here I think.
• Potential bugs:
  I couldn't deploy a new contract while using --salt.

I like your idea to improving DevEx with less clicks. I’ve added the dev flag which for now skips the point 1 and 3. This provides a good starting point, and we can continue iterating from here @brunopgalvao thoughts?.

Regarding the --salt flag it works for me. Not it has to be an hex encoded value. I tried: --salt 0x6644a2ae6564ea712b23389008cf9e4fe635cd7d4e9b04dd4733eb614c4112ce (generated in https://ui.use.ink/instantiate) and --salt $(date +%s) (example form ink! docs https://use.ink/4.x/basics/cross-contract-calling#basiccontractref-walkthrough)

[evilrobot-01]

High level review only. I think addressing the suggested changes around the call contract command can greatly improve the UX and the simplify the implementation.

A more flexible experience provides a greater experience. With very little refactoring, I can partially specify args on the command line e.g. 'pop call contract --contract xx' and the call UI can be used if message is ommitted.

That means I can enter stuff into the command which I dont want to repeat over and over, and then allow the terminal history to bring it up and to get me back to the bits I want to specify.

I feel this should be addressed prior to this being merged as it improves the UX significantly.

[evilrobot-01]

Running on the command on a fresh project, no build, results in the following:

[AlexD10S]

Running on the command on a fresh project, no build, results in the following:

Good catch! We can apply the same logic as the pop up contract building it if it hasn't been built already.

[al3mart]

Right now we assume that we are receiving a path to a contract project to load the metadata, and if not present build the contract to obtain the metadata.

We only need the metadata in order to call a contract, so it would be handy having both, an option for any user to point to their project and build the contract if necessary, or passing the location of the metadata directly to pop. Maybe the user only has access to the metadata.