ViewContract or why do I need to create an account if I want to use only query methods?

[strangeweb3guy]

So in the current API, when I use near-api-js Contract only for query methods(view methods), I need to create a redundant account

const near = await naj.connect(nearConfig);
const account = await near.account("");
return new ValidatorContract(account, config.poolId);

with an empty string, otherwise, I am not able to use the Contract, it is not an obvious thing for developers and it should be changed.

Also, we already have questions like that on StackOverflow, but the solution is to not use near-api-js and it will definitely confuse people.

What I propose is to implement another contract for example view contract where you will pass the connection and contract and will receive, the contract that you need without an account.

[frol]

What is ValidatorContract? Is this your type? I believe it is better if you illustrate the issue using the near-api-js types (i.e. Contract).

What I propose is to implement another contract for example view contract where you will pass the connection and contract and will receive, the contract that you need without an account.

The new ViewContract type sounds like a trivial solution, but from DevX point of view, there will be two types now: Contract and ViewContract, and the difference is not intuitive as from the naming it looks like ViewContract is Contract + View while in fact Contract = ViewContract + account + change methods.

I would argue that Contract signature is broken:

near-api-js/packages/near-api-js/src/contract.ts

Line 144 in 9189e11

constructor(account: Account, contractId: string, options: ContractMethods) {

What is account for the Contract?

near-api-js/packages/near-api-js/src/contract.ts

Line 140 in 9189e11

* @param account NEAR account to sign change method transactions

What if I want to sign change method calls with different accounts?

ViewContract won't be necessary if Contract would be just defined by contractId and options. I believe that signerAccount should be passed directly to each change-method function call just like gas and amount (attached deposit) are passed.

I think it is still realistic to refactor Contract to address it while maintaining backward compatibility. What do you think?

cc @andy-haynes @itegulov @volovyks

[frol]

Well, in fact, @kiskesis pointed out that Contract needs Connection which is currently extracted from Account, so here is the updated proposal in a pseudo-code:

interface IntoConnection {
    getConnection(): Connection,
}

class Account {
 ...
  getConnection(): Connection {
    return this.connection;
  }
}

class Connection {
 ...
  getConnection(): Connection {
    return this;
  }
}

class Contract {
  account?: Account,
  connection: Connection,
  contractId: string,

  constructor(connection: IntoConnection, contractId, options) {
    this.connection = connection.getConnection();
    if (connection is Account) {
      // print deprecation note
      this.account = connection;
    }
    // ...
    // change methods should expect `signerAccount` argument next to `args`, `gas`, `amount`, which will be prepopulated with this.account if set (for backward compatibility with the old code)
  }
}

[strangeweb3guy]

Also, part of the implementation is to move viewFunction from account.ts to new utils (I propose to create a new file view-function.ts) and all functions that needs to use in contract.ts and account.ts.

near-api-js/packages/near-api-js/src/account.ts

Lines 474 to 506 in 9189e11

	async viewFunction({
	contractId,
	methodName,
	args = {},
	parse = parseJsonFromRawResponse,
	stringify = bytesJsonStringify,
	jsContract = false,
	blockQuery = { finality: 'optimistic' }
	}: ViewFunctionCallOptions): Promise<any> {
	let encodedArgs;
	this.validateArgs(args);
	if(jsContract){
	encodedArgs = this.encodeJSContractArgs(contractId, methodName, Object.keys(args).length > 0 ? JSON.stringify(args): '');
	} else{
	encodedArgs = stringify(args);
	}
	const result = await this.connection.provider.query<CodeResult>({
	request_type: 'call_function',
	...blockQuery,
	account_id: jsContract ? this.connection.jsvmAccountId : contractId,
	method_name: jsContract ? 'view_js_contract' : methodName,
	args_base64: encodedArgs.toString('base64')
	});
	if (result.logs) {
	printTxOutcomeLogs({ contractId, logs: result.logs });
	}
	return result.result && result.result.length > 0 && parse(Buffer.from(result.result));
	}

It will look the same, but use the connection as an argument.

async viewFunction({
        connection: Connection,
        contractId,
        methodName,
        args = {},
        parse = parseJsonFromRawResponse,
        stringify = bytesJsonStringify,
        jsContract = false,
        blockQuery = { finality: 'optimistic' }
    }: ViewFunctionCallOptions): Promise<any> {
        let encodedArgs;
        
        validateArgs(args);
    
        if(jsContract){
            encodedArgs = this.encodeJSContractArgs(contractId, methodName, Object.keys(args).length >  0 ? JSON.stringify(args): '');
        } else{
            encodedArgs =  stringify(args);
        }

        const result = await connection.provider.query<CodeResult>({
            request_type: 'call_function',
            ...blockQuery,
            account_id: jsContract ? connection.jsvmAccountId : contractId,
            method_name: jsContract ? 'view_js_contract'  : methodName,
            args_base64: encodedArgs.toString('base64')
        });

        if (result.logs) {
            printTxOutcomeLogs({ contractId, logs: result.logs });
        }

        return result.result && result.result.length > 0 && parse(Buffer.from(result.result));
    }

[frol]

@kiskesis The proposal to extract utility functions makes total sense to me! 👍

[denbite]

the proposed idea was implemented in #1325