-
Notifications
You must be signed in to change notification settings - Fork 138
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC2981 (Royalty Info) for Cairo #413
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look great @immrsd. We should think of a way to group imports together, but that's out of the scope of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, @immrsd! Overall, the PR looks good to me. I left a few questions and comments
libraryPathSegments.splice(-1, 1, componentMappings[lastItem]); | ||
libraryPathSegments.splice(-1, 1, componentMappings[lastItem] as string); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there cases where the the value won't be a string (if it's not undefined)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this cast needed? The inferred type should already be string
, and these mappings are defined on line 27 above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another way could be to use a non-null assertion instead: componentMappings[lastItem]!
<RoyaltyInfoSection bind:opts={opts.royaltyInfo} errors={errors} /> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The window is getting pretty crowded with all the features. Maybe we should consider doing something like having a dropdown menu that opens when the box is checked for votes and royalty? Outside of this PR's scope though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, we should consider that
On the other hand, the Cairo control panels are still more concise that the Solidity ones and if we decide to go with that approach it may make sense to also apply it to the Solidity version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @immrsd, this looks great! Just a few comments.
libraryPathSegments.splice(-1, 1, componentMappings[lastItem]); | ||
libraryPathSegments.splice(-1, 1, componentMappings[lastItem] as string); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this cast needed? The inferred type should already be string
, and these mappings are defined on line 27 above.
export const enabledDefaults: RoyaltyInfoOptions = { | ||
enabled: true, | ||
defaultRoyaltyFraction: '10', | ||
feeDenominator: DEFAULT_FEE_DENOMINATOR.toString() | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this is only used in generate/erc{1155,721}.ts
, which has generator functions for testing different possible combinations. In this case:
- rename or add a comment to make it more clear that these values are just for testing
generate/erc{1155,721}.ts
should use an array of the different combinations to test with
For example, define something like the following:
export const enabledDefaults: RoyaltyInfoOptions = { | |
enabled: true, | |
defaultRoyaltyFraction: '10', | |
feeDenominator: DEFAULT_FEE_DENOMINATOR.toString() | |
}; | |
export const testRoyaltyInfoOptions = [ | |
{ | |
enabled: false, | |
defaultRoyaltyFraction: '10', // these should be ignored since enabled is false | |
feeDenominator: DEFAULT_FEE_DENOMINATOR.toString(), | |
}, | |
{ | |
enabled: true, | |
defaultRoyaltyFraction: '100', | |
feeDenominator: DEFAULT_FEE_DENOMINATOR.toString(), | |
}, | |
{ | |
enabled: true, | |
defaultRoyaltyFraction: '10000', | |
feeDenominator: '100000', | |
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this is the desired approach, so I've added 3 different options. The only problem is that now instead of 800 generated contracts we have 2000. That shouldn't be a problem, but as a result Scarb compiler required more than 100 GB of RAM at some point during compilation. I've barely managed to compile all the contracts and it took more than 30 minutes
Scarb compiler is not yet well-optimized and this behaviour shouldn't be normal. We should look into it, it seems that some compilation steps that should be O(1) are in fact O(n). Although, I reckon it shouldn't be in the scope of this PR
upgradeable: upgradeableOptions, | ||
royaltyInfo: [royaltyInfoEnabled], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my other comment, this should be an array of the different combinations that we want to test using the generator function.
@@ -17,6 +18,7 @@ const blueprint = { | |||
appVersion: ['v1'], | |||
pausable: booleans, | |||
mintable: booleans, | |||
royaltyInfo: [royaltyInfoEnabled], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my other comment, this should be an array of the different combinations that we want to test using the generator function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to add some tests in packages/core-cairo/src/erc721.test.ts
and packages/core-cairo/src/erc1155.test.ts
so that their snapshots are included.
Can you also bump the version in packages/core-cairo/package.json
?
The rest LGTM, thanks!
ERC2981
(RoyaltyInfo) toERC721
andERC1155
uint
Cairo types in input fields