feat(examples): awesome gno

[matijamarjanovic]

implementation of https://github.com/gnolang/gno/issues/3928

This is an on chain representation of the Awesome Gno repo which serves a purpose of showcasing dApp built in the community. The way this implementation works is:

• there are 2 lists (avl.Trees) : apps and categories
• app can have multiple categories and multiple apps can be part of a category
• admins (regulated by authz package) can add/update/remove both apps and categories
• apps are onchain representation of real gno-related projects from awesome-gno holding the url to the project and the addresses of the authors

UI (mock data):

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• [ ] IGNORE the bot requirements for this PR (force green CI check)
• [x] The pull request description provides enough details (checked by @thehowl)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info) 🟢 Pending initial approval by a review team member, or review from tech-staff

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: matijamarjanovic/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Pending initial approval by a review team member, or review from tech-staff

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 Not (🔴 Pull request author is a member of the team: tech-staff)

Then

🟢 Requirement satisfied
└── 🟢 If
    ├── 🟢 Condition
    │   └── 🟢 Or
    │       ├── 🟢 User leohhhn already reviewed PR 3963 with state APPROVED
    │       ├── 🟢 At least 1 user(s) of the team tech-staff reviewed pull request
    │       └── 🔴 This pull request is a draft
    └── 🟢 Then
        └── 🟢 Not (🔴 This label is applied to pull request: review/triage-pending)

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

The pull request description provides enough details

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 Not (🔴 Pull request author is a member of the team: core-contributors)
    └── 🟢 Not (🔴 Pull request author is user: dependabot[bot])

Can be checked by

• team core-contributors

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests.

:loudspeaker: Thoughts on this report? Let us know!

[jefft0]

Problem here with "not enough arguments in call to page.Picker", same as https://github.com/gnolang/gno/pull/3793#issuecomment-2740926222 :-)

[matijamarjanovic]

Problem here with "not enough arguments in call to page.Picker", same as #3793 (comment) :-)

Addressed in https://github.com/gnolang/gno/pull/3963/commits/567df81c14e0b67ab65ffa77653a4e6268f3b87d. I've also added hof registration (if you remember https://github.com/gnolang/gno/pull/3479 it caused lint to break in init) which suprisingly causes no trouble here..

[matijamarjanovic]

On top of this, I know you spent time implementing the proposal feature, but I think that for now we should start simple - scrap this and just allow admins to add/remove/update items - until the commondao PR is merged. After that, we can make a new PR to implement it here.

I was aware this might happen when I was making the system so don't worry about it, I completely agree. I will be addressing the changes and ping you when I'm done. Thank you for the insight

[matijamarjanovic]

The more I got into implementing changes you requested @leohhhn the more I realized that this had to be redone, so the last couple of commits contain:

• removal of the proposal making/aproving concept
• only add/update/delete dapps and categories are left
• dapps and categories structs are containing avl trees of eachother instead of slices of ids
• full capacity of authz: all the exposed funcs are using the Do function for authz that calls non-exposed functions with actual logic. this way when common dao is available it can be more easily implemented by just calling these functions and until then admins can manage the realm
• dapp can now have multiple authors
• introduction of panics instead of errors
• all avl.Trees are using seqids as keys
• exposed RO trees in place of getters
• minimalistic and better ui using txlink for better ux
• datasource covering new data

in short terms, all the requested changes have been applied 1 by 1 and although there were a lot of changes i'd say this is a much cleaner and more readable version

description is updated with screenshots of new ui

[leohhhn]

Let's see if the CI is ok with the code (it won't be) - try to fix up the tests and test it manually to support cross/crossing.

if not, we can merge into examples_draft and then you can make a PR to fix it later

[leohhhn]

Can you add a function to render out links to the last X items? We can then add this to the home page.

[matijamarjanovic]

Can you add a function to render out links to the last X items? We can then add this to the home page.

I have done so in https://github.com/gnolang/gno/pull/3963/commits/f8fafc65fd022a17da02c704d78316dd6dd7ebba; the problem I have found with this implementation (using fifo package) is that the admins would have to predefine the size of the items to get manually and get the list of that size. This means you couldn't technically dinamically change the size of the return values since the items in the list would be cut off if X is smaller than the current size or would just return current number of items if X is larger than that since the rest of the spaces would be empty.

If it is significant to have a dinamically changing value i would stick to using avl tree and just iterate it X times since the items are sorted in the order they were added chronologically anyway. Let me know which implementation is more suiting and I can do it. I have also used the same formatting in the "widget" as I have in awesome gno Render()

[leohhhn]

Will be taking a look at this soon

[michelleellen]

@leohhhn @matijamarjanovic it would be great to have this awesome gno realm!

[matijamarjanovic]

Hey @leohhhn, I've updated the imports in awesome gno, can you please re-review and let me know if there are any changes to be made