Storage Factory Contract: Managing Simple Storage Instances

The storage Factory contract efficiently manages and interacts with multiple simple storage contracts.

### Understanding Storage Factory and Simple Storage Contracts in Solidity
* 📜 The Storage Factory contract manages multiple Simple Storage contracts, allowing for **efficient creation and interaction** with them.
* 🔄 By implementing a function called `SF store`, which takes in a **storage index** and a **new number**, the factory can store values in the deployed **Simple Storage contracts**.
* 📡 To interact with these contracts, two crucial elements are required: the contract's **address** and its **Application Binary Interface (ABI)**, which defines how to interact with it.
* 📊 Instead of storing just a single Simple Storage contract, the factory maintains an **array of deployed contracts**, enabling it to **keep track of all addresses**.
* 🔍 After deploying the factory and creating Simple Storage contracts, users can **store and retrieve values**, confirming functionality through transactions.
* 🛠 A new function, `sfget`, is introduced to read values from the Simple Storage contracts, ensuring users can **access stored data effectively**.
* 📝 The ABI is automatically generated upon compilation, which allows the Remix IDE to provide **interaction buttons for the functions available in the deployed contracts**.
* 💡 Overall, the Storage Factory **streamlines the process of managing and interacting with multiple Simple Storage contracts**, enhancing Solidity programming practices.

now as you can see, though, right now, every single time we call create simple storage contract, we're going to deploy a new simple storage contract, but we're going to override it in this simple storage, right? So if we go ahead and deploy this right now, scroll down here, simple storage at the zero address, create, okay, now it's at a new address, create again, okay, now it's at a new address. We're not keeping track of all the different addresses that this simple storage contract is being deployed to. So let's actually create a running list of all the different simple storage contracts that we're deploying. So instead of having this variable be just a single simple storage contract, let's have it be an array or list of simple storage contracts, and we'll change the name to list of simple storage contracts. So now when we deploy it, instead of saving it like this, we're going to do what we did before in our last section. We'll say simple storage new simple storage contract equals new simple storage, and then we'll push it onto our Dynamic array. So we'll say list of

simple storage contracts push new simple storage contract, so let's go ahead and compile this. Okay, looks good. Let's go ahead and deploy this. We'll delete our old one. We're on the remix VM. Great. Storage Factory. And look at this. You can even see. Make sure we're on Storage Factory. Okay, great. We'll go ahead and deploy that. Awesome. We get a list of simple storage contracts, which now has this un256 input, which allows us to choose the index of the variable. We'll go ahead and create simple storage. Now we go check the zeroth index. We have an address. If we check the first index, nothing happens. If we call create again, which, sorry if I have the terminal up, I'll call create again. Again, now there is one at the first index. And since I called it twice, there's also one on the second. There's nothing at the third. I'll hit create again. There's no one at the fourth. Oh, at the third, excuse me. Awesome. So now we actually have a running list of all of our simple storage contracts. Now let's learn how to actually interact.

with other contracts from a contract for now we can think of our storage Factory as a sort of manager for all these other contracts. So let's learn how our storage Factory contract can actually call the store function of the simple storage that it deploys. So let's create a function called SF store, which is going to stand for storage Factory Store, and it's going to take two variables: a uint256 underscore simple storage index and a uint256 underscore new simple storage number. We'll make this public like this. Now, in order to interact with a contract, you're always going to need two things, and we're going to refer to this a lot. You need an address, and you're going to need the ABI. Now, this is technically a lie. You really just need the function selector, but we're going to learn that way, way later in the course. For now, just think, Okay, I always need the address, and I always need the ABI. The ABI stands for application binary interface. The ABI will tell our code exactly how it can interact with another

contract. We'll go deeper into the API later on in this course, but for now, if you go to the compile tab, hit compile, and you scroll down, there's this little button at the bottom that says copy ABI to clipboard. Or you can also go to compilation details. You can see a ton of information about the compilation details, such as the bytecode with the opcodes, some metadata, the name, but also the API, which tells us the ways we can interact with this contract. If we hit the dropdown for the zero, we see there's an input create simple storage contract, which is one of our functions. And you see state mutability, which we'll talk about later. But if we had another dropdown, we see list of simple storage contracts. And the other dropdown, we'll see SF store. These, as you know, are the buttons that we can press when we deploy this contract, right? So if I redeploy this, we see those exact three buttons. These are the three buttons that were inside of that API. This is how Remix knows to put three buttons here because

It looks at the API and sees that there are three buttons. So, in our code here, our compiler knows what the API is. So, in our code here, the compiler automatically knows what the API is because the compiler is the one that generates the API. And we know where the address is because we have a list of all of our addresses that we're keeping track of up here. So, the reason we have the ABI is because we're importing our simple storage contract. And actually, let's delete this simple storage too. We don't really need the simple storage too. So, when we compile simple storage, we automatically get the ABI for Solidity. In the future, we'll learn other ways to get the API. So, down here, let's get a simple storage contract to interact with from our list. And to do that, we'll say simple storage mySimpleStorage equals list of simple storage contracts at index simple storage index like this. Since this is an array of simple storage contracts, we can just automatically get the contract itself like this. However, let's say that instead of this

being an array of simple storage contracts. This was an array, an array of addresses, a list of simple storage addresses. Like this, you don't have to code along with me for this section. Just go ahead and follow along and watch. If we had a list of addresses, and this would be a little bit different, but we had a list of addresses instead, we could say simple storage, my simple storage equals list of simple storage addresses at the index, and then do something called type casting. And we'd wrap this in parentheses like so. Let me zoom out a little bit. So, this is something we'll learn about a little bit later. So, basically, what we're doing is this list of simple storage addresses, simple storage index. This line returns an address, and we're wrapping that address in simple storage like so. If this is a little confusing for you now, don't worry too much about it. We will learn about it more later. Now that we have our simple storage contract, we can actually call the store function directly on this contract. So, now we can

say my simple storage DOT store and we'll add the new simple storage number. And this is great if we were to deploy this contract right now though and call this SF store function though we wouldn't be able to read the new variable that we just updated our simple storage contract with. So let's create a function that allows us to read from our simple storage contracts as well. So we'll create a function called sfget which will take a un256 underscore simple storage index as an input parameter. We'll make this a public view function that will return a uint256 uint 256 and we'll say simple storage my simple storage equals and we'll use this exact same syntax that we used above to get the simple storage index equals list of simple storage contracts at the simple storage index. And now we're going to do return my simple storage and again if you see these autocompletes that come up you can just hit tab but dot retrieve. So perfect. Now let's go ahead and compile. We'll go ahead and delete the old deploy.

we'll make sure we're on storage factory. We'll hit deploy, and we see storage Factory down here. Now let's go ahead and run through that exact same exercise. So we'll pull up the terminal just to see our transactions go through. We'll hit create simple storage. Let's see that it's actually there at the zeroth index. Okay, cool. We see an address there. So now let's store a new variable at index 0, so at this address. So we'll say at index 0, we'll store the number one two three. And actually, before I hit this button, if we go down here, we hit zero, we get nothing back, right? But now if I hit s of store with index 0, favorite number one two three, looks like the transaction did go through. Now if I hit sfget, we go ahead and get one two three. So our storage Factory contract was able to create its own simple storage contract, store a variable in that contract from the storage Factory, and we were able to read back the number one two three, all from within our

storage Factory contract. Feel free to pause right now and play around with adding different values, creating different simple storage contracts, so that you really understand what's going on. You can also feel free to hit the little drop downs and read more information about these transactions. Just as a recap, in our storage Factory contract, we have a function called create simple storage contract, which creates new simple storage contracts from the storage Factory contract. The reason it's able to do this is because we're importing from our simplestorage.soul file using something called named Imports. We're only importing simple storage; we're not importing anything in these other contracts. Then, we'll use SF store to store a new number on one of those simple storage contracts using the index in our array. You can do this because we have the address and the API, the list of simple storage contracts automatically compact with the address and the API, and then finally, we can read back those simple storage values that we stored. Now, we could make this sfget function even more condensed since this list of simple storage contracts, simple storage.

index returns an object of type simple storage. We can actually delete this whole line, copy this, paste it here, and delete this line, and this will work exactly the same as what we had before. Go ahead and save or compile. You'll go ahead and get that green check mark there. This dot retrieve is saying we're going to call the retrieve function on whatever this is, and this whatever this is is of type simple storage contract. You can actually do the same thing up here by deleting this part, copying this line except for the semicolon, and pasting it over the my simple storage and hitting save or compile. Awesome, great job so far.

Lesson 3 Part 6 | Interacting with a contracts ABI - Solidity & Foundry Full Course

Book a smart contract audit here 👇
https://www.cyfrin.io/


Cyfrin Audits

Managing Multiple Simple Storage Contracts

The current implementation deploys a new simple storage contract each time, without keeping track of the addresses.

To manage this, an array is created to store the list of deployed simple storage contracts.

The storage factory contract successfully creates a simple storage contract, stores a variable, and retrieves the value, demonstrating effective management of multiple contracts.

Interacting with Smart Contracts in Remix

The API for the smart contract can be accessed through the compile tab, where users can copy the ABI or view compilation details.

The API provides buttons for interacting with the contract's functions, such as creating and listing simple storage contracts.

By deploying the contract and using the provided buttons, users can create multiple instances of the simple storage contracts and track their addresses.

Using an Array of Simple Storage Contracts

The tutorial discusses using an array of addresses to manage simple storage contracts.

It explains type casting and how to call the store function directly on a contract.

The storage factory contract creates new simple storage contracts and stores values using the contract's address and index in the array.

Updating and Reading from Simple Storage Contracts

A function called `sfget` is created to read from the simple storage contracts, taking an index as an input parameter.

This public view function returns the updated variable from the specified simple storage contract.

The compiler automatically generates the API and keeps track of the contract addresses, while the ABI is obtained by importing the simple storage contract.

Managing Contracts with a Storage Factory

The index returns a simple storage object, and the code can be simplified by rearranging lines.

The storage Factory contract will manage other contracts and will have a function to call the store function of the deployed simple storage.

To interact with a contract, two key elements are needed: the address and the ABI (application binary interface).