DEV Community

Discussion on: AppStorage Pattern for State Variables in Solidity

View post
Collapse
 
amxx profile image
Hadrien Croubois •

Regarding the use of an AppStorage struct, I always achieved similar result by creating an abstract AppStorage contract, that all my module/facets inherit from (first inheritance).

Do you have any strong opinion/argument against storage through inheritance ?

Collapse
 
mudgen profile image
Nick Mudge • • Edited

What you describe is the inherited storage pattern. It is totally fine. AppStorage is similar and can also be placed in a storage contract that is inherited by all facets.

What I like about AppStorage is that it adds a "s." prefix to all state variables which separates them from arguments, return variables and local variables. For me this makes things more explicit, clear and prevents name shadowing with function names or other variable names.

Collapse
 
binzydev profile image
Binzy •

The s. is pretty great. Hey have you run into any storage access issues? I cut a new facet and use a library get() function like someFunction() that returns the slot (hashed with keccak256). But it returns empty storage. It's definitely the same diamond contract but seems to get mixed up. Maybe I did something wrong?

library ArcaneBarracksStorage {
bytes32 constant namespace = keccak256("game.arcane.storage.barracks");

struct Storage {
    mapping (address => mapping (uint8 => uint256)) items;
}

function get() internal pure returns (Storage storage s) {
    bytes32 addr = namespace;
    assembly {
        s.slot := addr
    }
}
Enter fullscreen mode Exit fullscreen mode

}

Thread Thread
 
mudgen profile image
Nick Mudge •

You will run into trouble if you declare state variables outside AppStorage or DiamondStorage or inherit contracts that do that.