-
Notifications
You must be signed in to change notification settings - Fork 353
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
Migrate Account to component #783
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.
Looking good, Eric! I left a few comments and suggestions
Also, the __execute__
method in the API should have self
as a snapshot
Co-authored-by: Andrew Fleming <fleming.andrew@protonmail.com>
…eat/migrate-account-to-component
…rdelo/cairo-contracts into feat/migrate-account-to-component
…eat/migrate-account-to-component
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.
LGTM!
docs/modules/ROOT/pages/index.adoc
Outdated
component!(path: account_component, storage: account, event: AccountEvent); | ||
component!(path: src5_component, storage: src5, event: SRC5Event); |
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.
should each of these be next of their impls?
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 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.
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 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
Co-authored-by: Martín Triay <martriay@gmail.com>
…rdelo/cairo-contracts into feat/migrate-account-to-component
…eat/migrate-account-to-component
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. |
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.
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
src/account/presets/account.cairo
Outdated
/// | ||
/// Openzeppelin's account contract. | ||
#[starknet::contract] | ||
mod Account { |
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 don't love the Account
preset name. I guess we can differentiate between the two Account
s with component
and contract
, but idk. AccountPreset
maybe or something better? Thoughts?
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, but i'd go with BasicAccount
or something, to distinguish from future EthereumAccount
, or MultisigAccount
presets. I'd never call "preset" a contract btw.
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.
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.
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.
we can keep it like this for the time being, we can reassess post wizard
src/tests/presets/test_account.cairo
Outdated
use openzeppelin::tests::account::test_account::{ | ||
deploy_erc20, SIGNED_TX_DATA, SignedTransactionData, TRANSACTION_VERSION, QUERY_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.
I vote we import TRANSACTION_VERSION
and QUERY_VERSION
from the account component and not the test mod
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.
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?
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.
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.
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 think that's fair. Sounds good to me
src/account/presets/account.cairo
Outdated
/// | ||
/// Openzeppelin's account contract. | ||
#[starknet::contract] | ||
mod Account { |
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, but i'd go with BasicAccount
or something, to distinguish from future EthereumAccount
, or MultisigAccount
presets. I'd never call "preset" a contract btw.
Moved the preset changes to #803 |
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.
LGTM! I just left a question
src/account/account.cairo
Outdated
#[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); | ||
} |
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.
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
We also have to update the API from our "Embeddable Implementations" discussion. Maybe it's best to just slip that in here? |
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.
LGTM! +1 to Andrew's comments
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. |
I did also update the component names to add the Component suffix. |
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 Also, we'll have to update the code block under the component title in the API here e.g. |
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! |
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.
LGTM!
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 component and docs heading renames make everything much more clear to me ❤️
Fixes #782
PR Checklist