All right, great. So we've got a way to actually get this pricing information pretty easily. However, our code is getting a little bit cluttered with these `getPrice` and `getConversionRate`. You'd think that these are functions that would be reused pretty often, anyways, for anybody looking to

work with Chainlink price feeds. So is there an easier way for us to work with this pricing information? Maybe doing some math like this is pretty common and we'd want other contracts to be able to import this conversion functionality. And a way that we can do that is actually

creating something called a library. There's a site out there called Solidity by Example, which has great examples of using libraries and what they work with. Libraries are similar to contracts, but you can't declare any state variables and you can't send Ether. A library is embedded into the contract if all

library functions are internal. Otherwise, the library must be deployed and then linked before the contract is deployed. That's a little bit confusing. Don't worry too much about that right now. Using libraries can actually add functionality to different values. And what do I mean by that? Well, I mean we

can have our `getConversionRate` function be a function of any value of type `uint`. This means we could take this `getConversionRate` and do something like `msg.value.getConversionRate`. So we can create our own custom function with any type. We could

work with `getConversionRate` as if `msg.value` was a class or an object or contract that we actually created to do this. Let's go back to our files, create a new one, create a new one called `PriceConverter.sol`, and this is going to be a library, a `PriceConverter`.

Library, so how do we create a library and what is a library? Well, a library is going to be very similar to a contract. We're going to start, of course, with SPDX license identifier. We're going to do pragma solidity and we'll give it a

version of 0.8.18, the little carrot, and instead of typing contract, we're actually going to type library for the name of the library, and we're going to call this LibraryPriceConverter. So, libraries can't have any state variables, and all the functions have to be marked

internal. So, what we're going to do is we're going to go back to FundMe.sol and zoom out a little bit. We're going to grab getPrice, getConversionRate, and getVersion, delete them. Well, I hit copy first, go back to PriceConverter,

paste them in here and work with them in here. Of course, we're going to need the AggregatorV3 interface. So, we're going to go back to our FundMe, we're going to copy this named import from AggregatorV3 interface, paste it in at the top here,

hit command s, and we're going to go ahead and compile this successfully. FundMe is no longer going to compile, but we're going to fix that in a little bit. Now, the first thing that we're going to need to do in here is make these all

internal. So, we're going to say internal, this, we do internal getConversionRate, and internal getVersion. Now that we have our PriceConverter Library, we can actually import it back in our FundMe and attach it to a uint256. And let's actually delete this AggregatorV3

interface line for now, and we'll do import price converter from dot slash priceconverter. That's all. And now to attach the functions in our price converter library to all u256s, we'll say using price converter or you went 256. Of course, if we compile our fund me

we're gonna get an issue because it doesn't really know what get conversion rate is. So, for now, let's actually just comment out this line. I'm going to remove these comments up here as well. So, what we can do now though is we can do

message.value dot get conversion rate. Hit conversion rate, and in your library, whenever you're working with a library, the first input variable for a library is going to be the type that you're using with the library. So, message.value is of type u256, so this gets passed

inside of get conversion rate as the first variable into u256. Eat them out, even though we don't pass any variables inside of these parentheses here or get price and get version, we don't really care to have an input parameter at all, so it'll pass it

in but not do anything. So, now instead of require get conversion rate of message.value, we can actually do let's uncomment this line now, and let's delete this line. We can actually do message.value dot get conversion rate, conversion rate, and now if we compile

this, this is going to compile successfully. This works because we're attaching the price converter library to all you want 256s. So, now all you and 256s have access to this get conversion rate function, and since message.value is a u256, it can call dot get conversion

rate and it'll pass itself so that message.value is the first input parameter to the function here. If we wanted another variable in here like you know six something else, that would be the first parameter inside these parentheses. So maybe like one two three or something right? This one two three

would be the something else, but message.value would still be the initial parameter which in this example would be Ethan out. So let's go ahead and undo that and undo that, but all right, great. We've moved a lot of the math into our own library. Congratulations, nice work.

Lesson 4 Part 14 | Libraries - Solidity & Foundry Full Course

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


Cyfrin Audits

Code is cluttered with `getPrice` and `getConversionRate` functions.

Reusability of pricing information functions is desired.

Libraries are introduced as a solution, similar to contracts but without state variables or Ether sending capabilities.

Libraries add functionality to different value types, enabling custom functions.

A new file `PriceConverter.sol` is created for the library.

Library structure is similar to a contract, using `library` instead of `contract`.

Libraries cannot have state variables; functions must be marked `internal`.

`getPrice`, `getConversionRate`, and `getVersion` functions are moved from `FundMe.sol` to `PriceConverter.sol`.

The `AggregatorV3Interface` is imported into `PriceConverter.sol`.

Functions in `PriceConverter.sol` are marked `internal`.

`PriceConverter` library is imported into `FundMe.sol`.

Library functions are attached to `uint256` using `using PriceConverter for uint256`.

The first parameter in library functions is the type it's used with (e.g., `msg.value` for `uint256`).

`msg.value.getConversionRate` is used to call the library function.

Compilation is successful after attaching the library.

Additional parameters can be added to library functions.

Math functions are successfully moved into the library.

Lesson 4 Part 14 | Libraries - Solidity & Foundry Full Course

Lesson 4 Part 14 | Libraries - Solidity & Foundry Full Course

Scripts