A comprehensive, hands-on learning track that helps you master Fuel Network's mechanisms and architecture.

Build on Modular Blockchains with Fuel Network

If you’re a developer looking to add Fuel Blockchain to your skillset, this is the place to start. This course will teach you to code an impactful dApp in the Fuel blockchain. The course will begin with an introduction to the Fuel blockchain, its features and its use cases. Later on, you will will dive into the Sway programming language and develop a petition dApp using with the programming language.

# What Are We Building Today?

GM everyone ☀️, today we are very excited to bring a super exciting course on Fuel blockchain for developers on Metaschool.

So, what are we building? Believe it or not, we will build a petitions dApp using the Sway programming language on the Fuel blockchain. And this will serve as a huge learning step for you all. So let’s give it our all to this!!

Fuel is an L2 blockchain that aims to provide low cost for transactions at a high speed. Fuel believes that modular blockchains are the future. It offers separate execution from consensus and availability of data–which increases the bandwidth capacity significantly. Fuel is supported by Blockchain Capital, Stratos, CoinFund, Spartan, and many more.

## Course overview

We will:

1. Develop an understanding of the Fuel blockchain
2. Set up the development environment
3. Understand Sway basics
4. Build petitions dApp
5. Create front-end of the dApp

## Who exactly should take this course?

This course is for beginner web3 developers who wish to learn about Fuel blockchain. You should have basic programming knowledge as it will help you have a quick start to this course. 

## What you will be getting out of this course?

As a developer, you will be getting the following outcomes when you complete this course:

1. Understand how Fuel is different from other blockchain
2. Learn why you should choose Fuel for your next dApp
3. Earn up to 1000 XPs

## Proof of completion

If you complete this course with me, you will be getting XPs and a special NFT which will unlock many more opportunities for you on the Metaschool platform. Here is what the NFT looks like.

![ezgif.com-optimize (3).gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/course%20NFT.gif?raw=true)

Now before we move forward, let’s set some house rules first.
1. Kindly do your quick assignments properly.
2. Join [our discord server](https://discord.gg/vbVMUwXWgc) and ask all relevant questions there.
3. We are a free open-source platform and if you follow us on [X](https://bit.ly/petition-dapp-fuel-twitter) and [LinkedIn](https://bit.ly/petition-dapp-fuel-linkedin), it would be a great support.  🫣
4. Stay happy and positive!

Alright guys, no need to wait any longer, let's dive right into our awesome Fuel Blockchain course! Let's do this! 🙌


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/1.%20Getting%20Started/1.%20What%20Are%20We%20Building%20Today.md

What Are We Building Today?

# Introduction to Fuel and Sway

Alright, so we are all set to start our journey. So first things first, we will first understand a little about Fuel and then about its programming language, Sway. Let’s not wait for more and start!

## What is Fuel Blockchain?

Fuel v1 is an L2 scalability solution and optimistic rollup for monolithic Ethereum. 

As we know, blockchains are evolving from a consolidated design, where consensus, data availability, and execution are closely linked. The trend is shifting towards a modular approach, where execution is distinct from data availability and consensus, as seen in upcoming systems like Celestia. This separation enables specialization at the foundational level, resulting in a substantial boost in bandwidth capacity. At Fuel, the focus is on constructing the most rapid execution layer for this modular blockchain framework.

In short Modular blockchains are like lego bricks, the possibility is endless with a modular architecture like Fuel, you can pick the best bricks and place one on top of other to create a blockchain architecture you had in your mind.

## What so special about Fuel’s modular execution layer?

Fuel is like a powerful layer that makes blockchain technology work faster and handle more data. This layer helps blockchain quickly process data while keeping things secure. It's not just for basic tasks; it can also handle complex actions like those Ethereum-style smart contracts

In simple words, think of Fuel as a special engine that you put inside a blockchain system to make it work better and more efficiently. It's much better than older systems that can't handle a lot of information like Ethereum, the gas goes skyrockets when the Ethereum bottlenecks. As the blockchain is evolving, modular blockchain will be the future because its like having the best of every world in to one and Fuel is be a crucial part of the future as Fuel is the fastest execution layer for any modular blockchain out there.

## 3 pillars of Fuel blockchain

Fuel's technology stack rests on three key pillars:

1. **Parallel Transaction Execution**
    1. Fuel achieves unparalleled processing capacity by executing transactions in parallel. Fuel efficiently utilizes multiple threads and CPU cores, delivering significantly higher compute power, state accesses, and transactional throughput compared to single-threaded blockchains.
    2. *Example:* Consider a decentralized exchange (DEX) running on Fuel. In a traditional single-threaded blockchain, transaction processing might occur sequentially, limiting throughput. With Fuel's parallel execution, multiple trades can be processed simultaneously. This means that while one trade is being settled, others can progress concurrently, optimizing the use of available CPU resources and significantly enhancing the DEX's transactional capacity.
    
2. **Fuel Virtual Machine (FuelVM)**
    1. The FuelVM minimizes wasteful processing found in traditional blockchain virtual machine architectures. By learning from past mistakes and drawing insights from years of production blockchains, it expands the potential design space for developers, surpassing the constraints of the EVM (Ethereum Virtual Machine).
    2. *Example:* Imagine a decentralized application (DApp) handling complex computations, such as a decentralized finance (DeFi) protocol running on Fuel. Traditional virtual machines may struggle with the intricate calculations involved. However, FuelVM's optimized design reduces wasteful processing, enabling the DeFi protocol to execute complex smart contracts more efficiently. This efficiency translates to faster transaction confirmations and improved overall performance compared to using a standard virtual machine.
3. **Superior Developer Experience (Sway and Forc)**
    1. Fuel prioritizes a robust and user-friendly developer experience. Introducing its domain-specific language, Sway, and a supportive toolchain known as Forc (the Fuel Orchestrator), Fuel offers a powerful development environment. This environment retains the advantages of languages like Solidity while incorporating the Rust tooling ecosystem's innovative paradigms. With Fuel, developers can seamlessly integrate every component, from the virtual machine to the command-line interface (CLI), for a fully cohesive experience.
    2. *Example:* Suppose developers are creating a decentralized gaming platform on Fuel. With Sway, Fuel's domain-specific language, developers can express gaming logic more intuitively and concisely compared to generic languages. Forc, the supportive toolchain, streamlines the development process by automating tasks like deployment and testing. This means developers can focus more on designing innovative gaming features and less on managing technical intricacies, resulting in a smoother and more enjoyable development experience.

## Sway programming language

Sway is a domain-specific language for the Fuel Virtual Machine, which is optimized for the Fuel blockchain. It draws inspiration from Rust and aims to bring modern language development and superior performance to the blockchain ecosystem.

## Wrap up

To summarize, Fuel and Sway offer a groundbreaking solution for blockchain scalability and development. With parallel transaction execution, an optimized Fuel Virtual Machine, and the user-friendly Sway language, they empower developers to create efficient and intuitive decentralized applications. Fuel and Sway are driving the evolution of a more scalable and user-friendly blockchain ecosystem.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/1.%20Getting%20Started/2.%20Introduction%20to%20Fuel%20and%20Sway.md

Introduction to Fuel and Sway

# Set Up the Fuel Toolchain

We are so proud of you for choosing to upskill by continuing this course. In this lesson, you will learn how to set up your system with a Fuel chain to run the Sway programs.

## Prerequisite installations

Before installing the Fuel toolchain, we need to make sure that our system is ready to go. So let’s do that first. Feel free to scroll through the lesson to install the packages for your specific OS.

### MacOS

Let's ensure your MacOS is ready. Open the terminal and run these commands.

1. Install `brew` using the following command:

```
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```

2. Install `curl` using the following command:

```
brew install curl
```

3. Install `git` using the following command:

```
brew install git
```

> You are done with prerequisite installations for Mac, you can go to [Setup the development environment](https://github.com/0xmetaschool/Learning-Projects/blob/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/2.%20Setting%20Up%20the%20Dev%20Environment/1.%20Setup%20Fuel%20Toolchain.md#setup-the-development-environment) now.

### Linux

If you have a Linux OS system, run the following commands to set up your system.

1. Update `apt-get` using the following command:

```
sudo apt-get update
```

2. Install `cURL` using the following command:
    
 ```
sudo apt install curl
```
    
3. Install `git` CLI:
    
```
sudo apt-get install git-all
```

4. Install `libssl-dev`:

```
sudo apt-get install libssl-dev
```

5. Install `libclang-dev`:
    
```
sudo apt-get install libclang-dev
```
    
6. Install `libpq-dev`:
    
```
sudo apt-get install libpq-dev
```
    
7. Install `build-essential`:
    
```
sudo apt-get install build-essential
```

> You are done with prerequisites installations for Linux, you can go to [Setup the development environment](https://metaschool.so/courses/building-petition-dapp-fuel/lesson/c0d579ff-c6e6-414c-a3ba-9214e75b7336?learningPath=#setup-the-development-environment) now.


### Windows

Let's review the prerequisites needed to install Fuel on Windows.

For Windows, you should install [WSL](https://learn.microsoft.com/en-us/windows/wsl/install). Currently Fuel doesn't natively support Windows so you will need a Linux subsystem like WSL


Now, follow the following instructions to install the Rust and Fuel toolchain in your system. Open the terminal in your system and run the following commands.

1. First of all, we need to install the Rust in your system. The Fuel blockchain is built on top of the Rust programming language. To install Rust, run the following command in your system.

```
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
```

You might get the following error message after executing the command:
```
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012)
- The revocation function was unable to check revocation for the certificate.
```
It indicates that cURL was unable to check revocation for the certificate (which is the default behavior when it comes to communication with secure websites). The error usually occurs when you 
are using an anti-virus or equivalent software that offers its own certificate. The quickest solution would be to disable your anti-virus temporarily, run the cURL command once more, and then enable it again.

2. Run the following command to check the version of Rust installed in your system.

```
rustup --version
```

3. To install the Fuel toolchain, you need to install the `fuelup-init` script. If the command asks you to modify the path, press `y` and “Enter” to modify the path.

```
curl --proto '=https' --tlsv1.2 -sSf https://install.fuel.network/fuelup-init.sh | sh
```

4. Run the following command to check if the installation process was a success.

```
fuelup --version
```

5. Make sure your toolchain is up-to-date. 

```
fuelup self update
```

6. Run the following command to install the `beta-5` toolchain.

```
fuelup toolchain install beta-5
```

7. Set `beta-5` as your default toolchain with the following command:

```
fuelup default beta-5
```

8. Run the following command to view the list of toolchains and versions of the tools you are using.

```
fuelup show
```

## That’s a wrap

Without further ado, in the next section, we will move on to learn the basics of Sway programming language. So, let’s go!


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/2.%20Setting%20Up%20the%20Dev%20Environment/1.%20Setup%20Fuel%20Toolchain.md

Set Up the Fuel Toolchain

# Sway Basics

Welcome back! Great work on setting up your development environment and making your system ready to go for coding on Sway and Fuel. We know you want to dive straight into coding, but before that let's just take a pause and learn what actually is Sway. Get introduced to Sway and explore it in detail in this lesson.

## What is Sway?

Sway is a domain-specific language (DSL) that is designed for the Fuel Virtual Machine (FuelVM). Similar to how the Ethereum Virtual Machine is designed for the Ethereum blockchain, the FuelVM is a VM designed for the Fuel Blockchain. Sway is based on the Rust programming language. 

Well, enough of an overview now, let’s get straight into the basics of Sway. 

## Variables

In Sway, once you declare the variable, it cannot be changed. In other words, variables in Sway are immutable by default. Also, the variables are assigned u64 or 64-bit unsigned integer type by default. This is to ensure that Sway is a safe programming language.

### Declaring variables

Say you have a variable `num`

```
let num = 10;
```

As mentioned before, we can easily tell that `num` is immutable and also that `num` is assigned `u64`

Now, if we want to change the default setting from immutable to mutable then we need to do: 

```
let mut num = 10;
num = 12
```

Using `mut` allows you to make your variable mutable and you would now be able to reassign it to another value. 

### Type Annotations

Type Annotations are used to declare the type of variables. For example, unsigned integer type,  string, bool, etc. 

For example, 

```
let bar: str[4] = __to_str_array("sway");
let baz: bool = true;
```

We can also change the default `u64` so

```
let num: u32 = 5;
```

## Built-in Types in Sway

Sway is a statically typed language which means at the compile time, the types of every value must be known.

### Primitive Types

Sway has below primitive types. All other types can be built from these primitive types. You will notice that there are no signed integers below. This could be done in Sway using other libraries. 

1. `u8` (8-bit unsigned integer)
2. `u16` (16-bit unsigned integer)
3. `u32` (32-bit unsigned integer)
4. `u64` (64-bit unsigned integer)
5. `u256` (256-bit unsigned integer)
6. `str[]` (fixed-length string)
7. `str` (string slices)
8. `bool` (Boolean `true` or `false`)
9. `b256` (256 bits (32 bytes), i.e. a hash)

### Boolean Type

Like any other programming language, `bool` type has 2 values - `true` and `false`. 

If you want to negate the bool, say change the value from true to false or false to true, which might be required in conditional statements, you can use the `negation operator` `!`

```
fn returns_false() -> bool {
	let boolean_value: bool = true;
	!boolean_value
}
```

Above is an example of a function that makes the bool value false if it's true. 

### String Slices

- Strings in Sway are stored as variable-length string slices and are essentially a pointer to the actual string data and its length.
- They can't be used in certain scenarios, like constants, storages, configurables, main function arguments, or returns.
- For those cases, you should use string arrays.

```
let my_string: str = "fuel";
```

### String Arrays

- Static-length strings in Sway are a primitive type, where the size is part of the type.
- String arrays are written with square brackets denoting the size.
- You can convert string literals to string arrays at compile time using `__to_str_array`.
- Runtime conversion can be done with `from_str_array` and `try_as_str_array`.

```
let my_string: str[4] = __to_str_array("fuel");
```

### Tuple Types

- Tuples are static-length aggregations of types.
- You declare a tuple with parenthesized, comma-separated values.
- You access tuple values using indexing, starting from 0.
- Tuples can also be restructured.

```
let x: (u64, u64) = (0, 0);
```

### Arrays

- Arrays are similar to tuples but all values must be of the same type.
- They are written as comma-separated values inside square brackets.
- Arrays have a static size and are allocated on the stack.
- Array elements can be mutated if the array is declared as mutable.

Below is an example of an array: 

```
let x = [1, 2, 3, 4, 5];
```

## Functions

- Functions in Sway are declared using the `fn` keyword.
- Parameters are specified within parentheses after the function name.
- The arrow `>` indicates the return type.

Let’s look at the following example

```
fn equals(first_param: u64, second_param: u64) -> bool {
    first_param == second_param
}
```

Inputting arguments in the above functions would return this:

```
fn main() {
    equals(5, 5); // true
    equals(5, 6); // false
}

```

### Mutable Parameters

- Make a parameter mutable by adding `ref mut` before its name.
- Allows the function to modify the argument passed to it.

Below is an example

```
fn increment(ref mut num: u32) {
    let prev = *num;
    *num = prev + 1u32;
}

```

Now, let’s use this function

```
let mut num: u32 = 0;
increment(&mut num);
assert(num == 1u32); // Function modifies `num`

```

### Complex Types

- `ref mut` can be used with complex data types.

Let’s look at an example

```
fn swap_tuple(ref mut pair: (u64, u64)) {
    let temp = pair.0;
    pair.0 = pair.1;
    pair.1 = temp;
}

fn update_color(ref mut color: Color, new_color: Color) {
    *color = new_color;
}
```

Let’s implement the function now

```
let mut tuple = (42, 24);
swap_tuple(&mut tuple);
assert(tuple.0 == 24); // Function modifies `tuple.0`
assert(tuple.1 == 42); // Function modifies `tuple.1`

let mut color = Color::Red;
update_color(&mut color, Color::Blue);
assert(color == Color::Blue); // Function modifies color to Blue
```

## That’s a wrap

In this lesson, we learned about the basics of Sway, don’t you think Sway is such an expressive language? Well let’s move forward and get our hands dirty by coding a end to end petition dApp on Fuel using Sway.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/3.%20Sway%20and%20It%E2%80%99s%20Basics/1.%20Sway%20Basics.md

Sway Basics

# Set Up the Sway Project

Welcome back! We’re so proud of you for completing the basics of the Sway programming language. Now without any delay, we will create a Sway project and understand how it works.

## Set up your first Sway project

Let’s start by building the basic Sway project. This project we will use to build our first Petition dApp on Fuel. Open the terminal in your system and start following the instructions to set up your project.

1. Start by creating a new and empty folder. Let’s call it `petition-app`. You can call it whatever you want to.

```
mkdir petition-app
```

2. Move inside of the folder, we just created.

```
cd petition-app
```

3. Create the fuel project using the following command.

```
forc new petition-contract
```

After executing the command, you can expect to receive the output mentioned below. 

```
To compile, use `forc build`, and to run tests use `forc test`

----

Read the Docs:
- Sway Book: https://docs.fuel.network/docs/sway
- Forc Book: https://docs.fuel.network/docs/forc
- Rust SDK Book: https://docs.fuel.network/docs/fuels-rs
- TypeScript SDK: https://docs.fuel.network/docs/fuels-ts

Join the Community:
- Follow us @SwayLang: https://twitter.com/SwayLang
- Ask questions on Discourse: https://forum.fuel.network/

Report Bugs:
- Sway Issues: https://github.com/FuelLabs/sway/issues/new
```

## Project structure

Now, open the project folder, `petition-app` in the VS code. Here’s what the project structure will look like.

![fuel-project-strcuture.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Set%20Up%20the%20Sway%20Project/fuel-project-strcuture.png?raw=true)

### `Forc.toml` file

`Forc.toml` is a manifest file, the same as the `Cargo.toml` file. It defines the metadata of the project such as the project name and dependencies. Let’s look at what it looks like by default.

```
[project]
authors = ["Author Name"]
entry = "main.sw"
license = "Apache-2.0"
name = "petition-contract"

[dependencies]
```

You can also edit the `Forc.toml` file, to make it work best for you. For our `petition-contract`, we need a `toolchain` and `forc` and `fuel-core` components (Fuel SDK dependencies). So, let’s update our `Forc.toml` file.

```
[project]
authors = ["Author Name"]
entry = "main.sw"
license = "Apache-2.0"
name = "petition-contract"

[toolchain]
channel = "latest-2023-07-18"

[components]
forc = "0.46.1"
fuel-core = "0.20.5"
```

### Setup the project

Open the `src/main.sw` file and delete any existing code apart from the first line. It is important to start every Sway file with a declaration of its program type. So, in `main.sw` file, we are defining that our file will be a contract using the following line.

```
contract;
```

Let’s create a new folder inside of the `src` folder. 

```
cd petition-contract
cd src
mkdir data_structures
```

The updated project structure will look like this.

![fuel-project-strcuture-1.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Set%20Up%20the%20Sway%20Project/fuel-project-strcuture-1.png?raw=true)

We will use the `data_structures` folder to create different components of our `petition-contract` such as creating a campaign, tracking the campaign, and representing the current state of the campaign to the user and keeping track of the number of signs on one campaign.

## That’s a wrap

Great work on setting up your first project on Fuel blockchain. We will use this project to create our petition dApp. 

We need to write different components to make our petition dApp stand out. So, we will not only write code in the `main.sw` file, but write code in multiple files and build different components of our petition dApp.

In the next lesson, we will start with writing the code for different components inside of the `data_structures` folder. So, get ready for some exciting work!

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/4.%20Writing%20Your%20Smart%20Contract/1.%20Set%20Up%20the%20Sway%20Project.md

Set Up the Sway Project

# Let’s Add the States and Interfaces

I’m so proud of you for coming this far in the course. In this lesson, we will start building our petition dApp. During our last lesson, we discussed the need to incorporate various components into our petition dApp. These components are what will be called interfaces. 

## Adding interfaces to our petition dApp

The contract in Sway is callable and stateful. It is deployed to the blockchain via transaction. Think of a smart contract as a deployed API that comes with a database state. In Sway, each file is defined by a program type, followed by the import of an ABI. So, before moving on to writing our contract, `main.sw`. We will write four different ABIs that we will eventually use in our smart contract. These ABIs are like libraries that will perform different tasks and help us keep records of the different information. 

![fuel-note.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces/fuel-note.png?raw=true)

We will start by adding the interfaces (ABI) to the `data_structures` folder. Let’s look at what they will be.

1. Campaign creation ABI - Keeps record of the information of a campaign
2. Campaign track ABI - Keeps track of the campaign one user has created
3. Campaign State ABI - Keeps record of the state of a campaign
4. Number of signs ABI - Keeps track of the number of signs on one campaign

Let’s start implementing them one by one and understand the code side by side.

## Creating the campaign state library

First of all, we will begin with implementing the state library. We need a state library because it will help us keep a record of whether the campaign is currently going on, in progress, or has been canceled. We will implement state before implementing campaign information because we will use the state library in campaign information. We want to save the state of the campaign in the campaign information as well.

Create a `campaign_state.sw` file inside of the `src/data_structures` folder. Here’s what the new project structure will look like.

![fuel-structure-3.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces/fuel-structure-3.png?raw=true)

Let’s start coding. We will write and explain the code line by line for you to understand everything in detail.

### Add `library` keyword

```
library;
```

In Sway, the file defined with a `library` keyword defines a new common behavior. The best example of this is the [Sway standard library](https://github.com/FuelLabs/sway/tree/master/sway-lib-std). Libraries are defined using the `library` keyword, as we did here.

### Import libraries

```
use core::ops::Eq;
```

Followed by a `library` keyword comes the imports. Immediately after defining our file, we must import the existing libraries we need to build our own library. In this case, we are importing `ops::Eq` from the `core` library.

### Create a public enum

```
/// Represents the current state of the campaign.
pub enum CampaignState {
    /// The campaign has been canceled.
    pub Cancelled: (),
    /// The campaign was successful
    pub Successful: (),
    /// The campaign is still accepting funds.
    pub Progress: (),
}
```

First, we are defining the `CampaignState` enum that will help us keep track of the campaign state. It has three data fields, which we will use to store the state information.

1. `Cancelled`
2. `Successful`
3. `Progress`

### Create `CampaignState` ABI

```
impl Eq for CampaignState {
    fn eq(self, other: CampaignState) -> bool {
        match (self, other) {
            (CampaignState::Cancelled, CampaignState::Cancelled) => true,
            (CampaignState::Sucessful, CampaignState::Sucessful) => true,
            (CampaignState::Progress, CampaignState::Progress) => true,
            _ => false,
        }
    }
}
```

`impl` is used to implement the ABI library, `CampaignState`. The eq function allows us to take the CampaignState as an input, and check whether any of the data fields is equal to true, otherwise, it returns `false`.

### Complete code
You can find the complete code of `campaign_state.sw` file [here](https://github.com/0xmetaschool/petition-contract/blob/main/src/data_structures/campaign_state.sw).

## Creating a campaign information library

We need a campaign library for our petition dApp because it will help us keep a record of any campaign a user wants. As there can be multiple campaigns running at a time, it is important to keep a record of each campaign. So, let’s start making a library that will keep a detailed record of the campaign information on the Fuel blockchain. 

Create a `campaign_info.sw` file inside of the `src/data_structures` folder. Here’s what the new project structure will look like.

![fuel-structure-4.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces/fuel-structure-4.png?raw=true)

Let’s start coding. We will write and explain the code line by line for you to understand everything in detail.

### Add `library` keyword

```
library;
```

As we have discussed before that we need to define the program type of each file in Sway. We are defining our ABI with a `library` keyword.

### Import libraries

```
use ::data_structures::campaign_state::CampaignState;
```

As we have mentioned before, we must import the existing libraries we need to build our own library. Here, we are importing the `CampaignState` from the `data_structures/campaign_state.sw` file that will help us build our own data structure for the campaign.

### Create a new data structure

```
// General data structure containing information about a campaign.
pub struct CampaignInfo {
    /// The user who has created the campaign.
    pub author: Identity,
    // Whether the campaign is currently: in progress, successful, or Canceled.
    pub state: CampaignState,
    /// The end time for the campaign after which it becomes locked.
    pub deadline: u64,
    /// Total amount of signs received
    pub total_signs: u64,
}
```

We created a new data structure using the `struct` keyword. This struct defined the number of variables, we want to use to save the data details for our campaign. `pub` defines that the `struct` is accessible to the public. Let's see what the variables will be used.

**`author: Identity`**

We are defining an `author` of type `Identity`, which we will use to save the information of the author who created the campaign. `Identity` is an enum that allows handling both `address` and `ContractId` types. Identity comes in handy when we don’t know the exact type of data we will get. It can be addressed or the contract. An `Identity` is implemented as follows.

```
pub enum Identity {
    Address: Address,
    ContractId: ContractId,
}
```

**`state: CampaignState`**

The `state` is an instance of the `CampaignState` enum. We will use this instance to keep track of the campaign's state. It will allow us to know whether the campaign is still in progress, successful, or canceled.

**`deadline: u64`**

The `deadline` is `u64` type variable defining when to end the campaign. It helps automatically end the campaign without any external push. 

**`total_signs: u64`**

The `total_signs` is a `u64`-type variable that helps keep a record of the total number of signs who signed the campaign.

### Create `CampaignInfo` ABI

```
impl CampaignInfo {
    /// Creates a new campaign.
    ///
    /// # Arguments
    ///
    /// * `asset`: [ContractId] - The asset that this campaign accepts as a deposit.
    /// * `author`: [Identity] - The user who has created the campaign.
    /// * `deadline`: [u64] - The end time for the campaign after which it becomes locked.
    ///
    /// # Returns
    ///
    /// * [CampaignInfo] - The newly created campaign.
    pub fn new(
        author: Identity,
        deadline: u64,
    ) -> Self {
        Self {
            author,
            state: CampaignState::Progress,
            deadline,
            total_signs: 0,
        }
    }
}
```

`impl` is used to implement the ABI library. Here, we are implementing `CampaignInfo` ABI which is being used to create an instance of the `CampaignInfo` struct. `impl CampaignInfo` creates a new campaign, takes data as input, and saves it in the data fields. Let’s divide the code further and understand it in a bit more detail. 

**`pub fn new(author: Identity, deadline: u64) -> Self {}`**

Inside the `impl CampaignInfo`, we are defining a public function that takes two inputs, `author` and `deadline` of type `Identity` and `u64`, respectively. We will use these two inputs to fill the data fields. The function returns `Self` meaning it is returning the instance of itself.

**`Self { author, state: CampaignState::Progress, deadline, total_signs: 0, }`**

This line uses the input parameters and creates a new instance of the `CampaignInfo` ABI.


### Complete code
You can find the complete code of `campaign_info.sw` file [here](https://github.com/0xmetaschool/petition-contract/blob/main/src/data_structures/campaign_info.sw).


## Create a campaign library

We need a library that will store the information of what campaigns a user is creating. One use might create two or more campaigns. So, we need to keep track of the campaign on a user basis. Here’s where the `Campaign` library comes in.

Create a `campaign.sw` file inside of the `src/data_structures` folder. Here’s what the new project structure will look like.

![fuel-structure-5.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces/fuel-structure-5.png?raw=true)

Let’s start coding. We will write and explain the code line by line for you to understand everything in detail.

### Add `library` keyword

```
library;
```

As we have discussed before that we need to define the program type of each file in Sway. We are defining our ABI with a `library` keyword.

### Create a public data structure

```
/// Used to track the campaigns that a user has created.
pub struct Campaign {
    /// The unique identifier for the campaign.
    pub id: u64,
}
```

Here, we are defining a public `struct`, `Campaign`, which stores the user `id` in a `u64`-type data field.

### Create `Campaign` ABI

```
impl Campaign {
    /// Creates a new campaign.
    ///
    /// # Arguments
    ///
    /// * `id`: [u64] - The unique identifier for the campaign.
    pub fn new(id: u64) -> Self {
        Self { id }
    }
}
```

Here, we are simply defining the constructor function for the `Campaign` struct.

### Complete code
You can find the complete code of `campaign.sw` file [here](https://github.com/0xmetaschool/petition-contract/blob/main/src/data_structures/campaign.sw).


## Create sign library

Create `signs.sw` file inside of the `src/data_structures` folder. Here’s what the new project structure will look like.

![fuel-structure-6.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces/fuel-structure-6.png?raw=true)

Let’s start coding. We will write and explain the code line by line for you to understand everything in detail.

### Add `library` keyword

```
library;
```

As we have discussed before that we need to define the program type of each file in Sway. We are defining our ABI with a `library` keyword.

### Create `Signs` struct

```
/// Used to track the amount signed by a user to a specific campaign.
pub struct Signs {
    /// Signing to a campaign; it should be always 1
    pub sign: u8,
    /// The unique identifier for the campaign.
    pub campaign_id: u64,
}
```

Here, we are defining a public `struct`, `Signs`, which stores the user ID in a `u64`-type data field.

### Create `Signs` ABI

```
impl Signs {
    /// Creates a new sign.
    ///
    /// # Arguments
    ///
    /// * `campaign_id`: [u64] - The unique identifier for the campaign.
    ///
    /// # Returns
    ///
    /// * [sign] - The new sign.
    pub fn new(campaign_id: u64) -> Self {
        Self {
            sign: 1,
            campaign_id,
        }
    }
}
```

We are creating the ABI, `Signs`, using `impl` keyword. It contains a constructor function that takes the campaign ID and initializes the initial state of the `Signs` `struct`.

### Complete code
You can find the complete code of `signs.sw` file [here](https://github.com/0xmetaschool/petition-contract/blob/main/src/data_structures/signs.sw).

## Create data structures file

We’re done with creating the interfaces. Now, we need a file outside of the `data_strcutures` folder that can help us import all interface libraries easily using one library.

Create `data_structures.sw` file inside of the `src` folder. Here’s what the new project structure will look like.

![fuel-structure-7.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces/fuel-structure-7.png?raw=true)

The following code will be added to the `data_structures.sw` file.

```
library;

pub mod campaign_state;
pub mod campaign_info;
pub mod campaign;
pub mod signs;
```

After defining the file program type using the `library` keyword, we import all of the interfaces into on file. Later, we can use this file to import all of the extended libraries.

### Complete code
You can find the complete code of `data_structures.sw` file [here](https://github.com/0xmetaschool/petition-contract/blob/main/src/data_structures.sw).


## That’s a wrap

Great work on completing the 1st milestone of building your petition dApp. Next, we will implement the events and interface libraries.


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/4.%20Writing%20Your%20Smart%20Contract/2.%20Let%E2%80%99s%20Add%20the%20States%20and%20Interfaces.md

Let’s Add the States and Interfaces

# Let’s Add the Events and Interfaces

I’m so proud of you for setting up the initial interfaces for your petition dApp. Let’s move forward and add more libraries to our petition dApp.

## Adding events

We will define small events for our petition dApp. Whenever a particular activity is completed, we emit these events. Create a file named `events.sw` in the `petition-contract/src` folder and add the following code to it:

```
library;

use ::data_structures::campaign_info::CampaignInfo;

pub struct CancelledCampaignEvent {
    pub campaign_id: u64,
}

pub struct SuccessfulCampaignEvent {
    pub campaign_id: u64,
    pub total_signs: u64,
}

pub struct CreatedCampaignEvent {
    pub author: Identity,
    pub campaign_info: CampaignInfo,
    pub campaign_id: u64,
}

pub struct SignedEvent {
    pub campaign_id: u64,
    pub user: Identity,
}

pub struct UnsignedEvent {
    pub campaign_id: u64,
    pub user: Identity,
}
```

This code defines a library that includes several structures representing events related to campaigns.

### Explanation

Let's break down the components:

```
library;
use ::data_structures::campaign_info::CampaignInfo;
```

- The code starts with the declaration of a `library`.
- It then imports the `CampaignInfo` struct from the `data_structures` module, indicating that these events may involve campaign information.

```
pub struct CancelledCampaignEvent {
    pub campaign_id: u64,
}
```

- `CancelledCampaignEvent`: A struct represents an event when a campaign is canceled.
- It has a single field `campaign_id` of type `u64`, representing the unique identifier for the campaign.

```
pub struct SuccessfulCampaignEvent {
    pub campaign_id: u64,
    pub total_signs: u64,
}
```

- `SuccessfulCampaignEvent`: A struct representing an event when the proceeds of a campaign are claimed.
- It has two fields:
    - `campaign_id`: The unique identifier for the campaign.
    - `total_signs`: The total number of signs received by the campaign.

```
pub struct CreatedCampaignEvent {
    pub author: Identity,
    pub campaign_info: CampaignInfo,
    pub campaign_id: u64,
}
```

- `CreatedCampaignEvent`: A struct representing an event when a campaign is created.
- It has three fields:
    - `author`: The user who has created the campaign.
    - `campaign_info`: Information about the entire campaign (of type `CampaignInfo`).
    - `campaign_id`: The unique identifier for the campaign.

```
pub struct SignedEvent {
    pub campaign_id: u64,
    pub user: Identity,
}
```

- `SignedEvent`: A `struct` representing an event when a person signs a campaign.
- It has two fields:
    - `campaign_id`: The unique identifier for the campaign.
    - `user`: The user who has pledged.

```
pub struct UnsignedEvent {
    pub campaign_id: u64,
    pub user: Identity,
}
```

- `UnsignedEvent`: A struct representing an event when a signature is withdrawn from a campaign.
- It has two fields:
    - `campaign_id`: The unique identifier for the campaign.
    - `user`: The user who has unpledged.

These `struct`s define the structure of events that can occur within the context of a campaign and can be used to log or communicate these events in the system.

## Adding interface

It is necessary to add an ABI management file to handle the input-output structure when invoking dApp functions. Create a file named `interface.sw` in the `petition-contract/src` folder and add the following code to it:

```
library;

use ::data_structures::{
    campaign::Campaign,
    campaign_info::CampaignInfo,
    signs::Signs,
};

abi Petition {
    
    #[storage(read, write)]
    fn cancel_campaign(id: u64);
   
    #[storage(read, write)]
    fn end_campaign(id: u64);
   
    #[storage(read, write)]
    fn create_campaign(deadline: u64);
    
    #[storage(read, write)]
    fn sign_petition(id: u64);

    #[storage(read, write)]
    fn unsign_petition(id: u64);
}

abi Info {

    #[storage(read)]
    fn campaign_info(id: u64) -> Option<CampaignInfo>;

    #[storage(read)]
    fn campaign(campaign_history_index: u64, user: Identity) -> Option<Campaign>;

    #[storage(read)]
    fn sign_count(user: Identity) -> u64;

    #[storage(read)]
    fn signed(sign_history_index: u64, user: Identity) -> Option<Signs>;

    #[storage(read)]
    fn total_campaigns() -> u64;

    #[storage(read)]
    fn user_campaign_count(user: Identity) -> u64;
}
```

### Explanation

This code defines a library with two ABIs (Application Binary Interface) named `Petition` and `Info`. Let's break down the components:

```
library;

use ::data_structures::{
    campaign::Campaign,
    campaign_info::CampaignInfo,
    signs::Signs,
};
```

- The code starts with the declaration of a library.
- It then imports several structs (`Campaign`, `CampaignInfo`, `Signs`) from the `data_structures` module.

```
abi Petition {

    #[storage(read, write)]
    fn cancel_campaign(id: u64);

    #[storage(read, write)]
    fn end_campaign(id: u64);

    #[storage(read, write)]
    fn create_campaign(deadline: u64);

    #[storage(read, write)]
    fn sign_petition(id: u64);

    #[storage(read, write)]
    fn unsign_petition(id: u64);
}
```

- `Petition` ABI: Defines a set of functions that can be called by external actors using the Petition ABI.
    - `cancel_campaign`: Cancels a campaign with the given `id`.
    - `end_campaign`: Ends a campaign with the given `id`.
    - `create_campaign`: Creates a new campaign with the specified `deadline`.
    - `sign_petition`: Allows a user to sign a campaign with the given `id`.
    - `unsign_petition`: Allows a user to withdraw their signature from a campaign with the given `id`.

```
abi Info {

    #[storage(read)]
    fn campaign_info(id: u64) -> Option<CampaignInfo>;

    #[storage(read)]
    fn campaign(campaign_history_index: u64, user: Identity) -> Option<Campaign>;

    #[storage(read)]
    fn sign_count(user: Identity) -> u64;

    #[storage(read)]
    fn signed(sign_history_index: u64, user: Identity) -> Option<Signs>;

    #[storage(read)]
    fn total_campaigns() -> u64;

    #[storage(read)]
    fn user_campaign_count(user: Identity) -> u64;
}
```

- `Info` ABI: Defines a set of functions that can be called by external actors using the Info ABI.
    - `campaign_info`: Retrieves information about a campaign with the given `id`.
    - `campaign`: Retrieves information about a campaign for a specific `user` and `campaign_history_index`.
    - `sign_count`: Retrieves the number of campaigns a `user` has signed.
    - `signed`: Retrieves information about a signed campaign for a specific `user` and `sign_history_index`.
    - `total_campaigns`: Retrieves the total number of campaigns.
    - `user_campaign_count`: Retrieves the number of campaigns created by a specific `user`.

These ABIs define the interface for interacting with the smart contract. External actors can use these functions to perform various actions related to campaigns and retrieve information about the contract's state.

## That’s a wrap

In this lesson, we added events and interfaces to our petition dApp. Events allow us to log important actions within the system, while interfaces define the functions that external actors can use to interact with the smart contract. By adding these features, we have made progress in building a more comprehensive and functional petition dApp. Stay tuned for the next lesson!

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/4.%20Writing%20Your%20Smart%20Contract/3.%20Let%E2%80%99s%20Add%20the%20Events%20and%20Interfaces.md

Let’s Add the Events and Interfaces

# Let’s Add the Errors and Utils

Let’s work on the Errors and Utils files of our Petition dApp.

## `errors.sw`

Now that we have covered an important part of our petition dApp, we need to write the code that manages the errors of the dApp which we can throw whenever a condition is not met. Create a file named `errors.sw` in the `petition-contract/src` folder and add the following code to it:

```
library;

pub enum CampaignError {
    CampaignEnded: (),
    CampaignHasBeenCancelled: (),
    DeadlineNotReached: (),
}

pub enum CreationError {
    DeadlineMustBeInTheFuture: (),
}

pub enum UserError {
    SuccessfulCampaign: (),
    AlreadySigned: (),
    InvalidID: (),
    UnauthorizedUser: (),
    UserHasNotSigned: (),
}
```

### Explanation

This code defines a library that contains custom error types related to a campaign on a blockchain. Each error type represents a specific scenario or condition that can occur during the execution of smart contracts in the context of a campaign. Let's break down the different error types:

1. **`CampaignError`:**
    - The enum represents errors directly related to the campaign itself.
    - Possible variants:
        - `CampaignEnded`: Indicates that the campaign has already ended.
        - `CampaignHasBeenCancelled`: Indicates that the campaign has been canceled.
        - `DeadlineNotReached`: Indicates that the campaign's deadline has not been reached yet.
2. **`CreationError`:**
    - The enum represents errors related to the creation of a campaign.
    - Possible variants:
        - `DeadlineMustBeInTheFuture`: Indicates that the campaign's deadline must be set in the future.
3. **`UserError`:**
    - The enum represents errors related to user actions within the campaign.
    - Possible variants:
        - `SuccessfulCampaign`: Indicates that the user has already claimed the proceeds from the campaign.
        - `AlreadySigned`: Indicates that the user has already signed the campaign.
        - `InvalidID`: Indicates that the given ID does not correspond to a valid campaign.
        - `UnauthorizedUser`: Indicates that the user is not authorized to perform a certain action.
        - `UserHasNotSigned`: Indicates that the user has not signed the campaign.

## `utils.sw`

This file will acts as a validator to check the correctness of the campaign ID. Create a file named `utils.sw` in the `petition-contract` and add the following code to it:

```
library;

use ::errors::UserError;
pub fn validate_campaign_id(id: u64, count: u64) {
    require(id != 0 && id <= count, UserError::InvalidID);
}
```

### Explanation

This code defines a function named `validate_campaign_id` within a library. The purpose of this function is to ensure that a given campaign ID is valid based on certain conditions. Let's break down the components of this code:

```
library;
use ::errors::UserError;
```

- The code starts with the declaration of a library. Libraries in Sway are used to encapsulate reusable code, and they can contain functions, types, or other items.
- It then imports the `UserError` enum from the `errors` module, indicating that this function may raise errors related to user actions.

```
pub fn validate_campaign_id(id: u64, count: u64) {
    require(id != 0 && id <= count, UserError::InvalidID);
}

```

- The `validate_campaign_id` function is documented with comments indicating its purpose, arguments, and potential revert conditions.
- It takes two parameters:
    - `id`: The ID to be validated.
    - `count`: The count against which the ID should be validated.
- The function uses the `require` statement to check two conditions:
    1. `id != 0`: Ensures that the ID is not zero.
    2. `id <= count`: Ensures that the ID is less than or equal to the provided count.
- If either of these conditions is not met, the function triggers a revert with the `UserError::InvalidID` error, indicating that the campaign ID is not valid.

## That’s a wrap

In this lesson, we created the `errors.sw` file to handle specific scenarios related to a campaign on the blockchain. We also added the `utils.sw` file with a function to validate campaign IDs. These enhancements improve the reliability and maintainability of our Petition dApp. Next, we will write the main file of our dApp.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/4.%20Writing%20Your%20Smart%20Contract/4.%20Let%E2%80%99s%20Add%20the%20Errors%20and%20Utils.md

Let’s Add the Errors and Utils

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/4.%20Writing%20Your%20Smart%20Contract/5.%20Writing%20the%20Main%20File.md

Writing the Main File

# Setup Fuel Wallet

Awesome work till now. Now we are one step closer to deploying our dApp. Let’s quickly set up our wallet too!

Open a new terminal in your `petition-contract` directory and complete the following steps:

1. Initialize a new wallet: 
    
    ```
    forc wallet new
    ```
    
    - You will be prompted to enter a password. Set the password for this and confirm it.
    - After setting the password, you will see the mnemonic phrase in the output. Save it somewhere safe. DO NOT SHARE IT WITH ANYONE! These phrases are private information that can be used to hack your account. We will also need it to import our wallet so make sure to save it.
    - Hit the Enter/return button.
    
2. Create a new account:
    
    ```
    forc wallet account new
    ```
    
    - You will be prompted to enter the password you set in the previous step. Enter it and press the Enter/return button. Make sure to save your Wallet mnemonic phrase
    - You will get your fuel address. Save it as you'll need it to sign transactions to deploy the contract.
    
    ![Frame 3560370 (10).jpg](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/Frame_3560370_(10).jpg?raw=true)
    

3. You can view your list of accounts using the command below:
    
    ```
    forc wallet accounts
    ```
    

## Importing CLI Wallet to Fuel Wallet

- Go to [Fuel Wallet Chrome Extension](https://chromewebstore.google.com/detail/fuel-wallet/dldjpboieedgcmpkchcjcbijingjcgok) and click on “Add to Chrome” button.
- After Installing Fuel Wallet, you will see a popup tab where you need to click on “Import seed phrase” button.
    
    ![wallet-1.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-1.png?raw=true)
    
- Check the terms and condition checkbox and click on “Next: Seed Phrase” button.
    
    ![wallet-2.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-2.png?raw=true)
    

- Now select “I have a 24-word Seed Phrase”, paste your Wallet Mnemonic Phrase and click on the “Next: Your password” button.
    
    ![wallet-3.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-3.png?raw=true)
    

- Now finally set a password for your wallet, make sure it is a strong password, or else you won’t be allowed to move forward and please make a note of your password because trust me you need this whenever you are going to sign a transaction. Click on “Next: Finish set up” button to move forward.
    
    ![wallet-4.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-4.png?raw=true)
    

- And we are all set, let now move on to top it up with some faucet ETH because we will be needing this to pay for the gas.

**Note:** Your wallet might not show the same wallet address as shown on your terminal. So, remember to use the wallet address shown on the terminal to get some fake tokens.

## Get some tokens

Now it’s time to get some fake money in your wallet. Follow the steps given below to get some tokens:

1. Head over to [https://faucet-testnet.fuel.network/](https://faucet-testnet.fuel.network/).
2. Paste your wallet address. 
3. Submit the CAPTCHA.
4. Click on the “Give me Ether” button.
5. You will receive 0.01 ETH in your wallet.

## Wrap up

In this lesson, we learned how to set up our wallet, create a new account, and obtain our fuel address. We also learned how to get tokens from a faucet. Now we can proceed with deploying our contract. Let's move on to the next step!


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/5.%20Deploy%20the%20dApp/1.%20Setup%20Fuel%20Wallet.md

Setup Fuel Wallet

# Deploy the dApp

Kudos to you for making it so far! Now we will finally deploy our dApp on the Fuel blockchain. Yayyy!!

Open a new terminal in your `petition-contract` directory or continue using the previous terminal if opened. 

Run the following command to build your files:

```
forc build
```

This will generate the following output:

![Frame 3560370 (11).jpg](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Deploy%20the%20dApp/Frame_3560370_(11).jpg?raw=true)

Now let’s deploy the dApp using the following command:

```
forc deploy --testnet
```

- Once you use this command, it will ask you your the password of the wallet.
- After you provide the correct password, you will then be asked to provide the index of the account to use for signing - here you can write **0**.
- Lastly, you will be asked if you agree to sign this transaction. You can type **y** to approve the transaction.

The output should look like so: 

![deploy-2 (1).png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Deploy%20the%20dApp/deploy-2_(1).png?raw=true)

After deploying the contract, go back to Visual Studio code to your `petition-contract` folder. Here, you will find an extra `out` folder. Inside of the out folder, you’ll see two more folders: `debug` and `deployments`. The `debug` folder here contains the ABI files. We will use these ABI files to connect our deployed smart contract with the front end. Here’s what the project structure looks like:

![deploy-3 (1).png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Deploy%20the%20dApp/deploy-3_(1).png?raw=true)

**Note:** Please make sure you deploy the contract correctly because without ABI files you cannot cannot connect your Fuel project with the front end.

## That’s a wrap

In conclusion, we learned how to deploy a dApp on the Fuel blockchain. We built our files using `forc build` and deployed the dApp using `forc deploy --testnet`. Now, let's add the frontend to our dApp.


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/5.%20Deploy%20the%20dApp/2.%20Deploy%20the%20dApp.md

Deploy the dApp

# Setting Up Frontend

Kudos! We have deployed our dApp and now we are all set to proceed in setting up our frontend. No more waiting, let’s go!

## Set up the frontend

Open a new terminal in the `petition-app` folder, outside of the `petition-contract` directory.

Run the following command to clone the frontend directory:

```
git clone https://github.com/0xmetaschool/fuel-petition-frontend-boilerplate.git
```

After clonning the app don’t forget to move to the specific folder in your terminal.

```
cd fuel-petition-frontend-boilerplate
```

Let’s install our dependencies. Run each command one by one.

```
npm install
```

## Set up the ABIs

Time to move our ABI JSON files to the front end of the `petition-contract` project. To do this, we will run the following command inside the `fuel-petition-frontend-boilerplate` folder. This command will execute the `fuel.config.ts` file.

```
npx fuels build
```

This will add the `contracts` folder to your `src`:

![Frame 3560370 (12).jpg](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setting%20up%20Frontend/Frame_3560370_(12).jpg?raw=true)

## Set up the contract address

Move to the `src/App.tsx` file in the `fuel-petition-frontend-boilerplate` folder and replace your fuel contract address in the following line.

```
const CONTRACT_ID = "YOUR_CONTRACT_ADDRESS"; //Replace with your contract address
```

## Run the frontend

Now run the following command to start your app:

```
npm start
```

You will see an output like this:

![Frame 3560372.jpg](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setting%20up%20Frontend/Frame_3560372.jpg?raw=true)

## That’s a wrap

In this lesson, we learned how to set up the front end for our dApp. We cloned the frontend directory, installed dependencies, and moved the ABI JSON files. Congratulations on completing this lesson and setting up your dApp's front end! Happy coding!

In the next lesson, we will interact with our dApp.


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/6.%20Working%20with%20Frontend/1.%20Setting%20up%20Frontend.md

Setting Up Frontend

# Interact with the DApp

Now that you have deployed the contract and completed running the front end as well. In this lesson, we will learn how can you interact with the front end and use the petition dApp.

## Start interacting with the dApp

We will walk you through each feature of the dApp and how you can interact with it. So, buckle up and follow the steps one by one.

1. **Connect your wallet:** Make sure that the Fuel wallet is set up in your system and already has some tokens. Then click on the “Connect Wallet” button. Remember to select the "Fuel Wallet" from the list of wallets.
    
![run-app-1.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Interact%20With%20the%20DApp/run-app-1.gif?raw=true)
    

2. **Create a campaign:** First of all, we will create a create campaign. Fill in the first field, set the number of deadlines, and click on “Create Campaign.” After creating the campaign remember to save the campaign ID somewhere. You’ll need the campaign ID to sign the petition, get information, or end it.
    
![fuel-run-2-2.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Interact%20With%20the%20DApp/fuel-run-2-2.gif?raw=true)
    

3. **Sign the petition:** Let’s sign the petition by entering the campaign ID in the “Sign” field and clicking the “Sign” button.
    
![fuel-run-3.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Interact%20With%20the%20DApp/fuel-run-3.gif?raw=true)
    
4. **Get campaign information:** To get information about the campaign and know its status, enter the campaign ID in the “info” field and click on “info”.
    
![fuel-run-4.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Interact%20With%20the%20DApp/fuel-run-4.gif?raw=true)
    

Now, try out other fields and create more campaigns to make good use of your petition dApp.

## That’s a wrap

I’m so proud of you for building, shipping, and using your own dApp. Let’s just go through what you have learned in this course in the next lesson.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/7.%20Run%20the%20dApp/1.%20Interact%20With%20the%20DApp.md

Interact with the DApp

# Wrap Up

Congratulations on reaching the end of this comprehensive guide to building a decentralized application (dApp) on the Fuel blockchain! Throughout this learning journey, you've gained valuable insights into the Fuel network, mastered the Sway programming language, and successfully crafted and deployed a smart contract for a petition dApp. Let's reflect on your achievements and outline the key takeaways.

## Key Learnings:

1. **Fuel Ecosystem Exploration:**
    - You've familiarized yourself with the Fuel network, understanding its capabilities and how it stands out in the blockchain space.
2. **Sway Basics:**
    - Explored the basics of the Sway programming language, covering variables, data types, data structures, and functions.
3. **Development Environment Setup:**
    - Set up the Fuel toolchain and ensure your development environment is ready for creating decentralized applications.
4. **Smart Contract Development:**
    - Progressed through the step-by-step process of coding a smart contract for a petition dApp. From data structure setup to deployment, you've seen how Sway empowers developers in the Fuel ecosystem.
5. **Frontend Integration:**
    - Created a frontend for your dApp, showcasing the seamless interaction between smart contracts and user interfaces.
6. **Interaction:**
    - Learned how to interact with your dApp, ensuring that it performs as expected.

## ⚒️ A small yet important request:

This is a 100% open-source project like all the other projects on our platform. You can find the tutorial markdown files [here](https://github.com/0xmetaschool/Learning-Projects/tree/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network). If you find any issues in the course, please feel free to resolve it. We, at Metaschool, love love love contributions by our community and acknowledge the contributors on our [Discord](https://discord.com/invite/vbVMUwXWgc) and GitHub, too.

While you’re contributing:

1. Don’t forget to star ⭐️ our repository. We will be very thankful! ❤️
2. We are a completely free platform and we aim to stay the same, so please consider following us on [X](https://bit.ly/petition-dapp-fuel-twitter) and [LinkedIn](https://bit.ly/petition-dapp-fuel-linkedin) as well. 🫶


## 🎊 Congratulations

Thank you for joining us on this exciting journey into the world of Fuel and decentralized applications. Your commitment to learning and building in the blockchain space is commendable. Best of luck in all your future endeavors as you continue to shape the future of decentralized technologies!

WAGMI! Peace out! ✌🏻🔮

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20a%20Petition%20Filing%20dApp%20on%20the%20Fuel%20Network/8.%20Let%E2%80%99s%20Wrap%20it%20up/1.%20Wrap%20Up.md

Wrap Up

Build a Petition Filing dApp on the Fuel Network

Building an Airbnb dApp is the second course of the Fuel Network learning path, a perfect place to start for any developer looking to add Fuel Network to their skillsets. An advanced level course, it teaches you how to create a full-fledged dApp resembling that of Airbnb. 

You will begin this course by exploring more functions of the Sway programming language. Later on, you will build the AirBnb clone in the same programming language and deploy it on Fuel blockchain. Lastly, you will connect your dApp with Sway project and run it to functionally use your dApp.

# What Are We Building Today

GM everyone ☀️, today we are very excited to bring the second course of our advanced series on Fuel blockchain for developers on Metaschool. Let’s start the second course by congratulating you for completing the first course on Fuel blockchain. Woohoo!

So, what are we building? Believe it or not, we will build an Airbnb dApp using the Sway programming language on the Fuel blockchain. And this will serve as a huge learning step for you all. So let’s give it our all to this!!

Let’s revise how learning Fuel and Sway programming language can help you upskill and stand out in the job market. Fuel has 15 investors including 300 DAO and MH Ventures. Fuel is supported by Blockchain Capital, Stratos, CoinFund, Spartan, and many more.

Fuel is an L2 blockchain aiming for speed, efficiency, and security. It provides fast and low-cost transactions by separating execution from consensus and data availability making it the World’s fastest execution layer.

## Course overview

We will:

1. Revise the concepts of the Fuel blockchain and Sway programming language
2. Set up the development environment and Fuel wallet
3. Build and deploy the Airbnb dApp from start to finish
4. Set up and run the front end of the dApp

## Who exactly should take this course?        

This course is for advanced web3 developers who wish to learn about Fuel blockchain. You should have basic programming knowledge as it will help you have a quick start to this course. 

## What you will be getting out of this course?

As a developer, you will be getting the following outcomes when you complete this course:

1. Understand how Fuel is different from other blockchain
2. Learn why you should choose Fuel for your next dApp
3. Learn how to work with the Sway programming language and build your dApps
4. Earn up to 1000 XPs

## Proof of completion

If you complete this course with me, you will be getting XPs and a special NFT which will unlock many more opportunities for you on the Metaschool platform. Here is what the NFT looks like.

![ezgif.com-optimize (3).gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/course%20NFT.gif?raw=true)

Now before we move forward, let’s set some house rules first.
1. Kindly do your quick assignments properly.
2. Join [our discord server](https://discord.gg/vbVMUwXWgc) and ask all relevant questions there.
3. We are a free open-source platform and if you follow us on [X](https://bit.ly/airbnb-dapp-fuel-twitter) and [LinkedIn](https://bit.ly/airbnb-dapp-fuel-linkedin), it would be a great support.  🫣
4. Stay happy and positive!

Alright guys, no need to wait any longer, let's dive right into our awesome Fuel Blockchain course! Let's do this! 🙌


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/1.%20Let%E2%80%99s%20Get%20Started/1.%20What%20Are%20We%20Building%20Today.md

What Are We Building Today

# Revisit Fuel and Sway

Hey folks, we’re so glad for you to complete the first course of this Fuel learning path. Before we dive into the coding arena, let's take a moment to refresh our understanding of Sway and delve into some key concepts of Fuel.

## Fuel revision

Let's recap some essential aspects of Fuel blockchain.

### Fuel's three pillars

Fuel's technology stack rests on three key pillars:

1. Fuel achieves unparalleled processing capacity by executing transactions in parallel.
2. The FuelVM minimizes wasteful processing, providing an optimized design for executing complex smart contracts.
3. Fuel prioritizes a robust and user-friendly developer experience. 

## Sway revision

Now, let's shift our focus to Sway and recap some essential aspects:

### Variables

In Sway, variables are immutable by default, ensuring a safe programming environment. For instance:

```
let num = 10;
```

If you wish to make a variable mutable, employ the **`mut`** keyword:

```
let mut num = 10;
num = 12;
```

### Type annotations

Type annotations help declare variable types. For example:

```
let bar: str[4] = __to_str_array("sway");
let baz: bool = true;
```

You can also explicitly define variable types:

```
let num: u32 = 5;
```

### Built-in types in Sway

Sway's statically typed nature is evident in its primitive types, such as `u8`, `u16`, `u32`, `u64`, `u256`, `str[]`, `str`, `bool`, and `b256`. It also introduces concepts like string slices, string arrays, tuples, and arrays.

### Functions

Sway functions, declared with the `fn` keyword, are a crucial aspect of its expressive power. Here's a quick look:

```
fn equals(first_param: u64, second_param: u64) -> bool {
    first_param == second_param
}
```

And a usage example:

```
fn main() {
    equals(5, 5); // true
    equals(5, 6); // false
}
```

### Complex types and mutability

Sway supports complex types and mutable parameters, offering flexibility in coding. For example:

```
fn swap_tuple(ref mut pair: (u64, u64)) {
    let temp = pair.0;
    pair.0 = pair.1;
    pair.1 = temp;
}

fn update_color(ref mut color: Color, new_color: Color) {
    *color = new_color;
}
```

And their implementation:

```
let mut tuple = (42, 24);
swap_tuple(&mut tuple);
assert(tuple.0 == 24);
assert(tuple.1 == 42);

let mut color = Color::Red;
update_color(&mut color, Color::Blue);
assert(color == Color::Blue);
```

## That’s a wrap

In this lesson, we've revisited the fundamentals of both Sway and Fuel. Sway proves to be an expressive language, and with Fuel's three pillars, they form a powerful duo for blockchain development. Now, let's apply our knowledge by coding an end-to-end petition dApp on Fuel using Sway. Exciting times ahead!

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/1.%20Let%E2%80%99s%20Get%20Started/2.%20Revisit%20Fuel%20and%20Sway.md

Revisit Fuel and Sway

# Setup Fuel Toolchain

We are so proud of you for choosing to upskill by continuing this course. In this lesson, you will learn how to set up your system with a Fuel chain to run the Sway programs. Skip this lesson, if your already have set up the Fuel toolchain in your system.

## Prerequisite installations

Before installing the Fuel toolchain, we need to make sure that our system is ready to go. So let’s do that first. Feel free to scroll through the lesson to install the packages for your specific OS.

### MacOS

Let's ensure your MacOS is ready. Open the terminal and run these commands.

1. Install `brew` using the following command:

    ```
    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    ```

2. Install `curl` using the following command:

    ```
    brew install curl
    ```

3. Install `git` using the following command:

    ```
    brew install git
    ```

### Linux

If you have a Linux OS system, run the following commands to set up your system.

1. Update `apt-get` using the following command:

    ```
    sudo apt-get update
    ```

2. Install `cURL` using the following command:
    
    ```
    sudo apt install curl
    ```
    
3. Install `git` CLI:
    
    ```
    sudo apt-get install git-all
    ```
    

4.  Install `libssl-dev`:

    ```
    sudo apt-get install libssl-dev
    ```

5. Install `libclang-dev`:
    
    ```
    sudo apt-get install libclang-dev
    ```
    
6. Install `libpq-dev`:
    
    ```
    sudo apt-get install libpq-dev
    ```
    
7. Install `build-essential`:
    
    ```
    sudo apt-get install build-essential
    ```
    

### Windows

Let's review the prerequisites needed to install Fuel on Windows.

For Windows, you should install [WSL](https://learn.microsoft.com/en-us/windows/wsl/install). Currently Fuel doesn't natively support Windows so you will need a Linux subsystem like WSL


Now, follow the following instructions to install the Rust and Fuel toolchain in your system. Open the terminal in your system and run the following commands.

1. First of all, we need to install the Rust in your system. The fuel blockchain is built on top of the Rust programming language. To install Rust, run the following command in your system.

```
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
```

2. Run the following command to check the version of Rust installed in your system.

```
rustup --version
```

3. To install the Fuel toolchain, you need to install the `fuelup-init` script. After running the following command it will install Fuel toolchain. If the command asks you to modify the path, press `y` and “Enter” to modify the path.

```
curl --proto '=https' --tlsv1.2 -sSf https://install.fuel.network/fuelup-init.sh | sh
```

4. Run the following command to check if the installation process was a success.

```
fuelup --version
```

5. Make sure your toolchain is up-to-date. 

```
fuelup self update
```

6. Run the following command to install the `beta-5` toolchain.

```
fuelup toolchain install beta-5
```

7. Set `beta-5` as your default toolchain with the following command:

```
fuelup default beta-5
```

8. Run the following command to view the list of toolchains and versions of the tools you are using.

```
fuelup show
```

## That’s a wrap

Without further ado, in the next section, we will move on to set up our Fuels wallet. So, let’s go!! 

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/2.%20Setting%20Up%20the%20Dev%20Environment/1.%20Setup%20Fuel%20Toolchain.md

Setup Fuel Toolchain

# Set Up the Sway Airbnb Project

Welcome back! We’re so proud of you for setting up your system to run Sway programs. Now without any delay, we will create a Sway project and understand how it works.

## Set up your first Sway project

Let’s start by building the basic Sway project. This project we will use to build our first Airbnb dApp on Fuel. Open the terminal in your system and start following the instructions to set up your project.

1. Start by creating a new and empty folder. Let’s call it `airbnb-dapp`. You can call it whatever you want to.

```
mkdir airbnb-dapp
```

2. Move inside of the folder, we just created.

```
cd airbnb-dapp
```

3. Create the fuel project using the following command.

```
forc new airbnb-contract
```

After executing the command, you can expect to receive the output showed below. 

![fuel-output-2.1.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Sway%20Airbnb%20Project/fuel-output-2.1.png?raw=true)

## Project structure

Now, open the project folder, `airbnb-dapp` in the VS code. Here’s what the project structure will look like.

![fuel-structure-2.1.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Sway%20Airbnb%20Project/fuel-structure-2.1.png?raw=true)

### `Forc.toml` file

`Forc.toml` is a manifest file, the same as the `Cargo.toml` file. It defines the metadata of the project such as the project name and dependencies. Let’s look at what it looks like by default.

```
[project]
authors = ["Author Name"]
entry = "main.sw"
license = "Apache-2.0"
name = "airbnb-contract"

[dependencies]
```

### Setup the project

Open the `src/main.sw` file and delete any existing code apart from the first line. It is important to start every Sway file with a declaration of its program type. So, in `main.sw` file, we are defining that our file will be a contract using the following line.

```
contract;
```

Let’s create a new folder inside of the `src` folder. 

```
cd airbnb-contract
cd src
mkdir data_structures
```

The updated project structure will look like this.

![fuel-structure-2.2.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Sway%20Airbnb%20Project/fuel-structure-2.2.png?raw=true)

We will use the `data_structures` folder to create different components of our `airbnb-contract` such as creating a campaign, tracking the campaign, and representing the current state of the campaign to the user and keeping track of the number of signs on one campaign.

## That’s a wrap

Great work on setting up your first project on Fuel blockchain. We will use this project to create our Airbnb dApp. 

We need to write different components to make our petition dApp stand out. So, we will not only write code in the `main.sw` file, but write code in multiple files and build different components of our petition dApp.

In the next lesson, we will start with writing the code for different components inside of the `data_structures` folder. So, get ready for some exciting work!

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/2.%20Setting%20Up%20the%20Dev%20Environment/2.%20Set%20Up%20the%20Sway%20Airbnb%20Project.md

Set Up the Sway Airbnb Project

# Build the Booking Library

Kudos to you for setting up everything you need to build and ship your own Airbnb dApp on the Fuel blockchain. Without further delay, we will start building our dApp and start the coding part. So, buckle up and start coding.

## Adding libraries to our Airbnb dApp

The contract in Sway is callable and stateful. It is deployed to the blockchain via transaction. Think of a smart contract as a deployed API that comes with a database state. In Sway, each file is defined by a program type, followed by the import of a library. So, before moving on to writing our contract, `main.sw`. We will write four different libraries that we will eventually use in our smart contract. These libraries are like libraries that will perform different tasks and help us keep records of the different information. 

We will start by adding the libraries to the `data_structures` folder. Let’s look at what they will be.

1. Booking Info library - Keeps record of the information of the booking details. 
2. Booking State library - Keeps record of the state of the booking, for example, if the property is booked or available.
3. Booking library - Keeps track of the campaign one user has created, for example keeping track of booking ID alongside booking information and state.
4. Property Image library - Store the details of the property image.
5. Property Info library - Keeps record of the information of the property details. 
6. Property State library - Keeps record of the state of the booking, for example, if the property is listed or not.
7. Property library - Keeps track of the campaign one user has created, for example keeping track of property ID alongside property image, information, and state.

We will discuss more about these libraries while implementing them. So, let’s start implementing them one by one and understand the code side by side.

## Booking State Library

First of all, we will begin with implementing the state library. We need a state library because it will help us keep a record of whether the booking is available or not. We will implement state before implementing booking information because we will use the state library in booking information. We want to save the state of the booking in the booking information as well.

Create a `booking_state.sw` file inside of the `src/data_structures` folder and start coding. We will write and explain the code line by line for you to understand everything in detail.

### Defining Library Type

```
library;
```

As with any Sway project, we commence by defining the type of our program. The `library` keyword signals that we are crafting a library, and in this case, it revolves around the states of our bookings.

### Importing Essential Modules

```
use core::ops::Eq;
```

To enhance the functionality of our library, we import `Eq` from the `core::ops` module. This trait allows us to define equality operations for our `BookingState` enum.

### Crafting the Booking State Enum

```
/// Represents the current state of the Booking.
pub enum BookingState {
    pub Available: (),
    pub Booked: (),
    pub Cancelled: (),
}
```

Here, we introduce the `BookingState` enum, a fundamental aspect of our booking library. Let's unravel its elements:

- `Available: ()`: This variant signifies that a booking is available. The `()` denotes an empty tuple, indicating the absence of additional information in this state.
- `Booked: ()`: The `Booked` variant indicates a booking has been successfully reserved. Like `Available`, it carries an empty tuple.
- `Cancelled: ()`: In the unfortunate event of a cancellation, the `Cancelled` variant comes into play, also utilizing an empty tuple.

### Implementing the Booking States

```
impl Eq for BookingState {
    fn eq(self, other: BookingState) -> bool {
        match (self, other) {
            (BookingState::Available, BookingState::Available) => true,
            (BookingState::Booked, BookingState::Booked) => true,
            (BookingState::Cancelled, BookingState::Cancelled) => true,
            _ => false,
        }
    }
}
```

To enable equality comparisons for our `BookingState` enum, we implement the `Eq` trait. The `eq` function ensures that instances of `BookingState` can be compared for equality, providing a foundational mechanism for state validation.

### Complete code

Here’s the complete code for `src/data_structures/booking_state.sw` file.

```
library;

use core::ops::Eq;

/// Represents the current state of the Booking.
pub enum BookingState {

    pub Available: (),

    pub Booked: (),

    pub Cancelled: (),
}

impl Eq for BookingState {
    fn eq(self, other: BookingState) -> bool {
        match (self, other) {
            (BookingState::Available, BookingState::Available) => true,
            (BookingState::Booked, BookingState::Booked) => true,
            (BookingState::Cancelled, BookingState::Cancelled) => true,
            _ => false,
        }
    }
}
```

## Booking Info library

We need a booking library for our Airbnb dApp because it will help us keep a record of any booking. As there can be multiple campaigns booking at a time, it is important to keep a record of each booking. So, let’s start making a library that will keep a detailed record of the booking information on the Fuel blockchain. 

Create a `booking_info.sw` file inside of the `src/data_structures` folder and start coding. We will write and explain the code line by line for you to understand everything in detail.

### Defining Library Type

```
library;
```

As mentioned, in Sway, we start by defining the type of our program. The `library` keyword signals that we are crafting a library, a fundamental component in our quest to revolutionize decentralized accommodations.

### Importing Essential Modules

```
use ::data_structures::booking_state::BookingState;
```

To build our booking library, we import `BookingState` from `data_structures/booking_state.sw`. This module holds essential states for bookings, allowing us to track the lifecycle of each booking.

### Creating a Booking Data Structure

```
/// General data structure containing information about a booking
pub struct BookingInfo {
    /// The user who has created the booking
    pub bookedBy: Identity,
    ///booking from
    pub bookingFrom: u64,
    ///booking to
    pub bookingTo: u64,
    //Booking Status
    pub status: BookingState,
    ///Property booked
    pub property_id: u64,
}
```

Here, we define a new data structure named `BookingInfo`. Let's dissect its components:

- `bookedBy: Identity`: We capture the user who initiated the booking. The `Identity` type accommodates both `address` and `ContractId` for versatile user identification.
- `bookingFrom: u64`: This variable signifies the start date of the booking, represented as a `u64` data type.
- `bookingTo: u64`: Similarly, the end date of the booking is stored in a `u64` variable.
- `status: BookingState`: An instance of the `BookingState` enum is used to track the status of the booking, providing insights into whether it's booked, in progress, or canceled.
- `property_id: u64`: This variable holds the identifier of the property being booked.

### Implementing the BookingInfo Constructor

```
impl BookingInfo {

    pub fn new(
        bookedBy: Identity,
        bookingFrom: u64,
        bookingTo: u64,
        property_id: u64,
    ) -> Self {
        Self {
            bookedBy,
            bookingFrom,
            bookingTo,
            status: BookingState::Booked,
            property_id,
        }
    }
}
```

We introduce a constructor `new` for `BookingInfo`, facilitating the creation of booking instances with seamless initialization. The default status for a new booking is set to `BookingState::Booked`, reflecting its initial state.

### Complete code

Here’s the complete code for `src/data_structures/booking_info.sw` file.

```
library;

use ::data_structures::booking_state::BookingState;

/// General data structure containing information about a booking
pub struct BookingInfo {
    /// The user who has created the booking
    pub bookedBy: Identity,
    ///booking from
    pub bookingFrom: u64,
    ///booking to
    pub bookingTo: u64,
    //Booking Status
    pub status: BookingState,
    ///Property booked
    pub property_id: u64,
}

impl BookingInfo {

    pub fn new(
        bookedBy: Identity,
        bookingFrom: u64,
        bookingTo: u64,
        property_id: u64,
    ) -> Self {
        Self {
            bookedBy,
            bookingFrom,
            bookingTo,
            status: BookingState::Booked,
            property_id,
        }
    }
}
```

## Booking library

We need a library that will store the information of the bookings ID. It will create the struct for booking ID which we map to the `booking_info` after creating a local storage named `booking_info` where `u64` will be the ID that is mapped to `booking_info`.

Create a `booking.sw` file inside of the `src/data_structures` folder and start coding. We will write and explain the code line by line for you to understand everything in detail.

### Defining Library Type

```
library;
```

As with any Sway project, our journey begins by declaring the type of our program. The **`library`** keyword sets the stage, indicating that we are crafting a library with a specific focus on booking functionalities.

### Crafting the Booking Structure

```
/// Used to track the Listings that a user has created.
pub struct Booking {
    /// The unique identifier for the Listing.
    pub id: u64,
}
```

Here, we introduce the `Booking` structure, designed to track the listings associated with a user. Let's break down its key element:

- `id: u64`: This variable serves as the unique identifier for a listing within the booking system. Each booking is distinguished by its own `id`, ensuring a clear and unambiguous reference.

### Implementing the Booking Constructor

```
impl Booking {
    /// Creates a new Listing.
    ///
    /// # Arguments
    ///
    /// * `id`: [u64] - The unique identifier for the Listing.
    pub fn new(id: u64) -> Self {
        Self { id }
    }
}
```

The `Booking` structure comes to life with the implementation of its constructor, `new`. This function enables the seamless creation of new listings, allowing users to associate unique identifiers with their listings effortlessly.

The constructor takes a single argument:

- `id: u64`: This parameter represents the unique identifier for the listing being created. Users provide this identifier during the listing creation process.

Our `Booking` structure, coupled with its constructor, forms a crucial element in the intricate web of our Web3 booking library.

### Complete code

Here’s the complete code for `src/data_structures/booking.sw` file.

```
library;

/// Used to track the Listings that a user has created.
pub struct Booking {
    /// The unique identifier for the Listing.
    pub id: u64,
}

impl Booking {
    /// Creates a new Listing.
    ///
    /// # Arguments
    ///
    /// * `id`: [u64] - The unique identifier for the Listing.
    pub fn new(id: u64) -> Self {
        Self { id }
    }
}
```

## That’s a wrap

Great work on completing the 1st milestone of building your AirBnb dApp. Next, we will implement the property data structures.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/3.%20Start%20Writing%20the%20Sway%20DApp/1.%20Build%20the%20Booking%20Library.md

Build the Booking Library

# Create the Property Library

Now that you have already created your booking data structures, let’s go ahead and create a property data structure. Hold on tight as you are going to learn a lot in this lesson. 

The first data structure that we are going to build here is **property image**. Let's first try to understand what we want to achieve here and then we can start building it. 

The primary goal is to have the property image uploaded in a decentralized way. However, storing images on-chain is extremely expensive. But worry not, here’s when **IPFS** comes to our rescue. We will be storing our images on IPFS using something called Pinata. Well, I will come to this once we start working on the front end. So let’s get started: 

### property_image

Create a file called `property_image.sw` and write the following code: 

```
library;

/// Used to track the Listings that a user has created.
pub struct PropertyImage {
    /// images of the property.
    pub image1: b256,
    pub image2: b256,
}

impl PropertyImage {
    /// Creates a new Listing.
    ///
    /// # Arguments
    ///
    /// * `id`: [u64] - The unique identifier for the Listing.
    pub fn new(image1: b256, image2: b256) -> Self {
        Self { 
            image1,
            image2,
         }
    }
}
```

This file creates the struct to store the images as b256 which is a 256 bit, hence you can store a hash of 32 characters. Once we upload the images to IPFS, we get something called CID which we will show you the demo of this in the frontend section. We convert the CID here into the hash of 32 characters. We will get into more details in later sections. 

### property_info

Create a file called `property_info.sw` and write the following code:

```
library;

use ::data_structures::property_state::PropertyState;
use ::data_structures::booking_state::BookingState;


pub struct PropertyInfo {
    /// The user who has listed the Property
    pub owner: Identity,
    ///Pincode of the property
    pub pincode: u64,
    ///Listed or not
    pub listed: PropertyState,
    ///Availability
    pub available: BookingState,    
}

impl PropertyInfo {

    pub fn new(
        owner: Identity,
        pincode: u64,
    ) -> Self {
        Self {
            owner,
            pincode,
            listed: PropertyState::Listed,
            available: BookingState::Available,
        }
    }
}
```

This will create a struct for the property details like the pincode, owner, property state, and if the listing is available or not.  We internally create a storage to map to property id. 

### property

Create a file called `property.sw` and write the following code: 

```
library;

/// Used to track the Listings that a user has created.
pub struct Property {
    /// The unique identifier for the Listing.
    pub id: u64,
}

impl Property {
    /// Creates a new Listing.
    ///
    /// # Arguments
    ///
    /// * `id`: [u64] - The unique identifier for the Listing.
    pub fn new(id: u64) -> Self {
        Self { id }
    }
}
```

This file creates a struct for the `property_id` which will be similarly mapped to property info as `booking_info` that we looked at previously. 

### property_state

Create one more file called `property_state.sw` and paste the following code: 

```
library;

use core::ops::Eq;

/// Represents the current state of the campaign.
pub enum PropertyState {
    /// The campaign has been cancelled.
    pub Listed: (),
    /// The campain was successful
    pub Unlisted: (),
}

impl Eq for PropertyState {
    fn eq(self, other: PropertyState) -> bool {
        match (self, other) {
            (PropertyState::Listed, PropertyState::Listed) => true,
            (PropertyState::Unlisted, PropertyState::Unlisted) => true,
            _ => false,
        }
    }
}
```

This creates a struct for property states to track if the property is listed or not.

## That’s a wrap

Great work on completing the 2nd milestone of building your AirBnb dApp. Next, we will implement the events and errors handling features for our dApp.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/3.%20Start%20Writing%20the%20Sway%20DApp/2.%20Create%20the%20Property%20Library.md

Create the Property Library

# Add Events and Errors

Now let’s add events and errors in our smart contract. We need to write the error code so that whenever a certain condition is not met, it should throw an error. We also need to create events so that the events are emitted when a certain action is performed. 

## `errors.sw`

Let’s start with creating an `error.sw` file: 

```
library;

pub enum BookingError {

    PropertyBooked: (),

    BookingNotFound: (),

    PropertyNotAvailable: (),

    PropertyNotFound: (),
}

pub enum CreationError {

    BookingDateMustBeInFuture: (),
}

pub enum UserError {

    InvalidID: (),
    /// The user is not authorized to perform this action.
    UnauthorizedUser: (),

    PropertyNotAvailable: (),

}
```

Now let's start with understanding what we are doing here. 

- For the enum **BookingError**, we have a list of errors that will be thrown in certain cases like if the property is already booked, if the booking is not found, if the property is not available, and if the property is not found.
- For the enum **CreationError**, it indicates the error when the booking date is not in the future as in such cases, the booking should not be valid.
- Lastly, for the enum **UserError**, this error is thrown when the user searches for an invalid ID, or the user is not authorized to use this platform, and lastly, if the property is not available.

### events.sw

Now that we are done with the error file, let's create one for the events. This file will indicate which events will be thrown when a certain action takes place. To do that, let's first create one called `events.sw` and paste the following code: 

```
library;

use ::data_structures::property_info::PropertyInfo;

pub struct PropertyListed {

    pub owner: Identity,
    pub property_info: PropertyInfo,
    pub property_id: u64,
}
pub struct PropertyUnlisted {
    pub property_id: u64,
}

pub struct BookingSuccessful {

    pub booking_id: u64,
    pub bookedBy: Identity,
    pub bookingFrom: u64,
    pub bookingTo: u64,
}
```

- Here, a struct `PropertyListed` is emitted when the owner creates a listing for the house. It includes the identity of the owner, the info of the property, and the ID of the property.
- struct `PropertyUnlisted` will be emitted when the owner unlists the property. This includes the ID of the unlisted property.
- struct `BookingSuccessful` is emitted when the user successfully creates the booking. This includes booking ID, the identity of the owner who booked the property, and the dates from when the booking starts to when it ends.

## That’s a wrap

That was a lot! But if you have understood this, you are going to have a lot of fun in the later sections. See you there!

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/3.%20Start%20Writing%20the%20Sway%20DApp/3.%20Add%20Events%20and%20Errors.md

Add Events and Errors

# Building Airbnb Interface: Property Booking and Info

Welcome back, folks! Now that we have set up all data structure libraries, we need to build the main interface for our Airbnb app that will act as a bridge between our data structures and external interactions. So, let’s start building.

## Start building the interface

Create the `interface.sw` file in the `src` folder and start coding. We’ll explain the code one by one for you.

### Defining Library Type

```
library;
```

Our journey begins by defining the type of our program. The `library` keyword sets the stage, indicating that we are crafting a library with a focus on specific interfaces.

### Importing Essential Data Structures

```
use ::data_structures::{
    booking_info::BookingInfo,
    property_info::PropertyInfo,
    property_image::PropertyImage,
};
```

To equip our library with essential functionalities, we import data structures related to booking information, property details, and property images.

### HotelBooking Interface

```
abi HotelBooking {
    // ... (see details below)
}
```

The `HotelBooking` ABI serves as the interface through which external entities interact with our smart contract to perform actions related to hotel bookings. Let’s add the code to it.

**Listing a Property: `list_property`**

```
#[storage(read, write)]
fn list_property(pincode: u64, image1: b256, image2: b256);
```

The `list_property` function allows external entities to list a new property. It takes parameters such as `pincode` and image references (`image1`, `image2`). Let's break down its key components:

- `#[storage(read, write)]`: This attribute denotes that the function interacts with storage, both reading and writing.
- `pincode: u64, image1: b256, image2: b256`: These parameters provide essential details for the newly listed property, including the location and image references.

**Unlisting a Property: `unlist_property`**

```
#[storage(read, write)]
fn unlist_property(property_id: u64);
```

The `unlist_property` function enables external entities to unlist a property based on its `property_id`. Here's the breakdown:

- `#[storage(read, write)]`: Similar to `list_property`, this attribute signals storage interactions.
- `property_id: u64`: This parameter identifies the property to be unlisted.

**Booking a Property: `book`**

```
#[storage(read, write)]
fn book(property_id: u64, bookingFrom: u64, bookingTo: u64);
```

The `book` function orchestrates the property booking process. External entities can book a property by providing the `property_id` and the desired booking period (`bookingFrom`, `bookingTo`). Key components include:

- Date checks: Ensure booking dates are in the future.
- `#[storage(read, write)]`: Storage interactions are denoted.
- `property_id: u64, bookingFrom: u64, bookingTo: u64`: Parameters specifying the property and booking period.

### Info Interface

```
abi Info {
    // ... (see details below)
}
```

The `Info` ABI acts as a window into the internal state of our smart contract, allowing external entities to retrieve information. Let’s add the code to it.

**Retrieve Booking Information: `booking_info`**

```

#[storage(read)]
fn booking_info(booking_id: u64) -> Option<BookingInfo>;
```

The `booking_info` function provides external entities with details about a specific booking identified by `booking_id`. It returns an `Option<BookingInfo>` to handle the potential absence of data.

**Retrieve Property Information: `property_info`**

```
#[storage(read)]
fn property_info(property_id: u64) -> Option<PropertyInfo>;
```

The `property_info` function allows external entities to retrieve information about a property based on its `property_id`. It returns an `Option<PropertyInfo>` to gracefully handle scenarios where the property information might not exist.

**Retrieve Property Images: `get_property_images`**

```
#[storage(read)]
fn get_property_images(property_id: u64) -> Option<PropertyImage>;
```

With the `get_property_images` function, external entities can fetch images associated with a property specified by `property_id`. It returns an `Option<PropertyImage>` to gracefully handle cases where images may be unavailable.

**Retrieve Total Listed Properties: `total_property_listed`**

```
#[storage(read)]
fn total_property_listed() -> u64;
```

The `total_property_listed` function provides the total count of listed properties, offering a comprehensive view of the decentralized accommodations landscape.

**Retrieve Total Bookings: `total_booking`**

```
#[storage(read)]
fn total_booking() -> u64;
```

Lastly, the `total_booking` function furnishes the total count of bookings, shedding light on the bustling activity within our Web3 hotel booking contract.

## Complete code

Here’s the complete code for `src/interface.sw` file.

```
library;

use ::data_structures::{
    booking_info::BookingInfo,
    property_info::PropertyInfo,
    property_image::PropertyImage,
};

abi HotelBooking {
    
    #[storage(read, write)]
    fn list_property(pincode: u64,image1: b256, image2: b256);
   
    #[storage(read, write)]
    fn unlist_property(property_id: u64);

    #[storage(read, write)]
    fn book(property_id: u64, bookingFrom: u64, bookingTo: u64);
}

abi Info {

    #[storage(read)]
    fn booking_info(booking_id: u64) -> Option<BookingInfo> ;

    #[storage(read)]
    fn property_info(property_id: u64) -> Option<PropertyInfo>;

    #[storage(read)]
    fn get_property_images(property_id: u64) -> Option<PropertyImage>;

    #[storage(read)]
    fn total_property_listed() -> u64;

    #[storage(read)]
    fn total_booking() -> u64;

}
```

## That’s a wrap

As we conclude this exploration, remember that these ABIs serve as gateways, allowing external entities to seamlessly interact with our decentralized accommodations ecosystem. Next, we will conclude our Airbnb development by coding the Main file.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/3.%20Start%20Writing%20the%20Sway%20DApp/4.%20Building%20Airbnb%20Interface%20Property%20Booking%20and%20Info.md

Building Airbnb Interface: Property Booking and Info

# Create the Main File

Welcome to the heart of our Airbnb dApp! In this lesson, we'll start coding the `main.sw` file, the heart of our Web3 Airbnb dApp in the Sway programming language.

## Start coding

Create the `main.sw` file in the `src` directory and start coding. We will write and explain the code line by line for you to understand everything in detail.

### Defining Contract Type

```
contract;
```

Here, we initiate our journey by declaring the type of our program. The `contract` keyword signals that we are crafting a smart contract, a cornerstone in the realm of decentralized applications.

### Importing Essential Modules

```
mod data_structures;
mod errors;
mod events;
mod interface;
```

Here we are importing all the libraries we have created so far. These libraries cover data structures, error handling, events, and interface definitions.

### Storage Structure

```
storage {
    // StorageMap to track booking history
    booking_history: StorageMap<(Identity, u64), u64> = StorageMap {},

    // StorageMap to track property availability
    property_availability: StorageMap<(u64, u64, u64), bool> = StorageMap {},

    // StorageMap to store property information
    property_info: StorageMap<u64, PropertyInfo> = StorageMap {},

    // StorageMap to store property images
    property_images: StorageMap<u64, PropertyImage> = StorageMap {},

    // StorageMap to store booking information
    booking_info: StorageMap<u64, BookingInfo> = StorageMap {},

    // Counter for total listed properties
    total_property_listed: u64 = 0,

    // Counter for total bookings
    total_booking: u64 = 0,
}
```

Our storage section establishes the foundation for preserving essential data on the blockchain. We employ `StorageMap` structures to efficiently manage booking history, property availability, property information, property images, booking information, and counters for total properties and bookings.

### Contract Implementation: HotelBooking

```
impl HotelBooking for Contract {
    // ... (see details below)
}
```

The `HotelBooking` trait implementation encompasses essential functions for listing properties, unlisting properties, and making bookings. These functions play a pivotal role in orchestrating the interactions within our decentralized accommodations ecosystem.

**Listing a Property: `list_property`**

```
swayCopy code
#[storage(read, write)]
fn list_property(pincode: u64, image1: b256, image2: b256) {
    let owner = msg_sender().unwrap();

    let property_info = PropertyInfo::new(owner, pincode);
    let property_images = PropertyImage::new(image1, image2);

    storage.total_property_listed.write(storage.total_property_listed.read() + 1);
    storage.property_info.insert(storage.total_property_listed.read(), property_info);

    // Store the image references
    storage.property_images.insert(storage.total_property_listed.read(), property_images);

    // We have changed the state by adding a new data structure therefore we log it
    log(PropertyListed {
        owner,
        property_info,
        property_id: storage.total_property_listed.read(),
    });
}

```

Here, we introduce the `list_property` function, allowing users to list a new property. Let's break it down:

- `let owner = msg_sender().unwrap();`: Retrieve the owner's identity from the transaction sender.
- `let property_info = PropertyInfo::new(owner, pincode);`: Create a new `PropertyInfo` instance with the owner's identity and pincode.
- `let property_images = PropertyImage::new(image1, image2);`: Create a new `PropertyImage` instance with the provided image references.
- `storage.total_property_listed.write(storage.total_property_listed.read() + 1);`: Increment the total listed properties counter.
- `storage.property_info.insert(storage.total_property_listed.read(), property_info);`: Store property information in the `property_info` map.
- `storage.property_images.insert(storage.total_property_listed.read(), property_images);`: Store property images in the `property_images` map.
- `log(PropertyListed { ... });`: Log the property listing event, capturing owner details, property information, and the assigned property ID.

**Unlisting a Property: `unlist_property`**

```
swayCopy code
#[storage(read, write)]
fn unlist_property(property_id: u64) {
    // Retrieve the property in order to check its data / update it
    let mut property_info = storage.property_info.get(property_id).try_read().unwrap();

    // Only the creator (author) of the property can unlist it
    require(property_info.owner == msg_sender().unwrap(), UserError::UnauthorizedUser);

    // Mark the property as unlisted
    property_info.listed = PropertyState::Unlisted;

    storage.property_info.insert(property_id, property_info);

    // We have updated the state of a property therefore we must log it
    log(PropertyUnlisted { property_id });
}
```

Here, we introduce the `unlist_property` function, allowing users to unlist a property. Let's break it down:

- `let mut property_info = storage.property_info.get(property_id).try_read().unwrap();`: Retrieve the property information to check and update its data.
- `require(property_info.owner == msg_sender().unwrap(), UserError::UnauthorizedUser);`: Ensure that only the owner can unlist the property, else throw an unauthorized user error.
- `property_info.listed = PropertyState::Unlisted;`: Mark the property as unlisted.
- `storage.property_info.insert(property_id, property_info);`: Update the property information in the storage map.
- `log(PropertyUnlisted { property_id });`: Log the property unlisting event, capturing the property ID.

**Booking a Property: `book`**

```
#[storage(read, write)]
fn book(property_id: u64, bookingFrom: u64, bookingTo: u64) {
    //Booking date check
    require(bookingFrom >= height().as_u64(), CreationError::BookingDateMustBeInFuture );
    require(bookingTo >= height().as_u64(), CreationError::BookingDateMustBeInFuture );
    
    // Retrieve the property in order to check its data / update it
    let mut property_info = storage.property_info.get(property_id).try_read().unwrap();
    let mut bookedBy = msg_sender().unwrap();

    //check if the property is listed or not
    require(property_info.listed != PropertyState::Unlisted, BookingError::PropertyNotFound);
    //check if the property is booked or available
    require(property_info.available != BookingState::Booked, UserError::PropertyNotAvailable);
    
    //Create the booking info
    let booking_info = BookingInfo::new(bookedBy, bookingFrom, bookingTo, property_id);

    storage.total_booking.write(storage.total_booking.read() + 1);
    storage.booking_info.insert(storage.total_booking.read(), booking_info);
    storage.booking_history.insert((bookedBy, property_id), storage.total_booking.read());
    storage.property_availability.insert((property_id, bookingFrom, bookingTo), false);

    //Mark property as booked
    property_info.available = BookingState::Booked;

    storage.property_info.insert(property_id, property_info);

    // We have updated the state of a booking therefore we must log it
    log(BookingSuccessful { 
        booking_id: storage.total_booking.read(), 
        bookedBy, 
        bookingFrom, 
        bookingTo });
}
```

Here, we introduce the `book` function, orchestrating the booking process. Let's break it down:

- Booking date checks: Ensure booking dates are in the future.
- `let mut property_info = storage.property_info.get(property_id).try_read().unwrap();`: Retrieve the property information to check and update its data.
- `let mut bookedBy = msg_sender().unwrap();`: Retrieve the identity of the user booking the property.
- Check property availability and status:
    - `require(property_info.listed != PropertyState::Unlisted, BookingError::PropertyNotFound);`: Ensure the property is listed.
    - `require(property_info.available != BookingState::Booked, UserError::PropertyNotAvailable);`: Ensure the property is available for booking.
- Create booking information and update storage:
    - `let booking_info = BookingInfo::new(bookedBy, bookingFrom, bookingTo, property_id);`: Create a new `BookingInfo` instance.
    - Update counters and storage maps:
        - `storage.total_booking.write(storage.total_booking.read() + 1);`: Increment the total bookings counter.
        - `storage.booking_info.insert(storage.total_booking.read(), booking_info);`: Store booking information.
        - `storage.booking_history.insert((bookedBy, property_id), storage.total_booking.read());`: Log the booking in the history map.
        - `storage.property_availability.insert((property_id, bookingFrom, bookingTo), false);`: Mark the property as unavailable for the booked period.
        - `property_info.available = BookingState::Booked;`: Mark the property as booked.
        - `storage.property_info.insert(property_id, property_info);`: Update the property information in the storage map.
    - `log(BookingSuccessful { ... });`: Log the successful booking event, capturing the booking ID, booker details, and booking period.

### Contract Implementation: Info

```
impl Info for Contract {
    // ... (see details below)
}
```

The `Info` trait implementation provides functions to retrieve information about bookings, property details, property images, total listed properties, and total bookings.

**Retrieve Booking Information: `booking_info`**

```
#[storage(read)]
fn booking_info(booking_id: u64) -> Option<BookingInfo> {
    storage.booking_info.get(booking_id).try_read()
}
```

Here, we introduce the `booking_info` function, allowing users to retrieve booking details based on the booking ID. It utilizes the `try_read` method to safely access the storage map.

**Retrieve Property Information: `property_info`**

```
#[storage(read)]
fn property_info(property_id: u64) -> Option<PropertyInfo> {
    storage.property_info.get(property_id).try_read()
}
```

The `property_info` function enables users to retrieve property details based on the property ID. Like `booking_info`, it utilizes the `try_read` method for safe access.

**Retrieve Property Images: `get_property_images`**

```
#[storage(read)]
fn get_property_images(property_id: u64) -> Option<PropertyImage> {
    storage.property_images.get(property_id).try_read()
}
```

The `get_property_images` function facilitates the retrieval of property images based on the property ID. It employs the `try_read` method for secure access to the storage map.

**Retrieve Total Listed Properties: `total_property_listed`**

```
#[storage(read)]
fn total_property_listed() -> u64 {
    storage.total_property_listed.read()
}
```

The `total_property_listed` function provides the total count of listed properties, offering a comprehensive view of the decentralized accommodations landscape.

**Retrieve Total Bookings: `total_booking`**

```
#[storage(read)]
fn total_booking() -> u64 {
    storage.total_booking.read()
}
```

The `total_booking` function furnishes the total count of bookings, shedding light on the bustling activity within our Web3 hotel booking contract.

## Complete code

You can find the complete code of `src/main.sw` file here: [https://github.com/0xmetaschool/airbnb-contract/blob/main/src/main.sw](https://github.com/0xmetaschool/airbnb-contract/blob/main/src/main.sw)

You can find all the code files we have discussed so far here: https://github.com/0xmetaschool/airbnb-contract

## That’s a wrap

Stay tuned as we continue our exploration, unraveling the intricate dance of decentralized accommodations in the Web3 era!

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/3.%20Start%20Writing%20the%20Sway%20DApp/5.%20Create%20the%20Main%20File.md

Create the Main File

# Set Up the Fuel Wallet

Awesome work till now. Now we are one step closer to deploying our dApp. Let’s quickly set up our wallet too!

Open a new terminal in your `airbnb-contract` directory and complete the following steps:

1. Initialize a new wallet: 
    
    ```
    forc wallet new
    ```
    
    - You will be prompted to enter a password. Set the password for this and confirm it.
    - After setting the password, you will see the mnemonic phrase in the output. Save it somewhere safe. DO NOT SHARE IT WITH ANYONE! These phrases are private information that can be used to hack your account. We will also need it to import our wallet so make sure to save it.
    - Hit the Enter/return button.
    
2. Create a new account:
    
    ```
    forc wallet account new
    ```
    
    - You will be prompted to enter the password you set in the previous step. Enter it and press the Enter/return button. Make sure to save your Wallet mnemonic phrase
    - You will get your fuel address. Save it as you'll need it to sign transactions to deploy the contract.
    
    ![Frame 3560370 (10).jpg](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/Frame_3560370_(10).jpg?raw=true)
    

3. You can view your list of accounts using the command below:
    
    ```
    forc wallet accounts
    ```
    

## Importing CLI Wallet to Fuel Wallet

- Go to [Fuel Wallet Chrome Extension](https://chromewebstore.google.com/detail/fuel-wallet/dldjpboieedgcmpkchcjcbijingjcgok) and click on “Add to Chrome” button.
- After Installing Fuel Wallet, you will see a popup tab where you need to click on “Import seed phrase” button.
    
    ![wallet-1.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-1.png?raw=true)
    
- Check the terms and condition checkbox and click on “Next: Seed Phrase” button.
    
    ![wallet-2.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-2.png?raw=true)
    

- Now select “I have a 24-word Seed Phrase”, paste your Wallet Mnemonic Phrase and click on the “Next: Your password” button.
    
    ![wallet-3.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-3.png?raw=true)
    

- Now finally set a password for your wallet, make sure it is a strong password, or else you won’t be allowed to move forward and please make a note of your password because trust me you need this whenever you are going to sign a transaction. Click on “Next: Finish set up” button to move forward.
    
    ![wallet-4.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_petition_fuel/Setup%20Fuel%20Wallet/wallet-4.png?raw=true)
    

- And we are all set, let now move on to top it up with some faucet ETH because we will be needing this to pay for the gas.

**Note:** Your wallet might not show the same wallet address as shown on your terminal. So, remember to use the wallet address shown on the terminal to get some fake tokens.

## Get some tokens

Now it’s time to get some fake money in your wallet. Follow the steps given below to get some tokens:

1. Head over to [https://faucet-testnet.fuel.network/](https://faucet-testnet.fuel.network/).
2. Paste your wallet address. 
3. Submit the CAPTCHA.
4. Click on the “Give me Ether” button.
5. You will receive 0.01 ETH in your wallet.

## Wrap up

In this lesson, we learned how to set up our wallet, create a new account, and obtain our fuel address. We also learned how to get tokens from a faucet. Now we can proceed with deploying our contract. Let's move on to the next step!


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/4.%20Deploy%20the%20DApp/1.%20Set%20Up%20the%20Fuel%20Wallet.md

Set Up the Fuel Wallet

# Deploy the DApp on the Fuel Blockchain

Kudos to you for making it so far! Now we will finally deploy our dApp on the Fuel blockchain. 

## Deploy the dApp

Open a new terminal in your Blockstay-dApp directory or continue using the previous terminal if opened. 

Run the following command to build your files:

```
forc build
```

Now let’s deploy the dApp using the following command:

```
forc deploy --testnet
```

- Once you use this command, it will ask you your password of the wallet.
- After you provide the correct password, you will then be asked to provide the index of the account to use for signing - here you can write **0**.
- Lastly, you will be asked if you agree to sign this transaction. You can type **y** to approve the transaction.

The output should look like so: 

 

![Screenshot (14).png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Deploy%20the%20DApp%20on%20the%20Fuel%20Blockchain/Screenshot_(14).png?raw=true)

## That’s a wrap

In conclusion, we learned how to deploy a dApp on the Fuel blockchain. We built our files using `forc build` and deployed the dApp using `forc deploy --testnet`. Now, let's add the frontend to our dApp.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/4.%20Deploy%20the%20DApp/2.%20Deploy%20the%20DApp%20on%20the%20Fuel%20Blockchain.md

Deploy the DApp on the Fuel Blockchain

# Set Up the Frontend

Kudos! We have deployed our dApp and we are all set to proceed in setting up our frontend. No more waiting, let’s go!

## Clone the Airbnb frontend

Open a new terminal in your `airbnb-dapp` folder, outside of the `airbnb-contract` directory. 

Run the following command to clone the frontend directory:

```
git clone https://github.com/0xmetaschool/fuel-airbnb-frontend-boilerplate.git
```

## Set up environment variables

Now, after cloning the app, open the open in your IDE and find `.env` file. The .env file will look like this.

```
REACT_APP_CONTRACT_ID=YOUR_AIRBNB_DEPLOYED_CONTRACT_ID
REACT_APP_PINATA_SECRET_API_KEY=YOUR_PINATA_API_SECRET_KEY
REACT_APP_PINATA_API_KEY=YOUR_PINATA_API_KEY
```

Let’s go through how to fill these environment variables.

### Contract ID

In the last lesson, you must have copied the deployed contract ID. So, replace `YOUR_AIRBNB_DEPLOYED_CONTRACT_ID` with your contract ID here.

### Pinata API credentials

Next, we need Pinata API credentials. Follow the following steps to get one.

1. **Set up a Pinata account:** Head over to [Pinata](https://www.pinata.cloud/) and create a free account.
    1. Click on the “Start Building” button. It will take you to the signup page.
    2. Enter your email address, select “Builder” in the title section, and move “Next.”
    3. Set your first name, last name, and password.
    4. Confirm your email by entering the confirmation code.
    5. Your Pinata profile is ready to go. Here’s what it will look like:
        
        ![pinata-1.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Frontend/pinata-1.png?raw=true)
        

1. **Set up API keys:** Head over to the “API Keys” option from the sidebar. 
    1. Click on the “New Key” option.
    2. Write the key name. 
    3. Select the “Admin” option for the Scopes section.
    4. Lastly, simply click on the “Generate API Key” button. Here’s how we’re doing it.
        
        ![pinata-2.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Frontend/pinata-2.gif?raw=true)
        

After clicking on the Generate API Key” button. The page will appear that will display the “API Key” and the “Secret API Key”. Copy these keys and place them respectfully in the `.env` file.

## Install dependencies

Now, Move to the `fuel-airbnb-frontend-boilerplate` folder and install the dependencies:

```
cd fuel-airbnb-frontend-boilerplate
npm install
npm install buffer
npm install fuels@0.60.0 @fuel-wallet/sdk@0.13.0 --save
```

## Setup the ABI JSON files

Time to move our ABI JSON files to the front end of the `airbnb-contract` project. To do this, we will run the following command inside of the `fuel-airbnb-frontend-boilerplate` folder. This command will execute the `fuel.config.ts` file.

```
npx fuels build
```

This will add the `contracts` folder to your `src`:

![contracts-folder.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Frontend/contracts-folder.png?raw=true)

## Run the frontend

Now run the following command to start your app:

```
npm start
```

You will see an output like this:

![fuel-c2-output.png](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Set%20Up%20the%20Frontend/fuel-c2-output.png?raw=true)

## That’s a wrap

In this lesson, we learned how to set up the front end for our dApp. We cloned the frontend directory, installed dependencies, and moved the ABI JSON files. Congratulations on completing this lesson and setting up your dApp's front end! Happy coding!

In the next lesson, we will interact with our dApp.


https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/5.%20Work%20with%20the%20Frontend/1.%20Set%20Up%20the%20Frontend.md

Set Up the Frontend

# Interact with the DApp

Before starting this section, we would like to remind you that you have been doing great so far, and congratulations on reaching almost the end of the course. 

We will now be interacting with our DApp through the front end we created in earlier lessons. So, let’s get started. 

Firstly, you will need to connect your Fuel wallet to your dApp. This would allow you to carry out different actions and sign transactions according to your purpose. Remember to select the "Fuel Wallet" from the list of wallets.

![ezgif.com-optimize.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Interact%20with%20the%20DApp/ezgif.com-optimize.gif?raw=true)

You can see above that your wallet has now been connected to your dApp. Now let’s start with the more fun part. 

- Imagine you want to list a property for sale in our Blockstay dApp. You can simply do that by clicking on **List** and filling in the necessary details like so:

![fuel-listing-full.gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Interact%20with%20the%20DApp/fuel-listing-full.gif?raw=true)

Here you need to upload your PIN code, and two images to be able to list a property. This would then be ready for booking. 

Lastly, we should also be able to book a property. You can do this by going to Book from where you will see different property options available. You can choose to reserve this by providing the dates. 

![ezgif.com-video-to-gif (1).gif](https://github.com/0xmetaschool/Learning-Projects/blob/main/assests_for_all/assets_for_airbnb_fuel/Interact%20with%20the%20DApp/ezgif.com-video-to-gif_(1).gif?raw=true)

## Wrap up

As a developer, one of the most exciting aspects of their work is seeing their products in live action. We hope you had lots of fun seeing the working of the dApp you created in real time. Do share with us the links to your dApp.

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/6.%20Run%20the%20DApp/1.%20Interact%20with%20the%20DApp.md

# Wrap Up

Congratulations on reaching the end of the course where you learned to build your own Airbnb dApp on Fuel blockchain. Take a moment and pat on your back for the dedication you have shown to reach till here. Before we let you go to build amazing new dApps, let's recap what we have learned in this course.

## Key Learnings:

1. **Development Environment Setup:**
    - Set up the Fuel toolchain and ensure your development environment is ready for creating decentralized applications.
2. **Smart Contract Development:**
    - Progressed through the step-by-step process of coding a smart contract for the airbnb dApp.
3. **Frontend Integration:**
    - Created a frontend for your dApp, showcasing the seamless interaction between smart contracts and user interfaces.
4. **Interaction:**
    - Learned how to interact with your dApp, ensuring that it performs as expected.

## ⚒️ A small yet important request:

This is a 100% open-source project like all the other projects on our platform. You can find the tutorial markdown files [here](https://github.com/0xmetaschool/Learning-Projects/tree/main/Build%20Airbnb%20on%20Fuel%20Network). If you find any issues in the course, please feel free to resolve it. We, at Metaschool, love love love contributions by our community and acknowledge the contributors on our [Discord](https://discord.com/invite/vbVMUwXWgc) and GitHub, too.

While you’re contributing:

1. Don’t forget to star ⭐️ our repository. We will be very thankful! ❤️
2. We are a completely free platform and we aim to stay the same, so please consider following us on [X](https://bit.ly/airbnb-dapp-fuel-twitter) and [LinkedIn](https://bit.ly/airbnb-dapp-fuel-linkedin) as well. 🫶



## 🎊 Congratulations

Thank you for joining us on this exciting journey into the world of Fuel and decentralized applications. Your commitment to learning and building in the blockchain space is commendable. Best of luck in all your future endeavors as you continue to shape the future of decentralized technologies!

WAGMI! Peace out! ✌🏻🔮

https://raw.githubusercontent.com/0xmetaschool/Learning-Projects/main/Build%20Airbnb%20on%20Fuel%20Network/7.%20Wrap%20It%20Up/1.%20Wrap%20Up.md

Warden Protocol

30 days of solidity

Fuel Marathon

Aptos Marathon

Core Marathon

Sui Marathon

Build on Modular Blockchains with Fuel Network

Understand the Fundamentals of Fuel

Build a Petition Filing dApp on the Fuel Network

What you’ll learn

Build an Airbnb dApp on Fuel Network

What you’ll learn

Build on Modular Blockchains with Fuel Network

Understand the Fundamentals of Fuel

Build a Petition Filing dApp on the Fuel Network

What you’ll learn

Show Details

Build an Airbnb dApp on Fuel Network

What you’ll learn

Show Details