boostxyz / boost-protocol

A permissionless, trustless, and decentralized growth engine for protocol and application developers. It enables developers to bootstrap their projects by leveraging the power of community and the network effect.
https://boost-protocol.vercel.app
GNU General Public License v3.0
4 stars 2 forks source link

feat: add names to all events and functions signatures inputs #191

Open sammccord opened 1 week ago

sammccord commented 1 week ago

Description

Frontend needs to show detailed info about action steps. They have the signature, and @boostxyz/signatures to get the event/function name, but would need names for individual inputs to both help users create boosts, and our devs to build richer ui.

Suggested Solution

Add names to all events and functions in boost-protocol/packages/signatures/manifests

ie Transfer(address indexed,address indexed,uint256 indexed) becomes Transfer(address indexed from,address indexed to,uint256 indexed amount)

Quazia commented 1 week ago

This will cause args to get returned as K:V pairs instead of an array - they're unnamed for internal use intentionally. We could maintain both or maintain the named list and employ a helper to strip out the names. This is related to the signatures ergonomics work @topocount was going to focus on next. The ask here is basically that we need to serve the event as a human readable ABI with params in some way right?

Quazia commented 1 week ago

Another somewhat related thing I noticed recently too is there are some issues if we have the same event selector but the configuration of what is indexed is different - i.e. Transfer(address indexed,address indexed,uint256 indexed) vs Transfer(address indexed,address indexed,uint256)

topocount commented 1 week ago

@Quazia We have a ticket for that isssue with indexed vs nonindexed args here: https://linear.app/rh-app/issue/BOOST-4764/modify-the-eventaction-validators-to-account-for-indexed-args-through

sammccord commented 1 week ago

This will cause args to get returned as K:V pairs instead of an array - they're unnamed for internal use intentionally. We could maintain both or maintain the named list and employ a helper to strip out the names. This is related to the signatures ergonomics work @topocount was going to focus on next. The ask here is basically that we need to serve the event as a human readable ABI with params in some way right?

Yeah, Boost detail designs, and create flow rely on input names to label actions to be less error-prone and make the ui richer.

topocount commented 1 week ago

@sammccord this needs to be downstream of the work on signature package eronomics, as it'll break EventAction right now.