ts: Add views

[tomlinton]

Since #1598 instruction return types are in the IDL, and we know which instructions are mutable from the accounts, so we can add an <instruction>.view() to the client and the methods API builder that parses the logs and deserializes the return data.

E.g.

assert(
      new anchor.BN(99).eq(await callerProgram.methods.returnU64().view())
);

This came from looking at #566 which called for an explicit attribute for marking views, but I don't think we need it since #1598. Might be wrong though!

Closes #566.

[armaniferrante]

The no macro approach is much better!

[armaniferrante]

I forgot to add the changelog. Will do next.

[zikyfranky]

I know this is not the right place to do this, but does anyone have any idea why .view() on the client side triggers wallet signing?

Had to recreate the logic so as to get it working on my app.

[dev-johnny-gh]

@zikyfranky How they implement the view method is that they sign the transaction and simulate it on the endpoint(connection) and get the result, it's a very bad design compared to solidity.

[zikyfranky]

@dev-johnny-gh it really is a bad design asking end users to sign a VIEW call, it doesn't make sense whatsoever.

Thanks for the reply.

[jakerumbles]

@zikyfranky Running into the same issue here. Can't have phantom popping up left and right on our dapp just for read calls to the chain. How did this design pass beta testing?

[zikyfranky]

@zikyfranky Running into the same issue here. Can't have phantom popping up left and right on our dapp just for read calls to the chain. How did this design pass beta testing?

Exactly my thought haha.. it doesn't make any sense whatsoever to have end users sign READ instructions..

Anyways, created a gist that contains my fix, basically was a remake of the logic behind the view function
https://gist.github.com/zikyfranky/da0117a0e587899e39ffea10255abc1f