seatlab-dev / forked-near-rust-sdk Goto Github PK

Given the changes from #1, it may be possible to generate openapi files describing each method, including it's type and docs information. This should make creating/maintaining documentation much easier.

Draft notes:

• JsonSchema
  • For structs X and Y, with X::y being Y, the X::y documentation shows up but the Y one doesn't.
  • For the mods a and b and structs a::X and b::X, their name X will collide and thus should be able to potentially be named a.X and b.X.
  • Functions from the same trait or from the same impl block could be grouped together by having the same tag. This aligns whit an improvement for grouping the methods together from each impl block in a single trait, instead of each method having it's own trait.
• OpenAPI
  • The spec 3.0.x forbids the GET http request methods from having a json body.
    • Currently the PATCH is being used instead of the GET.
    • The spec 3.1 allows for that and is thus should be better, but there is less tooling and library support for it. So for now it's advisable to stick to the 3.0.x spec.
  • The files, assuming they will exist as artifacts and can be linked to, can be rendered by third-parties websites such as in this example.

Some changes to the sdk are being worked on, which should make testing more ergonomic.
The current change can be found on 4.0.0-pre.8...556b6dd, from the https://github.com/Seatlab-dev/Forked-Near-Rust-Sdk/tree/seatlab-changes branch.

For the exported methods:

• The Inputs are made public.
• A trait is created for each method, giving types that implement it a possibility of getting a method name that equals the actual method name on the contract.
  • This means that tests no longer need to use macros, and the input, the output and the method name are setup automatically.
  • Rust-analyzer also shows all methods available.

In order to mature those changes, the tests and documentations should be updated. Another improved would be that instead of creating one trait for each method, a single trait for all methods from the same module could be created.

Something to consider: to somehow try to merge all traits from different modules into a single super trait, so the tests could import only this unique trait which would imply all methods.

edit: once this is matured, and although the upstream project is getting away from the old simulation testing framework, this changes could still be suggested to the near foundation as (I believe) it could still help on the new workspace testing framework.