Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: clean GRC721 implementation #2117

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

leohhhn
Copy link
Contributor

@leohhhn leohhhn commented May 15, 2024

Description

Ported from here for visibility.

This is an experiment involving a refactor of the GRC721 package. The idea with this is that we might want a fully "by-spec" implementation, that people who know the standard can use out of the box.

The process for writing this was the following:

  • Wrote the implementation in Go
  • Ported the implementation to Gno
  • Wrote an exampleNFT app using the package

This PR replaces the old GRC721 implementation with the new one, and updates the foo721 example realm, and removes the nft example realm to only have a single example implementation.

Contributors' checklist...
  • Added new tests, or not needed, or not feasible
  • Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
  • Updated the official documentation or not needed
  • No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
  • Added references to related issues and PRs
  • Provided any useful hints for running manual tests
  • Added new benchmarks to generated graphs, if any. More info here.

@leohhhn leohhhn requested review from a team as code owners May 15, 2024 20:45
@leohhhn leohhhn requested review from jaekwon and piux2 and removed request for a team May 15, 2024 20:45
@github-actions github-actions bot added the 🧾 package/realm Tag used for new Realms or Packages. label May 15, 2024
@irreverentsimplicity
Copy link
Contributor

irreverentsimplicity commented May 21, 2024

LGTM to. As far as I'm concerned, there are no breaking changes. It's nice to have an implementation following the standard ERCs. I will update Flippando to use this realm once the PR is merged.

Copy link
Contributor

@irreverentsimplicity irreverentsimplicity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only major thing is the addition of the external Ownable realm, but it's not a breaking change. LGTM.

@leohhhn leohhhn changed the title x: clean GRC721 implementation feat: clean GRC721 implementation Jun 5, 2024
@leohhhn leohhhn requested a review from moul June 5, 2024 16:46
@linhpn99
Copy link
Contributor

linhpn99 commented Jun 6, 2024

after this PR is merged, i will update NFT's extensions realms @leohhhn

deelawn pushed a commit that referenced this pull request Jun 6, 2024
<!-- please provide a detailed description of the changes made in this
pull request. -->

## Description

This PR removes the outdated (and full of mistakes) guide from the docs.
After [this PR](#2117) is merged, we
can add a create a new how-to guide on how to create a GRC721 token.
I've added [an issue](#2288) about
this.

<details><summary>Contributors' checklist...</summary>

- [x] Added new tests, or not needed, or not feasible
- [x] Provided an example (e.g. screenshot) to aid review or the PR is
self-explanatory
- [x] Updated the official documentation or not needed
- [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message
was included in the description
- [x] Added references to related issues and PRs
- [ ] Provided any useful hints for running manual tests
- [ ] Added new benchmarks to [generated
graphs](https://gnoland.github.io/benchmarks), if any. More info
[here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md).
</details>
Comment on lines 12 to 16
owners *avl.Tree // tokenID > std.Address
balances *avl.Tree // std.Address > # of owned tokens
tokenApprovals *avl.Tree // tokenID > std.Address
operatorApprovals *avl.Tree // "OwnerAddress:OperatorAddress" -> bool
tokenURIs *avl.Tree // tokenID > URI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since you've at least 3 elements sharing the same key, I suggest having a single avl.Tree but returning an object.

nft.getApproved(tokenId) == owner
}

func (nft Token) update(to std.Address, tokenId string, auth std.Address) std.Address {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func (nft Token) update(to std.Address, tokenId string, auth std.Address) std.Address {
func (nft *Token) update(to std.Address, tokenId string, auth std.Address) std.Address {

was the code currently working?
because it shouldn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that this was working mainly because I use pointers to the AVL storage. Tests were also passing. I'll see to either use non-pointers for AVL trees or just add pointer receivers.

Copy link
Contributor Author

@leohhhn leohhhn Jun 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ended up just making the function take receiver pointers, as avl.NewTree returns a pointer.

}
}

std.Emit("Transfer", "from", from.String(), "to", to.String(), "tokenID", tokenId)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
std.Emit("Transfer", "from", from.String(), "to", to.String(), "tokenID", tokenId)
std.Emit("Transfer",
"from", from.String(),
"to", to.String(),
"tokenID", tokenId,
)

I suggest this format for emitted events, until we can have typesafe ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

# Conflicts:
#	examples/gno.land/r/demo/nft/README.md
#	examples/gno.land/r/demo/nft/z_0_filetest.gno
#	examples/gno.land/r/demo/nft/z_1_filetest.gno
#	examples/gno.land/r/demo/nft/z_2_filetest.gno
#	examples/gno.land/r/demo/nft/z_3_filetest.gno
#	examples/gno.land/r/demo/nft/z_4_filetest.gno
@dongwon8247
Copy link
Member

It this PR still relevant? @jinoosss is working on supporting GRC721s in Adena & GnoScan. Let us know the status of the PR, thanks!

@leohhhn
Copy link
Contributor Author

leohhhn commented Nov 5, 2024

Hey @dongwon8247, sorry for the late reply.

Any package we make for the GRC721 standard will have the same API. I think going forward with this in mind should be the way, and it will especially show us if we're maintaining this standard properly.

I think this PR will be closed, as we're discovering some new ways of working with GRCs (specifically grc20, ie here)

@leohhhn leohhhn marked this pull request as draft November 15, 2024 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🧾 package/realm Tag used for new Realms or Packages.
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

5 participants