Skip to content
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

Open
wants to merge 24 commits into
base: master
Choose a base branch
from

Conversation

immrsd
Copy link
Contributor

@immrsd immrsd commented Nov 27, 2024

  • Add support for ERC2981 (RoyaltyInfo) to ERC721 and ERC1155
  • Support uint Cairo types in input fields
  • Support constants in trait implementations
image

Copy link
Member

@ericnordelo ericnordelo left a 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.

Copy link
Contributor

@andrew-fleming andrew-fleming left a 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);
Copy link
Contributor

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)?

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's needed (at least in the Typescript version I'm using). There's a check componentMappings[lastItem] !== undefined, but since the dictionary is mutable, the compiler can't guarantee that on the next line an item at the lastItem will still exist

image

Copy link
Member

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]!

Comment on lines +76 to +77
<RoyaltyInfoSection bind:opts={opts.royaltyInfo} errors={errors} />

Copy link
Contributor

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

Copy link
Contributor Author

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

packages/core-cairo/src/set-royalty-info.ts Outdated Show resolved Hide resolved
packages/core-cairo/src/utils/convert-strings.ts Outdated Show resolved Hide resolved
Copy link
Member

@ericglau ericglau left a 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.

packages/ui/src/cairo/RoyaltyInfoSection.svelte Outdated Show resolved Hide resolved
libraryPathSegments.splice(-1, 1, componentMappings[lastItem]);
libraryPathSegments.splice(-1, 1, componentMappings[lastItem] as string);
Copy link
Member

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.

packages/core-cairo/src/set-royalty-info.ts Outdated Show resolved Hide resolved
packages/core-cairo/src/contract.ts Outdated Show resolved Hide resolved
packages/core-cairo/src/contract.ts Outdated Show resolved Hide resolved
Comment on lines 15 to 19
export const enabledDefaults: RoyaltyInfoOptions = {
enabled: true,
defaultRoyaltyFraction: '10',
feeDenominator: DEFAULT_FEE_DENOMINATOR.toString()
};
Copy link
Member

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:

Suggested change
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',
];

Copy link
Contributor Author

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

Screenshot 2024-11-29 at 09 10 36

upgradeable: upgradeableOptions,
royaltyInfo: [royaltyInfoEnabled],
Copy link
Member

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],
Copy link
Member

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.

packages/core-cairo/src/set-royalty-info.ts Outdated Show resolved Hide resolved
Copy link
Member

@ericglau ericglau left a 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants