Add macros package and the with_components macro

[ericnordelo]

Quickstart #1258

NOTE: A summary of the features included in the macro is added below after the example:

Example:

Simplifies this:

#[starknet::contract]
pub mod MyToken {
    use openzeppelin_access::ownable::OwnableComponent;
    use openzeppelin_token::erc20::{ERC20Component, ERC20HooksEmptyImpl};
    use starknet::ContractAddress;

    component!(path: ERC20Component, storage: erc20, event: ERC20Event);
    component!(path: OwnableComponent, storage: ownable, event: OwnableEvent);

    impl ERC20InternalImpl = ERC20Component::InternalImpl<ContractState>;
    impl OwnableInternalImpl = OwnableComponent::InternalImpl<ContractState>;

    #[storage]
    pub struct Storage {
        #[substorage(v0)]
        erc20: ERC20Component::Storage,
        #[substorage(v0)]
        ownable: OwnableComponent::Storage,
    }

    #[event]
    #[derive(Drop, starknet::Event)]
    enum Event {
        #[flat]
        ERC20Event: ERC20Component::Event,
        #[flat]
        OwnableEvent: OwnableComponent::Event,
    }

    #[constructor]
    fn constructor(ref self: ContractState, owner: ContractAddress) {
        self.ownable.initializer(owner);
        self.erc20.initializer("MyToken", "MTK");
    }
}

Into this:

#[with_components(ERC20, Ownable)]
#[starknet::contract]
pub mod MyToken {
    use openzeppelin_token::erc20::ERC20HooksEmptyImpl;
    use starknet::ContractAddress;

    #[storage]
    pub struct Storage {}

    #[constructor]
    fn constructor(ref self: ContractState, owner: ContractAddress) {
        self.ownable.initializer(owner);
        self.erc20.initializer("MyToken", "MTK");
    }
}

Summary of features:

IT DOES:

• Accepts multiple components from an internal whitelist (currently only ERC20 and Ownable for the POC).
• Validates that the contract has the #[startknet::contract] attribute, shows an error in compilation otherwise.
• Validates that the contract has the corresponding initializers in the constructor, shows a warning listing the missing initializers otherwise.
• Adds the use clauses for each component (i.e: use openzeppelin_access::ownable::OwnableComponent;)
• Adds the corresponding component! macros (i.e: component!(path: OwnableComponent, storage: ownable, event: OwnableEvent);).
• Adds the corresponding internal implementations (i.e: impl OwnableInternalImpl = OwnableComponent::InternalImpl<ContractState>;)
• Adds the storage entries to the Storage struct, using the lowercase version of the component name without the component keyword (i.e: ownable: OwnableComponent::Storage,)
• Adds the event entries to the Event enum, and creates the enum if it is missing.

IT DOES NOT:

• Adds the external implementations or hooks.
• Create the constructor and/or initializers.

Things to be considered still:

• openzeppelin_access vs openzeppelin::access in use clauses (configurable notation?)
• Configurable storage and event entries per component.
• Add default external embedded impls?
• Add warnings to other things, like missing camelCase interface.

Some may be addressed in different PRs/issues.

NOTE: I have plans to include a with_component macro which will accept only a single component but more configuration, like replacing the storage entry. People then may use both macros together (with_components and with_component)

PR Checklist

• Tests
• Documentation
• Added entry to CHANGELOG.md
• Tried the feature on a public network

[andrew-fleming]

Fantastic work on this @ericnordelo! I left some comments

Also, since so much of the component boilerplate is abstracted away, I don't think it's super obvious what the storage entry is for a given component. It'll be documented, for sure, but would it make sense just to simplify it further and use the same capitalized name as the whitelisted component i.e.

#[with_components(ERC20, Ownable)]
#[starknet::contract]
pub mod MyToken {
    (...)

    #[constructor]
    fn constructor(ref self: ContractState, owner: ContractAddress) {
        self.Ownable.initializer(owner);
        self.ERC20.initializer("MyToken", "MTK");
    }
}

This gives a point of reference inside the contract as opposed to attempting, for example, reentrancy_guard or reentrancyguard

[andrew-fleming]

Same here. I know the lib isn't entirely consistent (might be worth addressing in a separate issue), but I think it could get weird when we have timelock_controller vs accesscontrol and reentrancyguard

[ericnordelo]

I will refactor them here (for macros). We may update presets and mocks in a separate issue later.

[ericnordelo]

This gives a point of reference inside the contract as opposed to attempting, for example, reentrancy_guard or reentrancyguard

Since developers are already using snake case for storage members, I vote we stay with snake case, but split the words accordingly.

[andrew-fleming]

This gives a point of reference inside the contract as opposed to attempting, for example, reentrancy_guard or reentrancyguard

Since developers are already using snake case for storage members, I vote we stay with snake case, but split the words accordingly.

This is true...no strong pushback against keeping snake case, I just think reusing the name could be a bit more intuitive. If we wanted to make a change like this, it'd be better to do it now with the feature