Init/Default design in NEAR SDK JS

[volovyks]

Problems we are trying to solve:

• Now init() function is generated for the user. It looks too magical.
• Boilerplate default() function in every contract
• init() function can be called several times (we need to add #[init] analog from Rust) that would prevent this
• We MUST call init() function after deployment. (handled by Default and PanicOnDefault in Rust SDK)

Let's not forget to do things JS (OOP) way:

• If the contract is a class, it should be initialized with a constructor()
• If we want to have default values - they should be specified in the constructor

Known restrictions:

• We can not use near.signerAccountId() and other APIs in the constructor if it can be called from the “view” function

Design proposal:

• constructor is the only way to initialize the contract
• constructor can be called directly, or from the call function in case STATE does not exist
• constructor call will throw an error, if STATE already exists
• Default values are set in the constructor
• If Default values are not set, call and view functions will throw errors (as an alternative, view function can return null)

These principles create 3 possible life cycles: view, call, and init:

In order to implement this design, we will need to:

• delete init() autogeneration
• expose constructor as a function that can be called externally (by user or developer)
• fall back to default parameters if the STATE does not exist instead of throwing errors
• autogenerate default() function, which will always try to create an object using contractor without parameters. Example:

function default() {
        return new Counter({});
}

Known limitations:

• There is no constructor overloading in JS, so we can have only one "init function". On the other hand - part of the parameters can be defaulted to some value, it should solve most of the user requests.

cc @ailisp @gagdiez @austinabell @BenKurrek @MaximusHaximus

[gagdiez]

For the view flow, would it be too difficult to just use the call flow? if it fails (because there are no parameters or a call-only method is invoked) then we catch the error and fail with a "contract not initialized"

[volovyks]

@gagdiez It will not satisfy this restriction: "We can not use near.signerAccountId() and other APIs in the constructor if it can be called from the “view” function"

Also, view calls never write to the state, it requires signing, gas, etc.

[gagdiez]

I thought that being view or call is a property of the call, not the method itself. For example, you can do near view <a-call-method>, and it will fail with an error.

Based on that, there are two options:

1. the constructor is a view method, in which case it behaves as a Default since it can return an instantiated object
2. or it is a call method, because it needs to set up stuff, and therefore it behaves as a panicOnDefault.

If somebody makes a view call and the state is not initialised, we can simply evoke the constructor(), if it fails it is because the contract was not initialised.

[volovyks]

@gagdiez

view and call options in CLI just limit the type of parameters you can pass with the call (like signer).

the constructor is a view method, in which case it behaves as a Default since it can return an instantiated object

Constructor can not be a "view" method, because it will limit us to use only "view" APIs. Something like this will not be possible: https://github.com/near/near-sdk-js/blob/develop/examples/src/fungible-token.js#L21

If somebody makes a view call and the state is not initialised, we can simply evoke the constructor(), if it fails it is because the contract was not initialised.

We can not evoke the constructor in view calls, because it can contain things like
https://github.com/near/near-sdk-js/blob/develop/examples/src/fungible-token.js#L21

or it is a call method, because it needs to set up stuff, and therefore it behaves as a panicOnDefault.

What do you mean by "behaves as a panicOnDefault"? PanicOnDefault is something that affects other functions, not the init function (constructor). If you have passed all needed parameters - all good. If you have not, but there are default parameters - all good, we are using them. If you have not passed any parameters and there are no default parameters in the constructor - throw an error.

[volovyks]

Agreed with @gagdiez to try to call the default function in view instead of throwing an error.

[ailisp]

I think @volovyks proposed workflow is quite solid. Take Counter contract, with default Counter.count=0 as an example:

• init with a given initial count, or if not provided, initial count = 0
• init twice will error
• call and view after init will work
• call before init will call constructor with initial count = 0 and work

The only thing doesn't work great is view before init points by @gagdiez , and Serhii also agreed. Seems the challenge here is user can use near.signerAccountId() etc. in constructor, but if "view" reuse constructor for initialization, it would fail. Does rust contract works in this case?

[volovyks]

I think Rust should work the same way, if you have near.signerAccountId() in your Default implementation - it will fail. @ChaoticTempest @austinabell tell me if I'm wrong please.