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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

cw721-sylvia-base #127

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
Open

cw721-sylvia-base #127

wants to merge 15 commits into from

Conversation

JakeHartnell
Copy link
Collaborator

@JakeHartnell JakeHartnell commented Jun 21, 2023

Adds a similar contract to cw721-base but written with the Sylvia smart contract framework.

There are a few advantages to Sylvia over the extension based pattern we currently have:

  • Custom Queries and Execute messages can be added at the top level. No more need to wrap them in ExecuteMsg::Extension.
  • Easier to add new custom messages and queries
  • Less interaction with traits, way less complicated types
  • Easier to write tests! Sylvia + multi-test is super sweet

Have some open questions which I would love folks thoughts on if they have them:

  • Do we still want to support extensions at all for token metadata? Or do we just kill them? (personally leaning towards the later)
  • How should we organize this codebase? Took a stab based on some Sylvia examples, but open to suggestions.
  • As we move forward, should we focus more on a Sylvia based approach? Or stick with the extension pattern we have (which is already well used).

Closes #31 hopefully someday 馃

@the-frey
Copy link
Collaborator

Top line thought: this is useful to have in the repo. If Sylvia becomes more widely adopted, we should begin to provide a 'paved path'. If it doesn't, then it's either still useful documentation for somebody, or could be hypothetically removed later (although, personally once something is in, I think we should maintain it, see below).

Do we still want to support extensions at all for token metadata? Or do we just kill them? (personally leaning towards the later)

Depending on the effort to do so, yes, because they are widely in production and it's probably better to offer alternatives rather than hard deprecate a given pattern.

How should we organize this codebase? Took a stab based on some Sylvia examples, but open to suggestions.

No strong thoughts on this one as don't personally use Sylvia.

As we move forward, should we focus more on a Sylvia based approach? Or stick with the extension pattern we have (which is already well used).

I guess as referred to in my first response I think folks that want to focus on Sylvia can put those contracts here so that other people can use them, but if people don't want to use Sylvia, then that's valid. Any framework usually has some drawbacks WRT flexibility and from my understanding the same is true here.

There's another question of whether it's more approachable to beginners. My guess would be no, as there's a bit more upfront type stuff to parse in exchange for simpler definitions of data, but could be wrong about that!

@JakeHartnell JakeHartnell changed the title WIP: cw721-sylvia-base cw721-sylvia-base Jun 28, 2023
@JakeHartnell
Copy link
Collaborator Author

Added more tests, coverage should be decent by now. Will add a template for a basic sylvia cw721 contract after this is reviewed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extension is difficult & other long term design decisions
2 participants