Open sammccord opened 1 day ago
The encodeAbiItem
is particularly nice. If this isn't too difficult it seems like it's strictly better than how we're doing it right now. I forsee the most prickly part would be squaring the difference between the ABI typing and the typescript viem typing (i.e. uint256 = bigint uint8 = number Address = string etc etc)
Description
Right now, SDK implementers creating Boosts with EventActions accept a non-zero amount of cognitive load and guesswork to build a correct ActionStep, including:
fieldIndex
of the parameter to compare against, which is potentially error prone and only resolved by cancelling and recreating the boostfilterData
, which involves using viem utilities and right-sizing the bytes for the type, which can be error prone - for example:filterData: toHex(1n, { size: 1 })
Suggested Solution
If the signature is supported in
@boostxyz/signatures
, we should be able to utilize typescript generics and type inference to know the types of arguments at each index, what thefieldType
is, and how to correctly encode thefilterData
given the ABI type, removing two potential sources of human error in Boost construction, and moving errors that would normally occur during validation, likeFieldValueNotComparableError
andInvalidNumericalCriteriaError
, into the construction step.In pseudo code, the API could work like: