Feat/factory supports parameter within struct #1343
Conversation
…reaking down struct to find param
| @@ -6,6 +6,21 @@ const llamaFactoryEventAbiItem = parseAbiItem( | |||
| "event LlamaInstanceCreated(address indexed deployer, string indexed name, address llamaCore, address llamaExecutor, address llamaPolicy, uint256 chainId)", | |||
| ); | |||
|
|
|||
| const FactoryEventSimpleParamsAbiItem = parseAbiItem([ | |||
There was a problem hiding this comment.
- I think you need to use
parseAbihere because there are multiple items - We use
camelCasefor most identifiers
There was a problem hiding this comment.
- In case of function/event with struct, parseAbiItem can be used https://viem.sh/docs/abi/parseAbiItem#parameters . As parseAbiItem was already in use, I preferred to stick to it.
- Refactored, camelCase all the way. 🫡
| const parameterParts = parameter.split("."); | ||
|
|
||
| let offset = 0; | ||
|
|
||
| parameter = parameterParts[0]!; | ||
|
|
There was a problem hiding this comment.
There should be an explicit validation check that this exists, like if (parameter === undefined) throw new Error(...) like on line 53.
Also, I think these lines should be below where we build the address and eventSelector.
There was a problem hiding this comment.
Added the check, but I think these lines should be before building the address and eventSelector. As there's the possibility of parameter being undefined, the building of the address and eventSelector will be unnecessary. 🤔
There was a problem hiding this comment.
Fair enough, we just generally try to group concerns for readability, eg first parse address, then parse selector, then event, then parameter.
Another nit - we avoid re-assigning function parameters like you're doing with parameter here, would prefer something like
const firstParameterSegment = parameterSegments[0];| "struct MarketParams {address loanToken; address collateralToken; address oracle; address irm; uint256 lltv;}", | ||
| ]); | ||
|
|
||
| const FactoryEventWithDynamicChildParamsAbiItem = parseAbiItem([ |
There was a problem hiding this comment.
We should also include a test case where a struct/array is one of the indexed arguments and the user attempts to use one of its properties as the child address parameter. I think we'll have to validate against this - the address is not actually available in the event body because the value gets hashed and then stored as one of the topics.
| const parameterParts = parameter.split("."); | ||
|
|
||
| let offset = 0; | ||
|
|
||
| parameter = parameterParts[0]!; | ||
|
|
There was a problem hiding this comment.
Fair enough, we just generally try to group concerns for readability, eg first parse address, then parse selector, then event, then parameter.
Another nit - we avoid re-assigning function parameters like you're doing with parameter here, would prefer something like
const firstParameterSegment = parameterSegments[0];| "struct ChildInfo { address childAddress; string name; uint256 initialValue; uint256 creationTime; address creator; }", | ||
| ]); | ||
|
|
||
| const factoryEventWithDynamicChildParamsAbiItem2 = parseAbiItem([ |
There was a problem hiding this comment.
Which of the fields here is dynamic? This one still looks static to me.
[Not Complete Yet]
@typedarray