but the thing is, like I was saying, if we just add all of our contracts into the same file, and we have these massive contracts all interweaved between each other, and get very cluttered and very confusing, so is there a better way we can actually arrange and organize our code other than this? And this is actually even a little bit redundant since we already have our simplestorage.sol. If I change something in here, then I would also have to go and change it in here, and that's too much work for me as an engineer. I will work incredibly hard to be incredibly lazy. So instead of doing this, we can use what's called an import. If we go ahead and delete our contract simple storage in our storage Factory here, so that now we just have the storage Factory contract, we can go ahead and use the import keyword to import simple storage.sol. So we can do Imports dot slash simplestorage.sol and a little semicolon here. This import dot slash simplestorage.sol is the exact same as if we had this giant simple storage in

here. So, this import simple storage.sol is a shorthand version of copy-pasting that simple storage.sol into this contract. And now we're able to have simple storage.sol in its own file, and storage Factory just imports it from simple storage, making our lives much easier. It takes our path package or GitHub, which we'll explain in a little bit, and imports and copy-pastes whatever in that file at the top of our file. Literally, Solidity for us is copy-pasting everything in here and sticking it up here so we can go ahead and run this again. Let's compile the old contract. We're on Remix VM. Let's be sure we're on storage Factory. We'll go to storage Factory. We'll deploy it. Scroll down. Click here. Simple storage starts up as nothing. Create simple storage. Oh my God, this look. We deployed a contract. Huzzah! Great work. So now that we're starting to work with different files, there's a number of things we want to consider. The first one is actually the Solidity version. So right now, we're using 0.8.8.

with no carrot and in storage Factor, we're using 0.8.8 with a carrot. If I were to, for example, move the solidity version of this down to 0.8.16 and go to compile this with a different version, remix is actually gonna automatically bump this up to 0.8.19 or actually remix is actually going to automatically bump this up to 0.8.18 if I'm on the simple storage because 0.8.18 is the version that works for simple storage and it still is compatible with storage Factory. However, if I were to take storage Factory and move it to 0.7.6 and try to compile, it's going to try to compile this with 0.7.6 and our simple storage with 0.7.6 and a stock will be able to do it for both, and so we're going to get a compilation error. So, when working with multiple files, it's important to keep the version of solidity in mind because

you want to make sure that all of your contracts can actually compile together. So, this is great and all, but right from the get-go, I want to teach you the more advanced import that you should always use. So, this is good, but we actually never want to default to this. We want to default to something called named Imports. Let's say our simplestorage.soul contract had a ton of other contracts like contract simple storage 2, simple storage 3, simple storage 4, and these were all massive, massive contracts. As we have this right now, import simplestorage.soul would import everything from here: simple storage, simple storage 2, simple storage 3, simple storage 4. And if these files were incredibly big, when we deploy our storage Factory, it would have to calculate all this extra computation, making the deployment of our storage Factory more expensive. If that's confusing to you, don't worry about it right now. Additionally, in the future, these can import from weird places that aren't compatible with storage Factory. Again, that's not going to make sense quite yet, and that's okay, but in any

case there's a way for us to not import this whole file but only a very specific contract or a specific section of our simplestorage.soul. So, instead, what we can do is in our import statement, we can specify the exact contract that we want to import from this file. So, in our simplestorage.sol, let's say we do have these other contracts in here. We could say we only want to import simple storage, not simple storage 2, not simple storage 3, not simple storage 4, by saying import these little brackets here, simple storage from simplestorage.soul. And this goes ahead and compiles correctly. We can also import multiple contracts from our simple storage. For example, we could do import simple storage, simple storage 2 from simplestorage.soul. This way, we only import the exact specific contracts that we want from these other files. And I promise you, in the future, always referring to named imports instead of this type of imports will save you a lot of headache in the future. So, always default to this, never default to this.

Just by learning this, you are already better than 80% of the current Solidity developers, so congratulations. But all right, fantastic. So, we've learned about imports. We're able to import our simple storage from simplestorage.soul. We're importing it in the more advanced way. Congratulations.

Lesson 3 Part 4 | Imports - Solidity & Foundry Full Course

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