Make signer optional in getLogicDriver

Description

This issue concerns the signer is not required to execute the call and estimateFuel methods.

Environment

• Operating System: Browser/Linux/macOS/Windows
• Branch/Version: NA

Screenshots

NA

Proposed Solution

Implement new method in base provider.

Passing a tuple/object with argument keys when invoking a endpoint

Description

In the current implementation of cocolang, developers must explicitly mention argument variable names, even when passing a single argument to a function, as demonstrated by the following syntax:

someFunc(name: bhim)

Inspired by this approach, there is a proposal to enhance the js-moi-sdk by adopting a similar convention. The idea is to use tuples instead of arrays when passing arguments to endpoints, aligning the SDK syntax more closely with the cocolang convention.

The current syntax for passing arguments in the SDK looks like this:

logicDriver.routines.someFunc(["bhim"])

The proposed syntax, on the other hand, suggests using a more structured and readable format:

logicDriver.routines.someFunc({name: "Bhim"})

In this proposed change, each argument is explicitly labeled with its corresponding parameter name. To ensure code integrity, the SDK should implement thorough validation. If there is a mistake in the number of arguments provided, an invalid argument name, or a datatype mismatch, the SDK should check against the manifest and throw an appropriate error.

Proposal to Simplify Code Structure in SDK for .call() Routine

Description

The existing code structure appears as follows:

let ixResponse = await logicDriver.routines.GetPosts()
let { allPosts } = (await ixResponse.result()).output;

This proposal suggests simplifying it to the following form:

let { allPosts } = await logicDriver.routines.GetPosts().unwrap();

With this proposed change, devs can use .unwrap() to directly retrieve the returned object if they are not concerned about the ixResponse data.

Comparison

This proposal draws inspiration from the approach taken by ethers.js in simplifying their call methods:

await erc20.decimals();
// you get 18

The intention is to streamline the code structure and enhance the developer experience with a more readable syntax.

Description

Create a unified package for moi.js which should include all the sub-packages. The package should enable easy access to the various functionalities offered by moi.js. Additionally, each sub-package should remain independently available for separate installation and usage.

Description.

• Implement the latest RPC methods available in the protocol.
• Upgrade the logic factory and driver components to seamlessly accommodate the latest "call" and "estimateFuel" methods.
• Fix the deep struct calldata encoding bug in js-moi-manifest package.

TypeScript Declaration File Linking Causing Build Failure

When attempting to build the project, there is a critical error caused by the linkage between the TypeScript declaration file (*.d.ts) index.d.ts and import from the src directory inside the js-moi-signer. This linkage issue is impeding the successful compilation of the project.

Additional Information:

Package Version: 0.1.2

Support for optional nonce in logic calls

Description

The current state of the JavaScript library lacks support for an optional nonce parameter in logic calls. This feature is crucial for certain use cases where nonce values need to be included

Environment

• Operating System: Browser/Linux/MacOs/Windows
• Branch/Version: NA

Screenshots

NA

Proposed Solution

Add the nonce as an optional field in LogicIxArguments

Not allowing user to pick between .call() and .send() when doing routines.endPoint()

Description

Presently, developers have the option to choose between two methods:

routines.SomeEndpoint.call()
// or
routines.SomeEndpoint.send()

This choice may cause confusion, especially for new developers. Additionally, it introduces the risk of developers unintentionally calling a read-only endpoint using .send(), which is not only inefficient (consumes gas and creates a tesseract) but also considered bad practice.

The desired behavior is to have the js-moi-sdk automatically determine the appropriate method based on the nature of the endpoint being called.

Additionally, if a developer intends to simulate interaction with a mutating function, they should continue to use routines.someEndpoint.call() (as per the existing convention).

However, the option of using routines.someEndpoint.send() for this purpose should be deprecated and ultimately removed - The SDK should only decide if the endpoint being called is a mutating function and internally use .send() for such interactions.

Possible resolution

To achieve this behavior, the js-moi-sdk should emulate the pattern used by ethers.js when handling different types of functions:

How ethers handle a mutate function call -

const tx = await erc20Contract.transfer(toAddress, amount);
const receipt = await tx.wait();

How ethers handle a view function call -

const balance = await erc20Contract.balanceOf(targetAddress);

Implement new RPC Methods for Handling pending interactions and tesseracts

Description

Introduce methods that enable operations such as retrieving pending tesseracts based on account filters, fetching pending interaction filters, removing filters, and obtaining changes made to specific filters since the last poll.

Environment

• Operating System: Browser/Linux/macOS/Windows
• Branch/Version: NA

Screenshots

NA

Proposed Solution

Implement new method in base provider.

Description

Implement a feature for listening to the pending interactions

Description

• Update the HTTP transport package from axios to cross-fetch due to compatibility issues in certain environments.
• Rectify inaccuracies in the readme and documentation to improve clarity and accuracy.