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

Migrate Account to component #783

Merged

Conversation

ericnordelo
Copy link
Member

Fixes #782

PR Checklist

  • Tests
  • Tried the feature on a public network
  • Documentation

Copy link
Collaborator

@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.

Looking good, Eric! I left a few comments and suggestions

Also, the __execute__ method in the API should have self as a snapshot

src/account/account.cairo Outdated Show resolved Hide resolved
src/account/account.cairo Outdated Show resolved Hide resolved
src/account/account.cairo Outdated Show resolved Hide resolved
docs/modules/ROOT/pages/api/account.adoc Outdated Show resolved Hide resolved
src/tests/account/test_account.cairo Show resolved Hide resolved
src/tests/account/test_dual_account.cairo Outdated Show resolved Hide resolved
docs/modules/ROOT/pages/api/account.adoc Show resolved Hide resolved
ericnordelo and others added 4 commits October 18, 2023 12:38
Co-authored-by: Andrew Fleming <fleming.andrew@protonmail.com>
…rdelo/cairo-contracts into feat/migrate-account-to-component
Copy link
Collaborator

@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.

LGTM!

src/account/account.cairo Outdated Show resolved Hide resolved
src/tests/account/test_dual_account.cairo Outdated Show resolved Hide resolved
src/tests/mocks/account_mocks.cairo Outdated Show resolved Hide resolved
src/tests/mocks/account_mocks.cairo Outdated Show resolved Hide resolved
Comment on lines 74 to 75
component!(path: account_component, storage: account, event: AccountEvent);
component!(path: src5_component, storage: src5, event: SRC5Event);
Copy link
Contributor

Choose a reason for hiding this comment

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

should each of these be next of their impls?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think is easier to read with the component! macro calls on top, because you can quickly get what components are being used. I don't think there's much value on moving them next to the impls, but no strong opinion.

Copy link
Contributor

@martriay martriay Oct 28, 2023

Choose a reason for hiding this comment

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

agree on making components easy to understand at a quick glance. Just to counterbalance, the value I see is grouping logically related lines, making it easy to:

  • add/remove components without affecting all lines
  • make sure all directives for a component are in place (event, component, importing impl)
  • performing reviews gets simpler and easier, based on the above items

docs/modules/ROOT/pages/api/account.adoc Outdated Show resolved Hide resolved
docs/modules/ROOT/pages/api/account.adoc Show resolved Hide resolved
docs/modules/ROOT/pages/api/account.adoc Show resolved Hide resolved
@ericnordelo
Copy link
Member Author

I added a preset with tests, maybe it is too much for just one PR. Let me know if I should better split it. Documenting the preset in the doc-site API corresponding section is still missing.

Copy link
Collaborator

@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.

Looking good, Eric! I left some comments and questions

I added a preset with tests, maybe it is too much for just one PR. Let me know if I should better split it. Documenting the preset in the doc-site API corresponding section is still missing.

Yeah, I'd split the presets into another PR so discussions on that don't block this getting merged. The more tight and focused the PR, the better IMO

///
/// Openzeppelin's account contract.
#[starknet::contract]
mod Account {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't love the Account preset name. I guess we can differentiate between the two Accounts with component and contract, but idk. AccountPreset maybe or something better? Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

Agree, but i'd go with BasicAccount or something, to distinguish from future EthereumAccount, or MultisigAccount presets. I'd never call "preset" a contract btw.

Copy link
Member Author

Choose a reason for hiding this comment

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

FWIW, I rather keep the name clean as Account, because the separation exists in the directory (imports) structure, and you cannot use a component as a preset, or a preset as a component (compiler error), so the potential issues from this clash are minimal IMO.

For Account we can come up with a name, but what about ERC20? Which names would you use for the preset? Since we are probably removing presets in favor of Wizard anyway, I vote for keeping the name as just Account (and ERC20 when it comes the time).

Let me know if I still should update it, and to what name then.

Copy link
Contributor

@martriay martriay Oct 31, 2023

Choose a reason for hiding this comment

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

we can keep it like this for the time being, we can reassess post wizard

src/tests/account/test_dual_account.cairo Outdated Show resolved Hide resolved
src/tests/presets/test_account.cairo Outdated Show resolved Hide resolved
src/tests/presets/test_account.cairo Outdated Show resolved Hide resolved
Comment on lines 6 to 8
use openzeppelin::tests::account::test_account::{
deploy_erc20, SIGNED_TX_DATA, SignedTransactionData, TRANSACTION_VERSION, QUERY_VERSION
};
Copy link
Collaborator

Choose a reason for hiding this comment

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

I vote we import TRANSACTION_VERSION and QUERY_VERSION from the account component and not the test mod

Copy link
Collaborator

Choose a reason for hiding this comment

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

So I'm wondering if we should move presets/ into the component test directory. My thinking is that we could create a component-specific utils file and import deploy_erc20, SIGNED_TX_DATA, and SignedTransactionData from it (since we're reusing these with accounts). One concern I have, though, is that presets may not have a long future because of the wizard. Maybe it's not worth the trouble, idk. Thoughts?

Copy link
Member Author

@ericnordelo ericnordelo Oct 30, 2023

Choose a reason for hiding this comment

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

IMO it is easier to follow in one separate folder. If you want to check all our presets, you could check one place. In the other case, you would need to search all the components to see if there is a preset or not for it. We should be deprecating presets soon enough, but in the meantime, I vote for having a separate presets folder, and a separate one in tests as well to match.

PD: I had the preset folder inside the account folder, but I changed that to match the previous paragraph.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think that's fair. Sounds good to me

src/account/interface.cairo Outdated Show resolved Hide resolved
docs/modules/ROOT/pages/api/account.adoc Outdated Show resolved Hide resolved
src/account/account.cairo Outdated Show resolved Hide resolved
src/tests/account/test_account.cairo Outdated Show resolved Hide resolved
Scarb.lock Outdated Show resolved Hide resolved
src/tests/account/test_account.cairo Show resolved Hide resolved
src/tests/account/test_dual_account.cairo Outdated Show resolved Hide resolved
src/tests/mocks/account_mocks.cairo Show resolved Hide resolved
src/account/interface.cairo Outdated Show resolved Hide resolved
src/account/interface.cairo Outdated Show resolved Hide resolved
///
/// Openzeppelin's account contract.
#[starknet::contract]
mod Account {
Copy link
Contributor

Choose a reason for hiding this comment

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

Agree, but i'd go with BasicAccount or something, to distinguish from future EthereumAccount, or MultisigAccount presets. I'd never call "preset" a contract btw.

@ericnordelo
Copy link
Member Author

Moved the preset changes to #803

Copy link
Collaborator

@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.

LGTM! I just left a question

Comment on lines 4 to 8
#[starknet::interface]
trait IPublicKey<TState> {
fn set_public_key(ref self: TState, new_public_key: felt252);
fn get_public_key(self: @TState) -> felt252;
fn set_public_key(ref self: TState, new_public_key: felt252);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since this is an I trait, should we move it to interface.cairo? I'm not sure if we established rules with what goes in there and what stays local in the file

@andrew-fleming
Copy link
Collaborator

LGTM! I just left a question

We also have to update the API from our "Embeddable Implementations" discussion. Maybe it's best to just slip that in here?

Copy link
Contributor

@martriay martriay left a comment

Choose a reason for hiding this comment

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

LGTM! +1 to Andrew's comments

@ericnordelo
Copy link
Member Author

I updated the Account API sections. Let me know your thoughts. When we achieve some consensus around the naming of the section, I will update them all (other existing API pages) before merging the PR.

cc @martriay @andrew-fleming

@ericnordelo
Copy link
Member Author

I did also update the component names to add the Component suffix.

@andrew-fleming
Copy link
Collaborator

Very nice! My question was meant just for the account API, but doing them all also works :)

I'm thinking it might be better, in the API, to change EMBEDDABLE CAMELCASE SUPPORT to EMBEDDABLE CAMELCASE IMPLEMENTATIONS to provide more consistency with the naming convention. Wdyt?

Also, we'll have to update the code block under the component title in the API here e.g.
Account
use openzeppelin::account::Account;

@ericnordelo
Copy link
Member Author

I'm thinking it might be better, in the API, to change EMBEDDABLE CAMELCASE SUPPORT to EMBEDDABLE CAMELCASE IMPLEMENTATIONS to provide more consistency with the naming convention. Wdyt?

I think I lean more towards EMBEDDABLE IMPLEMENTATIONS (CAMELCASE), just because I think it looks better visually, lol, but no strong defense, let me know which one you prefer and I will update accordingly.

@andrew-fleming
Copy link
Collaborator

I think I lean more towards EMBEDDABLE IMPLEMENTATIONS (CAMELCASE), just because I think it looks better visually, lol, but no strong defense, let me know which one you prefer and I will update accordingly.

Sounds good to me!

Copy link
Collaborator

@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.

LGTM!

Copy link
Contributor

@martriay martriay left a comment

Choose a reason for hiding this comment

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

The component and docs heading renames make everything much more clear to me ❤️

@martriay martriay merged commit 69dc448 into OpenZeppelin:main Nov 1, 2023
1 check passed
@ericnordelo ericnordelo deleted the feat/migrate-account-to-component branch November 1, 2023 22:16
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.

Migrate Account to component
3 participants