gnolang / gno-js-client Goto Github PK

There would be a lot of interesting experimentations (leading to many use cases) if that was the case,
but for now I can only use this locally.

That lib is sooo where web3 is. It needs some endpoints!

The documentation link in the README of the NPM package points to
https://onbloc.gitbook.io/gnoland-developer-portal/docs/gno-js-client
which redirects to
https://docs.gno.land/docs/gno-js-client (404)

It should be https://docs.gno.land/reference/gno-js-client as in the README of this repository, should be solved automatically with the next package publish

In the documentation, the Provider methods (getRenderOutput , getFunctionSignatures , evaluateExpression , getFileContent ) all take an optional height param.

There are 2 problems with it:

• The doc isn't clear about the default value if not provided:

If omitted, the latest height is used (optional, default 0)
So is it the latest height or 0 ??

• Even if the param is passed, in reality it's not used in the code and hardcoded to 0, developers reading the documentation should be aware of that instead of having to look in the code.
  • https://github.com/gnolang/gno-js-client/blob/main/src/provider/websocket/ws.ts#L31
  • https://github.com/gnolang/gno-js-client/blob/main/src/provider/jsonrpc/jsonrpc.ts#L36

currently, evaluateExpression throws a "constant" error here if the query failed, where the gnokey cli returns the actual go error

this is a pain for dev where you have to run a modified client or the cli to know the actual error message

Add the ability to load modules that provide type-safe methods (arguments and return types) corresponding to exposed contract methods to interact with contracts in a type-safe and controlled manner while enjoying dev perks such as coe-completion type lookups etc.

Please expose the original ABCIResponse from GnoJSONRPCProvider.evaluateExpression as it's quite useful to have a uniform response type in logic that allow both running tx calls and eval commands.

Introduction

To enhance interoperability and simplify the development of dApps on the Gno.land, I propose the creation of a common TypeScript interface. This interface will standardize the methods, properties and responses required to interact with the Gno.land, ensuring that different implementations can be easily integrated and maintained.

This proposal is similar to what viem and abitype offers to Ethereum. The ultimate goal is to create a toolbox of Typescript like wevm

Objectives

• Standardization: Provide a consistent interface for various packages to interact with the Gno.land.
• Interoperability: Ensure that different projects can easily switch between or use multiple implementations.
• Ease of Use: Simplify the development process for dApp developers by providing a clear and unified API.

Proposed Common Interface

The common interface will define the essential methods and properties that any Gno.land blockchain client should implement.

PR to be Created

To facilitate detailed discussion, I propose creating an issue for each method as outlined below:

• getBalance - PR 120
• getAccount: next
• ...

References

• web3 libraries comparison