search

near / bounties

Specs for technical and non-technical work that earns NEAR tokens
https://devgovgigs.near.social
72 stars 8 forks source link

NEAR + Rust Contract Interface Parser #42

Closed TrevorJTClarke closed 3 years ago

TrevorJTClarke commented 3 years ago

Description

Building a dapp currently needs manual input of function names into changeMethods & viewMethods to use in near-api-js. Other popular blockchains have build scripts that parse the contracts to extract the "ABI", which allows for easy javacript module import and usage.

Context

In building several dapps, its become a common missing piece to have my rust contracts auto-compile to use within the website frontend connections via near-api-js. A couple examples can be seen with Near Vue Tailwind and Near Ceramic

Acceptance Criteria

Example Use/Outcome

Rust Source code:

## snippet from https://github.com/near-examples/rust-counter/blob/master/contract/src/lib.rs
#[near_bindgen]
impl Counter {
    /// Returns 8-bit signed integer of the counter value.
    pub fn get_num(&self) -> i8 {
        return self.val;
    }

    /// Increment the counter.
    pub fn increment(&mut self) {
        self.val += 1;
        let log_message = format!("Increased number to {}", self.val);
        env::log(log_message.as_bytes());
        after_counter_change();
    }

ES Module Output: (rough example)

export const getContractInterface = () => {
  return {
    changeMethods: [
      'increment'
    ],
    viewMethods: [
      'get_num'
    ]
  }
}

Bounty

1000 NEAR

ouromoros commented 3 years ago

This looks fun. I would like to work on it.

ouromoros commented 3 years ago

OK, my first thoughts are to manually do some simple parsing work and probably some regex to match and find the methods in Rust source code. However, this can result in a lot of edge cases if not treated carefully and will probably in the end result in writing a basic Rust lexer/parser.

Second thoughts are using rustc to generate AST tree output and start from there. However, this would require user to have rustc nightly or rustup installed since outputing AST feature is only enabled in nightly version.

IMO the latter seems a more viable and extensible approach. What bugs me is the nightly thing, but there doesn't seem to be better alternative. I plan to write a JS tool that utilizes the generated AST and auto-generate module code.

frol commented 3 years ago

@TrevorJTClarke We already had such a bounty: https://github.com/near/bounties/issues/11, and there is the implementation. Please, clarify how it is different this time.

The problem I see with such hacky solutions is that we cannot really recommend anyone using it. There should be a complete implementation with tests and I believe, it should be part of near-sdk-rs, which will generate some JSON spec along with the code-generation it does.

/cc @potatodepaulo @chadoh @ilblackdragon @luciotato

TrevorJTClarke commented 3 years ago

@frol -- thanks, i was unaware of this project.

I think NEAR needs this: https://github.com/luciotato/create-contract-cli/blob/master/src/lib/Parser/Parser.ts to be exposed in an easy to use manner, as part of the default build scripts for every dapp project, so that anyone can get a contract module available to import without manually managing the interfaces.

luciotato commented 3 years ago

@TrevorJTClarke @frol, It seems he needs a different output: an ES module for easy import into near-api-js

The create-near-cli utility creates something similar as an intermediate output but then goes on and generates an entire cli-tool from that. BTW it's directed at developers, the output is code, you're supposed to continue from there.

I can do what @TrevorJTClarke asks, and also I can separate the parser as another lib package (near-rust-sc-simple-parser), so anyone needing to parse NEAR rust smart contracts in the future can use it and maybe extend it

I've no problem doing all of that. If y'all agree, then reopen the bounty.

TrevorJTClarke commented 3 years ago

@luciotato @frol yes, thats correct -- it would solve UX with FE development. Just want to comment on this: it should be part of near-sdk-rs I looked into this first, it seems the only route here is adding more macros (syn lib), which makes the developer maintain the output, rather than simply generating from code. This to me seems more hacky than maintaining a parser, as there's already libraries out there for parsing rust (for IDEs, etc).

Having a parser would enable things like Hardhat, truffle, embark exist for NEAR.

frol commented 3 years ago

@TrevorJTClarke If there is happen to be an extra layer on top of near-sdk-rs attributes, parsers will just fail, and it will be always a "catch me" game for parsers. Having the implementation right in near-sdk-rs macros, we can evolve and extend the functionality in a fully compatible way. If we properly define the specification, we can solve more problems:

There is even some initial work done: https://github.com/near/near-sdk-rs/pull/99 (though, I think we need to integrate it deeper instead of asking to wrap the code with another extra macro)

TrevorJTClarke commented 3 years ago

@TrevorJTClarke If there is happen to be an extra layer on top of near-sdk-rs attributes, parsers will just fail, and it will be always a "catch me" game for parsers. Having the implementation right in near-sdk-rs macros, we can evolve and extend the functionality in a fully compatible way. If we properly define the specification, we can solve more problems:

* [near/NEPs#3](https://github.com/near/NEPs/pull/3)

* [near/nearcore#274](https://github.com/near/nearcore/issues/274)

* [near/NEPs#129](https://github.com/near/NEPs/pull/129)

* [near/near-wallet#66](https://github.com/near/near-wallet/issues/66)

* [near/devx#5](https://github.com/near/devx/issues/5)

There is even some initial work done: near/near-sdk-rs#99 (though, I think we need to integrate it deeper instead of asking to wrap the code with another extra macro)

I see, I agree it would be nice to expose a way to simply view methods directly, as long as the developer is not maintaining the exposed methods via extra macros. If that is close to getting released, it would be worth the wait, otherwise I still think its valuable to make something that bootstraps quickly for the developer to use.

frol commented 3 years ago

@TrevorJTClarke it is anywhere close to release, and I propose instead of wasting our energy with hacks, empower our community to finish the proper solution. Bounties that create yet another project for us to maintain are not helpful, and will most certainly just die due to lack of maintenance :cry:

TrevorJTClarke commented 2 years ago

@frol checking in on this, any movement on the "proper solution"? Would love to get this built, either the proper solution or diff project.

frol commented 2 years ago

@TrevorJTClarke I know that @miraclx has recently discussed this problem.

@miraclx @austinabell I want to loop you in this conversation since you folks can make the change happen!

austinabell commented 2 years ago

Ah, yes, very much is a topic of discussion and something we are hoping to have a workable solution for this quarter (or at least define the spec and PoC)