Add more possibilities to call contract messages

[VargSupercolony]

The problem

The problem right now is that contract messages (txs & queries), which have a trait prefix, are only callable like myTraitMyMethod. Previously, the stringCamelCase function allowed commas, so we could differentiate between message name and trait name when calling the functions. Like this:

const myContractCallOutcome: ContractCallOutcome = await myContract.query['MyTrait,myMethod'](...)

But now, as the stringCamelCase function replaces the commas with whitespace (and camelCases the trait), it means we have only one way to call a contract function:

const myContractCallOutcome: ContractCallOutcome = await myContract.query.myTraitMyMethod(...)

As the trait names may grow longer, we end up calling simple methods like this:

const myContractCallOutcome: ContractCallOutcome = await myContract.query.myVeryLongTraitNameBalanceOf(...)

In some cases, we don't want the frontend calls to contain the trait names, and with this approach, it is almost impossible to remove the trait prefixes without doing hacks.

Proposed solution

The proposed solution is following:

1. For ink v3.0.0-rc6, as the trait names and method names are separated by a comma, leave a comma there, camelCase the method name and write to the query object. (Ends up like myContract.query['MyTrait,myMethod'])
2. For ink v3.0.0-rc7 and potentially later versions, as the trait names and methods are separated by ::, add the unchanged generated identifier to the query and tx objects. (Ends up like myContract.query['MyTrait::my_method'])
3. Regardless of the version, add the camelCased version of call as it is now. (Ends up like myContract.tx.myTraitMyMethod)

In the end, we want to end up with several ways to call the same ABI message.

I would be pleased to work on this issue personally if you need my help :)

[jacogr]

The API doesn't track or work on ink versions. So have no idea what versions you are referring to. What it does do is work on the version of the metadata, which is actually broader than ink itself, i.e. versioned metadata is also output by other compilers, for instance solang.

In both your examples, providing an ABI to see what the different outputs are is the best route.

[VargSupercolony]

Of course.

This is a metadata.json file generated for ink v3.0.0-rc6 (V1 metadata):

{
          "args": [],
          "docs": [
            " Returns the token name."
          ],
          "mutates": false,
          "name": [
            "PSP22Metadata",
            "token_name"
          ],
          "payable": false,
          "returnType": {
            "displayName": [
              "psp22metadata_external",
              "TokenNameOutput"
            ],
            "type": 19
          },
          "selector": "0x3d261bd4"
        }

This one is V3 metadata by ink v3.0.0-rc7:

{
          "args": [],
          "docs": [
            " Returns the total token supply."
          ],
          "label": "BaseErc20::total_supply",
          "mutates": false,
          "payable": false,
          "returnType": {
            "displayName": [
              "Balance"
            ],
            "type": 0
          },
          "selector": "0x8244a1ad"
        }

So in the V1 metadata, the 'name' key denotes the method name, and it's an array of trait prefix + method name. In V3, it's located in the 'label' key, and follows Rust syntax of Trait::method. My proposal is to include multiple ways to call method, like myTraitMyMethod & ['MyTrait::my_method'] (for V3) or ['MyTrait,myMethod'] (for V1).

[jacogr]

So I understand why in V1 the name came through with ,, it was wrongly serialized.

As for the V3 with the :: labels, also have not seen this one. Both full .contract files (or similar ones) would be great to add as tests - neither form appears anywhere in the V0-V3 samples that are available.

For the first - checks against the v1ToLatest function to ensure it ends up in the same form as the current V3 traits

For the second - seeing what it actually does in practice and then being able to formulate some way around it.

[VargSupercolony]

I can do that, just assign me to this issue

[VargSupercolony]

So for the first, I checked how the messages containing traits are parsed - and indeed they are in a different format.
This is how the messages get parsed from V3 metadata:

And V1 metadata:

[jacogr]

Indeed, that is what #4471 addresses - it changes the up-conversion to combine the name -> labels in the same way as natively supplied in V2+, aka with ::

This is where more actual real-world contracts are needed, none of the versions tested against has the same type of labelling, https://github.com/polkadot-js/api/tree/master/packages/api-contract/src/test/contracts

[VargSupercolony]

Ok, got it. Should I provide example contracts & tests for conversions?

[jacogr]

That would be great, one V1 with the namespaces (https://github.com/polkadot-js/api/tree/master/packages/api-contract/src/test/contracts/ink/v1) and a V2/V3 (doesn't matter, they would both be equivalent with label) would help a lot.

[VargSupercolony]

I'm on it 👌

[VargSupercolony]

#4472

[VargSupercolony]

Pining the issue to continue the discussion regarding method calls.
Since we completed the first thing we wanted to do, let's get back to the original point of the proposal:

This is what the contract query object looks like for me on my front-end (metadata V1, @polkadot/api v ^7.4.1). As you can see, there is only one way to call the methods of the contract, which is by camelCasedTraitNameAndMethodName. I want to suggest adding two more ways of calling the contracts' methods (for all metadata versions):

• Call using contract.query/tx['PSP22.balanceOf'] or contract.query/tx.PSP22.balanceOf syntax
  This would actually create a really neat way of grouping the messages by traits, so PSP22 object would contain accordingly namespace messages.

• Call using contract.query/tx['PSP22::balance_of'] syntax

As the new generated metadata with the label attribute suggests us using Rust's syntax, I feel like it would be great to add this to the query/transaction objects. (As well as display it this way on the contracts UI, but that's a different issue 😄 )

Again, feel free to assign me to these tasks.
Looking forward to hearing your thoughts on the suggestion

[jacogr]

Indeed, now that the discrepancies have been addressed, back to the original.

The contracts contract.{tx, query}.<method> actually has a flaw compared to the methods on the api.{tx, query}.* interfaces. The API variants also exposes the actual metadata, e.g. api.query.system.account.meta in the ABI's these are not available. (Just logged that here #4484).

Basically with the metadata available, things like UIs can then display additional extra information, i.e. original trait info. (It can be gotten to at this point, but it really does need to be consistent, and here it is not yet)

So generally the API itself never decorates using Rust syntax, it decorates with JS syntax - which we everywhere try to get to via stringCamelCase. (Contracts, API, etc)

So on the options you laid out -

• I'm not in favor of exposing contract.{tx, query}['PSP22::balance_of'] at all - this basically means that we have multiple names for the same underlying method. We have a 1-to-1 mapping between the interfaces and what is on the ABIs
• The contract.{tx, query}.<nameSpace>.<method> could be interesting. Once again, this would make users have to jump through some hoops, e.g. contract.{tx, query}.something may have something as a namespace or method, so it does break downstream code and removes consistency.

Something like contract.ns.psp22.{query, tx}.balanceOf may be worth investigating. (Or something similar to the format, e.g. contract.ns.query.p2p22.balanceOf). However once again, here we are in JS camelCase syntax, not Rust syntax.