
## **Introduction**

In the world of programming, errors are inevitable. Rust, a modern systems programming language, takes a unique approach to error handling by categorizing errors into two main types: **unrecoverable** and **recoverable**. This distinction allows developers to manage errors more effectively, ensuring robust and reliable code.

### **Unrecoverable Errors: The Power of Panic!**

Unrecoverable errors are those that occur when something goes fundamentally wrong, and the program cannot safely proceed. For example, if a file that is essential for the program to run is missing or corrupted, the program can panic and display an appropriate error message. Rust provides a mechanism for handling such situations through the **`panic!`** macro. When a **`panic!`** occurs, the program stops execution, unwinding the stack and providing a clear panic message.

```rust
fn main() {
    let divisor = 0;

    if divisor == 0 {
        panic!("Division by zero error occurred!");
    }

    let result = 10 / divisor;
    println!("Result: {}", result);
}
```

While panicking is not a solution for every error, it's a powerful tool for signaling critical issues and preventing the program from continuing in an undefined state.

### **Recoverable Errors: Embracing `Option` and `Result`**

In contrast to unrecoverable errors, recoverable errors are situations where the program can gracefully handle the issue and proceed with execution. Rust provides two main types to address these errors: **`Option`** and **`Result`**.

### Working with **`Option`**

**`Option`** is used when a computation might return a value or nothing. It prevents the need for null or undefined values, enhancing the safety of the code.

```rust
fn find_element(arr: &[i32], target: i32) -> Option<usize> {
    for (i, &elem) in arr.iter().enumerate() {
        if elem == target {
            return Some(i);
        }
    }
    None
}

fn main() {
    let arr = [1, 2, 3, 4, 5];
    let target = 3;

    match find_element(&arr, target) {
        Some(index) => println!("Element found at index: {}", index),
        None => println!("Element not found"),
    }
}
```

### Working with **`Result`**

**`Result`** is similar to **`Option`** but includes an **`Err`** variant to hold information about the error that occurred. This makes it suitable for functions that may return an error.

```rust
use std::fs::File;

fn open_file(file_path: &str) -> Result<File, std::io::Error> {
    File::open(file_path)
}

fn main() {
    let file_path = "example.txt";
    match open_file(&file_path) {
        Ok(file) => {
            // File opened successfully, continue with further operations
            println!("File opened successfully!");
            // ...
        }
        Err(error) => {
            // Error occurred while opening the file, handle it appropriately
            println!("Error opening file: {}", error);
            // ...
        }
    }
}

```

### **`unwrap` and `expect`: Proceed with Caution**

The **`unwrap`** and **`expect`** methods are convenient but should be used judiciously. They extract the value from **`Option`** or **`Result`** and panic if the value is **`None`** or **`Err`**. While they can simplify code, excessive use may lead to unexpected panics.

```rust
use std::fs::File;

fn open_file(file_path: &str) -> Result<File, std::io::Error> {
    File::open(file_path)
}

fn main() {
    let file_path = "example.txt";
    let file = open_file(&file_path).unwrap();

    println!("File opened successfully!");
}
```

### **Early-Return Error Handling with `?`**

The **`?`** operator provides a concise way to propagate errors early in a function. It can be used with functions that return **`Result`** or **`Option`**, automatically unwrapping the value or returning early on an error.

```rust
use std::fs::File;
use std::io::{self, Read};

// A function that reads a file and returns the content as a String
fn read_file_content(file_path: &str) -> Result<String, io::Error> {
    // Attempt to open the file
    let mut file = File::open(file_path)?;

    // Read the content of the file into a String
    let mut content = String::new();

    // Use the ? operator to handle the Result returned by read_to_string
    // If an error occurs, it is returned immediately.
    file.read_to_string(&mut content)?;

    // Return the content
    Ok(content)
}

fn main() {
    // Specify the file path
    let file_path = "example.txt";

    // Attempt to read the file and handle the result
    match read_file_content(file_path) {
        Ok(content) => {
            println!("File content:\n{}", content);
        }
        Err(error) => {
            eprintln!("Error reading the file: {}", error);
            // Handle the error as needed
        }
    }
}
```

### **Handling Multiple Errors: Creating Custom Errors**

Up until now, our focus has been on handling a single error. However, what if your function has the potential to return multiple errors, and you want the caller to precisely identify and handle each error scenario? In such cases, Rust allows you to implement your own custom error types.

```rust
#[derive(Debug)]
enum MyError {
    Io(std::io::Error),
    Parse(std::num::ParseIntError),
}

fn read_and_parse(path: &str) -> Result<i32, MyError> {
    let file_content = std::fs::read_to_string(path);

    match file_content {
        Ok(file_content) => match file_content.trim().parse::<i32>() {
            Ok(num) => Ok(num),
            Err(err) => Err(MyError::Parse(err)),
        },
        Err(err) => Err(MyError::Io(err)),
    }
}

fn main() {
    let file_path = "example.txt";

    match read_and_parse(file_path) {
        Ok(parsed_value) => {
            println!("File content parsed successfully: {}", parsed_value);
        }
        Err(my_error) => {
            eprintln!("Error: {:?}", my_error);

            // You can also perform specific error handling based on the error variant
            match my_error {
                MyError::Io(io_error) => {
                    eprintln!("IO Error Details: {}", io_error);
                    // Additional IO error handling logic can be added here
                }
                MyError::Parse(parse_error) => {
                    eprintln!("Parse Error Details: {}", parse_error);
                    // Additional parse error handling logic can be added here
                }
            }
        }
    }
}
```

Notice that we can't use **?** on **std::fs::read_to_string(path)** because if an error occurs, **?** will attempt to convert the errors (std::io::Error or std::num::ParseIntError) to our custom error, MyError. However, it doesn't know how to perform this conversion. To address this, we have to implement the `From` trait on our custom error.

```rust
impl From<std::io::Error> for MyError {
    fn from(err: std::io::Error) -> MyError {
        MyError::Io(err)
    }
}

impl From<std::num::ParseIntError> for MyError {
    fn from(err: std::num::ParseIntError) -> MyError {
        MyError::Parse(err)
    }
}

// We can finally rewrite read_and_parse
fn read_and_parse(path: &str) -> Result<i32, MyError> {
    let file_content = std::fs::read_to_string(path)?;
    let num = file_content.trim().parse::<i32>()?;
    Ok(num)
}
```

## **Making Your Error Composable**

While our custom error solution is functional, seasoned developers often recommend implementing the **`std::error::Error`** trait for custom errors. By embracing this practice, our error becomes easily composable with other parts of the program, offering users the ability to obtain a string representation of an error. This is achieved by ensuring implementations for both **`fmt::Debug`** and **`fmt::Display`** are provided.

```rust
#[derive(Debug)]
enum MyError {
    Io(std::io::Error),
    Parse(std::num::ParseIntError),
}

impl std::error::Error for MyError {
    fn source(&self) -> Option<&(dyn std::error::Error + 'static)> {
        match self {
            MyError::Io(err) => Some(err),
            MyError::Parse(err) => Some(err),
        }
    }
}

impl std::fmt::Display for MyError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        match self {
            MyError::Io(err) => write!(f, "IO error: {}", err),
            MyError::Parse(err) => write!(f, "Parse error: {}", err),
        }
    }
}
```

## References:

- https://doc.rust-lang.org/book/ch09-00-error-handling.html
- https://blog.burntsushi.net/rust-error-handling/


nrecoverable errors are those that occur when something goes fundamentally wrong, and the program cannot safely proceed. For example, if a file that is essential for the program to run is missing or corrupted, the program can panic and display an appropriate error message. Rust provides a mechanism for handling such situations through the **`panic!`** macro. When a **`panic!`** occurs, the program stops execution, unwinding the stack and providing a clear panic message...

Error handling on Rust


Rust's **trait** system is a powerful feature that enables developers to define shared behavior across different types. Traits play a crucial role in achieving code reusability, abstraction, and flexibility.

## Understanding traits

In Rust, a trait is a collection of methods that can be implemented by types to define shared behavior. Think of traits as a way to express what abilities a type should have, without dictating its internal structure. This promotes a high degree of abstraction and allows for code that is more generic and adaptable.
Traits are similar to a feature often called `interfaces` in other languages, although with some differences.

```rust
trait Shape {
    fn area(&self) -> f64;
}
```

In the example above, we define a trait named `Shape` with a single method, `area`. This trait can then be implemented by various types to provide their own implementation of the `area` method.

## Implementing traits

To use a trait, a type must implement it by providing its own implementation for each of the trait's methods. This is achieved through the `impl` keyword.

```rust
struct Circle {
    radius: f64,
}

impl Shape for Circle {
    fn area(&self) -> f64 {
        std::f64::consts::PI * self.radius * self.radius
    }
}

```

Now, instances of `Circle` can leverage the functionality provided by the `Shape` trait.

## Default implementation

Rust allows you to provide default implementations for trait methods. This means that implementing types can choose to override the default behavior if needed. Let's enhance our `Shape` trait with a default method for `perimeter`:

```rust
trait Shape {
    fn area(&self) -> f64;

    fn perimeter(&self) -> f64 {
        0.0 // Default implementation for perimeter
    }
}

struct Circle {
    radius: f64,
}

impl Shape for Circle {
    fn area(&self) -> f64 {
        std::f64::consts::PI * self.radius * self.radius
    }
}

```

Now, any type implementing `Shape` will automatically have a default `perimeter` method, but it can choose to provide its own implementation.

## Trait as parameters

Traits can be used as parameters to functions, enabling polymorphism and enhancing the flexibility of your code. Consider a function that calculates and prints the area of any type implementing the `Shape` trait:

```rust
fn print_area(shape: impl Shape) {
    println!("Area: {}", shape.area());
}

fn main() {
    let circle = Circle { radius: 3.0 };
    print_area(circle);
}
```

Here, the `print_area` function takes any type that implements the `Shape` trait as a parameter. This allows us to use the function with various shapes without modifying its code.

## Trait bound

To make functions even more flexible, you can use trait bounds to specify that a generic type must implement a certain trait. For instance:

```rust
fn print_area<T: Shape>(shape: T) {
    println!("Area: {}", shape.area());
}

fn main() {
    let circle = Circle { radius: 3.0 };
    print_area(circle);
}
```

Now, the `print_area` function can accept any type `T` as long as it implements the `Shape` trait.

## Conclusion

Traits in Rust provide a powerful mechanism for defining shared behavior, promoting code reuse and adding polymorphism in our code. By understanding how to implement traits, provide default behavior, use traits as parameters, and apply trait bounds, you can leverage this feature to write more modular and adaptable Rust code.


Rust's **trait** system is a powerful feature that enables developers to define shared behavior across different types. Traits play a crucial role in achieving code reusability, abstraction, and flexibility...

Rust trait


When working with websites and managing the computers that show them, we run into two important ideas: redirect URLs and rewrite URLs. These ideas are like tools that help us make websites work better for people. They help us make websites easier to find on search engines, and they help us make the paths on websites smoother. In this guide, we're going to explore these tools together. We'll learn what makes them different and how we can use them to make websites even cooler.

## Redirect URLs: navigating the path

A redirect URL is a technique used to guide users from one URL to another, often due to a webpage's relocation, restructuring, or a change in content. Imagine it as a virtual signpost that ensures visitors reach their desired destination without wandering in the digital wilderness. Redirects come in various flavors, but the two most common types are:

### 1. 301 permanent redirect

The 301 redirect is a magician's wand for SEO. It indicates that a page has moved permanently to a new location, preserving almost all of its link equity and SEO juice. This not only assists users in finding the new location but also guides search engines to update their indexes.

### 2. 302 temporary redirect

The 302 redirect is more like a "Come back soon" note. It informs browsers and search engines that a page has temporarily moved. While it does redirect users to a new location, it's not meant for permanent changes.

**How Redirect URLs Work: A Closer Look**

1. The user types a URL into the browser's address bar or clicks on a link.
2. The server follows predefined rules, directing requests for the URL to be externally redirected to a new URL. The server then instructs the user's browser to go to this new URL.
3. The browser automatically navigates to the new URL.
4. The server provides the browser with the content of the new URL, which users can then view in their browser.

## Rewrite URLs: crafting the illusion

If redirect URLs are signposts, then rewrite URLs are masterful illusions. URL rewriting involves modifying the URL that a user enters or clicks on, usually to make it more user-friendly, descriptive, or structured. This modification is typically done on the server side before the request is processed. The rewritten URL is then used to fetch the appropriate resource or content from the server.

### 1. clean URLs

Rewrite URLs can transform complex, dynamic URLs into clean, human-readable versions. For instance, converting `https://example.com/products.php?id=123` into `https://example.com/products/123`.

### 2. SEO enhancement

Clean, concise URLs not only appeal to users but also win favor with search engines. Rewriting URLs to include relevant keywords can boost SEO efforts and improve search engine ranking. For instance:

| Good URL                                                        | Bad URL                                                                                      |
| --------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| https://ahrefs.com/blog/seo-friendly-urls/                      | https://ahrefs.com/blog/seo-friendly-urls/?utm_source=google&utm_medium=cpc&utm_campaign=seo |
| https://moz.com/blog/15-seo-best-practices-for-structuring-urls | https://moz.com/blog/15-seo-best-practices-for-structuring-urls?ref=homepage&date=2023-09-05 |
| https://seranking.com/blog/create-seo-friendly-url/             | https://seranking.com/blog/index.php?post_id=1234&create-seo-friendly-url                    |

### 3. improved user experience

Rewrite URLs can enhance the user experience by making URLs more memorable, shareable, and aesthetically pleasing. A user is more likely to click on `https://example.com/contact` than a convoluted URL.

**How Rewrite URLs Work: A Closer Look**
Now, let's delve into the process of how URL rewriting works using an example:

1. The user types http://example.com/product/macbook-pro into the browser's address bar or clicks on a link.
2. The server follows predefined rules and rewrites http://my-app/product/macbook-pro to http://my-app/product?id=macbook-pro. The server processes the rewritten URL and returns the content to the browser.

## Key differences and how to choose

Redirect URLs and rewrite URLs share a common goal: to lead users to the right place. However, they achieve this goal differently:

- **Purpose**: Redirect URLs are about physically moving users from one URL to another, while rewrite URLs focus on altering the appearance of URLs.
- **Type of change**: Redirects involve a change in the browser's URL bar, while URL rewriting doesn't change the URL displayed in the browser.

- **HTTP response**: Redirects typically use HTTP status codes like 301 or 302, signaling browsers and search engines about the nature of the move. URL rewriting doesn't change the HTTP response.

**Choosing the Right Approach**: If you're moving or restructuring content, use redirect URLs. If you want cleaner, SEO-friendly URLs without changing the content's location, opt for URL rewriting.

## Conclusion

Redirect URLs and rewrite URLs are threads that weave together seamless user experiences, enhanced SEO, and organized website structures. By understanding the step-by-step processes of these techniques, you hold the power to guide users through the digital landscape and leave an indelible mark on the virtual world.

## References

- https://en.wikipedia.org/wiki/URL_redirection
- https://en.wikipedia.org/wiki/Rewrite_engine
- https://weblogs.asp.net/owscott/rewrite-vs-redirect-what-s-the-difference


When working with websites and managing the computers that show them, we run into two important ideas: redirect URLs and rewrite URLs. These ideas are like tools that help us make websites work better for people. They help us make websites easier to find on search engines, and they help us make the paths on websites smoother. In this guide, we're going to explore these tools together. We'll learn what makes them different and how we can use them to make websites even cooler.

URL Redirect vs. Rewrite; What’s the difference?


Scroll-driven animations are popular effects used in web design. They are animations that are connected to the scroll position of a scroll container. So, as you scroll up or down, the animation moves accordingly. For example, think of background images that move with your scroll or indicators that show your progress as you read through a page. Another type of scroll-driven animation is linked to an element's position within its scroll container. With this, elements can smoothly fade in as they become visible.

In the past, achieving these effects involved responding to scroll events on the main thread. However, this made it difficult to create smooth and synchronized animations. But now, thanks to the Scroll-driven Animations specification, you have access to new APIs and concepts that enable you to easily create declarative scroll-driven animations. These APIs work seamlessly with the Web Animations API and CSS Animations API.

## Animation timelines

By default, an animation attached to an element runs on the document timeline. Its origin time starts at 0 when the page loads, and starts ticking forwards as clock time progresses. This is the default animation timeline and, until now, was the only animation timeline you had access to.

The Scroll-driven Animations Specification defines two new types of timelines that you can use:

### Scroll progress timeline

A **Scroll progress timeline** is an animation timeline that is linked to progress in the scroll position of a scroll container–also called scrollport or scroller–along a particular axis. It converts a position in a scroll range into a percentage of progress.

The starting scroll position represents 0% progress and the ending scroll position represents 100% progress. In the following visualization, you can see that the progress counts up from 0% to 100% as you scroll the scroller from top to bottom.

<video src="https://storage.googleapis.com/web-dev-uploads/video/AeNB0cHNDkYPUYzDuv8gInYA9rY2/xdU4YJ6cxjNYpec1XcE6.mp4" controls></video>

Visualization of a Scroll progress timeline. As you scroll down to the bottom of the scroller, the progress value counts up from 0% to 100%. Source: https://developer.chrome.com/articles/scroll-driven-animations/

### View progress timeline

A **View progress timeline** is an animation timeline that is linked to the relative progress of a particular element within a scroll container.

Just like **IntersectionObserver**, this feature tracks how much of an element is visible in the scroller. If the element is completely hidden, it's not considered intersecting. But even if a small part of the element is visible, it's considered intersecting.

A View progress timeline starts when the subject enters the scroll container and ends when it leaves. In the visualization, the progress begins at 0% when the subject enters and reaches 100% when it exits the container.

<video src="https://storage.googleapis.com/web-dev-uploads/video/AeNB0cHNDkYPUYzDuv8gInYA9rY2/rvPTFW2277KBTuWiZFj1.mp4" controls></video>

Visualization of a View progress timeline. The progress counts up from 0% to 100% as the subject (green box) crosses the scroller. Source: https://developer.chrome.com/articles/scroll-driven-animations/

## Basic usage

To demonstrate the Scroll-driven Animations, we will re-create the animation from [this demo](https://codepen.io/chriscoyier/pen/mdVWgdN) without using any JavaScript. Let's grab some code from the original example:

```
<body>
  <svg width="100" height="100" viewBox="0 0 24 24">
  <path d="M21,9H15V22H13V16H11V22H9V9H3V7H21M12,2A2,2 0 0,1 14,4A2,2 0 0,1 12,6C10.89,6 10,5.1 10,4C10,2.89 10.89,2 12,2Z" />
</svg>
</body>
```

```
svg {
  position: fixed;
  top: 50%;
  left: 50%;
  margin-top: -50px;
  margin-left: -50px;
}

@keyframes rotate {
  to {
    transform: rotate(360deg);
  }
}

body {
  min-height: 500vh;
}
```

Our goal is to make the icon rotate based on the user's scrolling. To achieve this, we need to create a Scroll progress timeline using CSS. The simplest way to do this is by using the `scroll()` function. It allows us to create an anonymous Scroll Timeline, which we can then set as the value for the new `animation-timeline` property.

```
svg {
  ...
  animation: rotate auto linear;
  animation-timeline: scroll(root, block);
}
```

The `scroll()` function requires two arguments: `<scroller>` and `<axis>`. Here are the accepted values for each argument:

For the `<scroller>` argument:

**nearest**: Uses the nearest ancestor scroll container (default). **root**: Uses the document viewport as the scroll container. **self**: Uses the element itself as the scroll container.

For the `<axis>` argument:

**block**: Measures the progress along the block axis of the scroll container (default). **inline**: Measures the progress along the inline axis of the scroll container. **y**: Measures the progress along the y-axis of the scroll container. **x**: Measures the progress along the x-axis of the scroll container.

In our case, to bind an animation to the root scroller on the block axis, you can use the simplified syntax `scroll(root block)`. Also, note that when using a Scroll progress timeline, it does not make sense to set the `animation-duration` in seconds. Instead, you should set it to `auto`.

You can find the full code of this example at this [link](https://codepen.io/Levi-ackerman/pen/BaqeENy)

Note: Make sure you run this example in Chrome 115 or above with the 'Experimental Web Platform Features' enabled.

That's it! With just a few lines of CSS code, we've created an awesome scroll animation. You can create many amazing animations with Scroll-driven Animation. To discover more examples, please check the reference link.

## References

- https://scroll-driven-animations.style
- https://developer.chrome.com/articles/scroll-driven-animations
- https://www.youtube.com/watch?v=oDcb3fvtETs&t=335s


Scroll-driven animations are popular effects used in web design. They are animations that are connected to the scroll position of a scroll container.

Scroll-driven animations


I'm currently working on a new application called Javis, which operates as a Chrome extension. Functioning as an AI assistant, Javis is designed to facilitate a smooth and enriching web browsing experience for users. During its testing phase in Chrome, I faced a unique challenge - **Javis's CSS clashed with the webpage's CSS**. The result was a distortion of both the application's and the webpage's interfaces. Following a research, I unearthed a potent solution - the Shadow DOM. In this piece, I aim to explain the concept of Shadow DOM and shed light on the its advantage of encapsulating style.

## What is Shadow DOM?

Shadow DOM is a web standard that allows encapsulation of HTML, CSS, and JavaScript within a specific context. Shadow DOM allows hidden DOM trees to be attached to elements in the regular DOM tree — this shadow DOM tree starts with a shadow root, underneath which you can attach any element, in the same way as the normal DOM.

![](assets/shadow-dom.svg) Source: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM

There are some bits of shadow DOM terminology to be aware of:

- **Shadow host**: The regular DOM node that the shadow DOM is attached to.
- **Shadow tree**: The DOM tree inside the shadow DOM.
- **Shadow boundary**: the place where the shadow DOM ends, and the regular DOM begins.
- **Shadow root**: The root node of the shadow tree.

When working with the shadow DOM, you have the power to manipulate its nodes just like you would with non-shadow nodes. This includes appending children, setting attributes, and applying styles using `element.style.color` or a `<style>` element within the shadow DOM. The key distinction is that any code within the shadow DOM remains encapsulated, unable to affect elements outside of it, providing a valuable encapsulation feature.

## Basic usage

Now that we understand the importance of Shadow DOM, let's explore how to create and manipulate Shadow DOM. You can create Shadow Dom by attaching a shadow root to any element using the `Element.attachShadow()` method. This takes as its parameter an options object that contains one option — `mode` — with a value of `open` or `closed`:

```js
const shadowOpen = host.attachShadow({ mode: "open" });
const shadowClosed = host.attachShadow({ mode: "closed" });
```

- `open`: The shadow DOM/ internal DOM of the component is accessible from outside JavaScript.
- `closed`: The shadow DOM/ internal DOM of the component is not accessible outside JavaScript. The `<video>` tag is an example of closed-mode shadow root.

## Conclusion

Shadow DOM provides a powerful tool for developers creating website extensions, widgets, and similar interactive components. It offers the benefit of encapsulation, ensuring styles and scripts do not clash with the host page, that can significantly enhance the reliability and user experience of your applications.

## References

- https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM


Shadow DOM is a web standard that allows encapsulation of HTML, CSS, and JavaScript within a specific context.

Shadow DOM


With the rise of NFTs on the Solana blockchain, there is a growing demand for these digital assets to be as commonplace as any other item on the internet. This includes every single item in a game's inventory, proof of engagement in popular consumer apps, and even a personal profile for every human on Earth.

While the cost of renting NFTs on Solana is relatively cheap (at ◎0.012), it scales linearly, making it costly to have a large number of NFTs. However, through compression, the cost of on-chain storage for NFTs can be drastically reduced, enabling creators to fully leverage the technology to express themselves. For example, with compression, the cost of 10,000 NFTs at ◎3.5 (34x) reduces, as does the cost of 1 million NFTs at ◎5 (2,400x) and 1 billion NFTs at ◎500 (24,000x).

![](assets/metaplex-nft-compression-cost-comparation.webp)

## How compression for NFTs works

Compressed NFTs are stored in Merkle trees via the Gummyroll program where:

- Roots of Merkle trees are stored and updated on-chain in a buffer stored in a program account
- Modifications to a tree (e.g. mint, transfer, delegate) are encoded in the Solana ledger
- Off-chain indexers observe changes to the tree via the ledger and cache NFT-related metadata, and serve data and proofs needed to power dApps and smart contracts

The Merkle root's on-chain buffer in the Gummyroll program enables multiple write requests to a single Merkle tree to be processed simultaneously. As updates to the tree cause the root to change, the program ensures that outdated requests to update the tree remain valid if they would have updated a prior version of the tree, given the nature of how Merkle trees operate.

The implementation of Compression for NFTs will have a significant impact on the Solana ecosystem, and Metaplex is working towards making this a reality. To achieve this, Metaplex is collaborating with various partners, including wallets and RPCs. Some of the partners that have already implemented solutions include Solflare for wallets, Crossmint for enterprise tools, and GenysysGo and Triton for RPCs. Additionally, partners such as Phantom for wallets and Quicknode and Alchemy for RPCs are expected to launch their solutions soon.

![](assets/metaplex-nft-compression-how-it-work.png)

## Conclusion

This is just a brief overview of Compression for NFTs. There is much more to explore, whether from a technical perspective or in terms of potential use cases. Nevertheless, this technological advancement marks a significant shift in how users, developers, and businesses can approach NFTs in Solana blockchain.

## Reference

- https://www.metaplex.com/posts/expanding-digital-assets-with-compression-for-nfts
- https://metaplex.notion.site/Compression-for-NFTs-Public-94f9faa25f034110b513414a11a85bbe


Metaplex NFT compression is a technology that allows for the compression of NFTs on the Solana blockchain, reducing the cost of on-chain storage for NFTs. This article provides an overview of the technology, how it works, and its potential impact on the Solana ecosystem.

Metaplex NFT compression


Unlike most blockchain, Solana separates logic and data into two separate components: Program and Account. What that means is that instead of storing data inside variables internally, Programs interact with external data stored in Accounts with the ability to mutate them.

## Account model

There are 3 kinds of accounts:

- Data accounts store data (which we use the most).
  - System owned accounts.
  - PDA(Program Derived Address) accounts.
- Program accounts store executable programs.
- Native accounts that indicate native programs on Solana such as System, Stake and Vote.

Each account has an address (usually a public key) and an owner (address of a program account). The full field list an account stores is found below.

| Field      | Description                                    |
| ---------- | ---------------------------------------------- |
| lamports   | The number of lamports owned by this account   |
| owner      | The program owner of this account              |
| executable | Whether this account can process instructions  |
| data       | The raw data byte array stored by this account |
| rent_epoch | The next epoch that this account will owe rent |

## Ownership rules

There are a few important ownership rules:

- Only a data account's owner can modify its data and debit lamports.
- Anymore is allowed to credit lamports to a data account.
- The owner of an account may assign a new owner if the account's data is zeroed out.

Technically, the Programs are special kinds of Accounts marked as `executable` whose entire purpose is to store the compiled code of Program. The program accounts do not store state.

For example, if you create a counter program that lets you increment a counter, you must create two accounts, one account (account A) to store the program's code (`executable = true`), and one (account B) to store the counter value and account A must be the owner of account B.

![](assets/solana-account_account_example5b70d95ajpeg.webp)

## Rent

- Storing data on accounts costs SOL to maintain, and it is funded by what is called `rent`.
- An account is considered rent-exempt if it holds at least 2 years worth of rent. Currently, all new accounts are required to be rent-exempt.
- Use the `getMinimumBalanceForRentExemption` RPC endpoint to calculate the minimum balance for a particular account size.
- If the account does not have enough to pay rent, the account will be deallocated and the data removed.

## References

- https://docs.solana.com/developing/programming-model/accounts
- https://solanacookbook.com/core-concepts/accounts.html


This article provides an overview of Solana accounts, including their structure, types, and how they work.

Solana account


What makes a bad error message

- Inappropriate tone
- Technical jargon
- Passing the blame
- Generic for no reason

What makes a good error message

- Say what happened and why
- Provide reassurance
- Be empathetic
- Help them fix it
- Always give a way out

Reference: <https://wix-ux.com/when-life-gives-you-lemons-write-better-error-messages-46c5223e1a2f>

![](assets/202211081111-error-messaging_pasted-image-20221108111328.webp)
![](assets/202211081111-error-messaging_pasted-image-20221108111346.webp)


Error messaging


**Forward proxy**: is a server that sits between user devices and the internet.
uses for:

- protect clients
- avoid browsing restrictions
- block access to certain content

**Reverse proxy:** is a server that accepts a request from the client, forwards the request to web servers, and returns the results to the client as if the proxy server had processed the request.
uses for:

- Protect servers
- load balancing
- cache static contents
- encrypt and decrypt SSL communications

Credit: https://blog.bytebytego.com/p/ep25-proxy-vs-reverse-proxy

![](assets/202210122014-forward-proxy_pasted-image-20221012202942.webp)


A forward proxy is a server that sits between user devices and the internet.

Forward proxy


Let's say we want to create a `Text` component with React and Typescript. A basic implementation could look like:

```typescript
import React from 'react'

type TextProps = {
  children: React.ReactNode
  size?: 'sm' | 'md' | 'lg'
  color?: 'default' | 'primary' | 'secondary'
  className?: string
}

const Text = ({ children, className, size, color }: TextProps) => {
  // hooks to return CSS class base on component props
  const classes = useGetClasses('Text', { size, color })

  return <p className={clsx(classes, className)}>{children}</p>
}
```

This component works for simple use-cases but if we care about semantic HTML (use HTML heading tags to display titles or subtitles, `<p/>` for paragraph) it doesn't help. We need to adjust the above implementation by adding a `as` (you can name it anything you like) property to determine which tag we want to render.

```typescript
type TextProps = {
    children: React.ReactNode
    as?: any // We don't know the type of this property yet
}

const Text = ({ children, as, ...rest }: TextProps) => {
    // other code
    ...

    const Component = as || 'p';

    return (
        <Component {...rest}>{children}</Component>
    )
}

// Usage
// display with h1 tag
<Text as='h1'>Title</Text>
// display with p tag
<Text as='p'>Long paragraph</Text>
```

Our `Text` component works as expected but these are some couple of issues:

- `as` property is `any` so we can pass anything we want even invalid tag.
- We want to pass more attributes which belong to the HTML tag we provide

```typescript
<Text as="label" htmlFor="username">
  Username
</Text>
```

To fix the first issue, we need `as` only accepts a valid React element type. Fortunately, we can achieve this by using : `React.ElementType`. Update the implementation:

```typescript
import React from 'react';

type TextProps<C extends React.ElementType> = {
  children: React.ReactNode;
  as?: C;
  // other properties
};

const Text = <C extends React.ElementType>({ children, as }: TextProps<C>) => {
  // other code
    ...

  const Component = as || 'p';

  return <Component>{children}</Component>;
};
```

Now typescript will complain if you try to pass an invalid html tag

```typescript
// It's ok
<Text as='p'>Hello world</Text>
// Error!!!! Type '"vincenzo"' is not assignable to type 'ElementType<any> | undefined'
<Text as='vincenzo'>Hello world</Text>
```

To solve second issue, once again, React provides us a useful type `React.ComponentPropsWithoutRef`.

```typescript
type TextProps<C extends React.ElementType> = {
  children: React.ReactNode;
  as?: C;
} & React.ComponentPropsWithoutRef<C>;
```

Essentially, the type of `TextProps` is an object type containing `children`, `as` and all valid component properties that correlates with `as` tag.

Now, let’s give the solution a try! We try to add `htmlFor` property to a `Text` component with `as` is `p`. That’s wrong, and righty caught by TypeScript with the error: `Property 'htmlFor' does not exist on type...`

```typescript
// It's ok
<Text as='label' htmlFor='username'>
    Username
</Text>
// Error!!!! Property 'htmlFor' does not exist on type 'IntrinsicAttributes & { children: ReactNode; as?: "p" | undefined; }....
<Text as='p' htmlFor='username'>
    Username
</Text>
```

Our component is looking good right now but we still have an issue. The `as` property is optional, if we omit it, the component will render as `p` tag (as we expected) but Typescript can't know about this so it can't check the valid properties for this component.

```typescript
// No error !!! But it should be
<Text htmlFor="username">User</Text>
```

To fix this issue, we need to assign a default type for type parameters in a generic type.

```typescript
const Text = <C extends React.ElementType = 'p' /* default type */>({
  children,
  as,
  ...rest
}: TextProps<C>) => {
  // other code
   ...

  const Component = as || 'p';

  return <Component {...rest}>{children}</Component>;
};
```

The previous example we had should now throw an error, that is when you pass `htmlFor` to the `Text` component without an `as` prop. It's magic. ✨✨

We still can improve our `Text` component. As we know, some html tags have some internal properties like `color`, if we want to provide our own `color` property (or other properties), we just don't want to mess it up. We need to filter our own properties out of internal properties.

```typescript
// our custom text properties
type Props {
    color?: 'primary' | 'secondary',
    size?: 'sm' | 'md' | 'lg'
}
// omit internal properties
Omit<React.ComponentPropsWithoutRef<C>, keyOf Props>
```

The full implementation looks like

```typescript
type Props<C extends React.ElementType> = {
  children: React.ReactNode;
  as?: C;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
  // other properties...
};

type TextProps<C extends React.ElementType> = Props<C> &
  Omit<React.ComponentPropsWithoutRef<C>, keyof Props<C>>;

const Text = <C extends React.ElementType = 'p'>({
  children,
  as,
  ...rest
}: TextProps<C>) => {
  // other code
    ...

  const Component = as || 'p';

  return <Component {...rest}>{children}</Component>;
};
```

Our `Text` component is strongly typed.

Now, let's take it one step further. We want our solution works for other components not only `Text`. To make our solution reuseable, we can add one more generic type which represent the custom component.

Before going ahead, follow the `separation of concerns` principle, we should move `as` property out of our custom properties and define its own type.

```
type AsProp<C extends React.ElementType> = {
  as?: C;
};
```

Our reuseable solution will look like

```typescript
type AsProp<C extends React.ElementType> = {
  as?: C;
};

type PropWithAs<C extends React.ElementType, P = {}> = P & AsProp<C>;

export type PolymorphicComponentProps<
  C extends React.ElementType,
  Props = {}, // adding one more generic type
> = PropWithAs<C, Props> &
  Omit<React.ComponentPropsWithoutRef<C>, keyof PropWithAs<C, Props>>;
```

Now we can go ahead and use `PolymorphicComponentProps` on our components as follows:

```typescript
// Text component
type TextProps = {
  children: React.ReactNode;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
 // other properties...
};

const Text = <C extends React.ElementType = 'p'>({
  children,
  as,
  ...rest
}: PolymorphicComponentProps<C, TextProps>) => {
    // other code
    ...

  const Component = as || 'p';

  return <Component {...rest}>{children}</Component>;
};

// Usage
<Text as='h1'>Heading</Text>
<Text as='label' htmlFor='username'>
Username
</Text>

// Button component
type ButtonProps = {
  children: React.ReactNode;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
 // other properties...
};

const Button = <C extends React.ElementType = 'button'>({
  children,
  as,
  ...rest
}: PolymorphicComponentProps<C, ButtonProps>) => {
    // other code
    ...

  const Component = as || 'button';

  return <Component {...rest}>{children}</Component>;
};

// Usage
<Button>Submit</Text>
<Button as='a' href='/login'>Login</Text> // act as a link

```

Everything works like a charm. ✨✨

## How about `ref`?

To write a functional component which support Ref forwarding, we can use `React.forwardRef` function. The `Button` component will be look like

```typescript
const Button = React.forwardRef<HTMLButtonElement, ButtonProps>((props, ref) => {
  const { children, ...rest } = props

  return (
    <button ref={ref} {...rest}>
      {children}
    </button>
  )
})
```

To create polymorphic component, we need to replace `HTMLButtonElement` with a generic type `C`. Unfortunately we can't do that, `forwardRef()` is a function call so we can't define a generic type. So we came up with defining type for the function inside `forwardRef()`.

```typescript
const Button = React.forwardRef(
  <C extends React.ElementType = 'button'>(
    props: PolymorphicComponentProps<C, ButtonProps>,
    ref: unknown, // we still don't know yet
  ) => {
    const { as, children, ...rest } = props
    const Component = as || 'button'
    return (
      <Component ref={ref} {...rest}>
        {children}
      </Component>
    )
  },
)
```

So what type of the`ref` object? Remember this guy `React.ComponentPropsWithoutRef`? he has a brother named `React.ComponentPropsWithRef` which includes all the relevant component props based on the element type, plus the ref object. Let's define a new helper type, `PolymorphicRef`, that returns the type of the ref object for the polymorphic component.

```typescript
type PolymorphicRef<C extends React.ElementType> = React.ComponentPropsWithRef<C>['ref']

const Button = React.forwardRef(<C extends React.ElementType = 'button'>(props: PolymorphicComponentProps<C, ButtonProps>, ref: PolymorphicRef<C>) => {
  const { as, children, ...rest } = props
  const Component = as || 'button'
  return (
    <Component ref={ref} {...rest}>
      {children}
    </Component>
  )
})
```

Our `Button` component still isn't strongly typed. We need to explicitly defined the type annotation for it. `Button` component will be receive `ButtonProps` and return a JSX

```typescript
type ButtonComponent = (props: ButtonProps) => React.ReactElement | null;
```

The final step is to update `ButtonProp` to support `PolymorphicRef`

```typescript
// new helper type which includes the `ref` property for the polymorphic component
type PolymorphicComponentPropsWithRef<
  C extends React.ElementType,
  Props = {}
>
 = PolymorphicComponentProps<C, Props> & { ref?: PolymorphicRef<C> }

type CustomButtonProps = {
  children: React.ReactNode;
  color?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
};

type ButtonProps<C extends React.ElementType> = PolymorphicComponentPropsWithRef<
  C,
  CustomButtonProps
>

type ButtonComponent = <C extends React.ElementType = 'button'>(
  props: ButtonProps<C>,
) => React.ReactElement | null

const Button: ButtonComponent = React.forwardRef(
  <C extends React.ElementType = 'button'>(
    props: ButtonProps<C>,
    ref: PolymorphicRef<C>
  ) => {
    const { as, children, ...rest } = props;

    const Component = as || 'button';
    return (
      <Component ref={ref} {...rest}>
        {children}
      </Component>
    );
  }
);

// Useage
const buttonRef1 = React.useRef<HTMLButtonElement | null>(null);
const buttonRef2 = React.useRef<HTMLDivElement | null>(null);

// It's ok
<Button ref={buttonRef1}>Button1</Button>
// Error!!!! Type 'MutableRefObject<HTMLDivElement | null>' is not assignable to type 'RefObject<HTMLButtonElement>'...
<Button ref={buttonRef2}>Button2</Button>

```

Finally, we now have a complete solution.

```typescript
import React from 'react'

// base types
type AsProp<C extends React.ElementType> = {
  as?: C
}

type PropWithAs<C extends React.ElementType, Props = {}> = Props & AsProp<C>

type PolymorphicComponentProps<C extends React.ElementType, Props = {}> = PropWithAs<C, Props> & Omit<React.ComponentPropsWithoutRef<C>, keyof PropWithAs<C, Props>>

type PolymorphicRef<C extends React.ElementType> = React.ComponentPropsWithRef<C>['ref']

type PolymorphicComponentPropsWithRef<C extends React.ElementType, Props = {}> = PolymorphicComponentProps<C, Props> & { ref?: PolymorphicRef<C> }

// Usage

// Text component
type CustomTextProps = {
  children: React.ReactNode
  color?: 'primary' | 'secondary'
  size?: 'sm' | 'md' | 'lg'
}

type TextProps<C extends React.ElementType> = PolymorphicComponentProps<C, CustomTextProps>

const Text = <C extends React.ElementType = 'p'>({ children, as, ...rest }: TextProps<C>) => {
  const Component = as || 'p'

  return <Component {...rest}>{children}</Component>
}

// Button component
type CustomButtonProps = {
  children: React.ReactNode
  color?: 'primary' | 'secondary'
  size?: 'sm' | 'md' | 'lg'
}

type ButtonProps<C extends React.ElementType> = PolymorphicComponentPropsWithRef<C, CustomButtonProps>

type ButtonComponent = <C extends React.ElementType = 'button'>(props: ButtonProps<C>) => React.ReactElement | null

const Button: ButtonComponent = React.forwardRef(<C extends React.ElementType = 'button'>(props: ButtonProps<C>, ref: PolymorphicRef<C>) => {
  const { as, children, ...rest } = props

  const Component = as || 'button'
  return (
    <Component ref={ref} {...rest}>
      {children}
    </Component>
  )
})
```

Congratulation, we have successfully built a strongly typed Polymorphic React Component with Typescript. 🎉🎉🎉🎉


This article provides a step-by-step guide on how to build polymorphic React components with Typescript, covering the necessary concepts and techniques to create flexible and reusable components.

Build polymorphic React components with Typescript


Frontend engineers use Hexadecimal color codes to represent colors, but they have some limitations:

- Hexadecimal color codes are difficult to write and adjust, requiring the use of a third-party application to get right.
- Hexadecimal color codes can be difficult to remember and use, especially for designers.

HSL is the answer to resolving all of the painful points.

## What is HSL?

**HSL** stands for **hue**, **saturation**, and **lightness**. It’s based on the RGB color wheel. Each color has an angle and a percentage value for the saturation and lightness values.

- **Hue**: Think of a color wheel. Around 0<sup>o</sup> and 360<sup>o</sup> are reds. 120<sup>o</sup> is where greens are and 240<sup>o</sup> are blues. Use anything in between 0-360. Values above and below will be modulus 360.

  ![](assets/hsl-color_hls-color.webp)

- **Saturation**: 0% is completely desaturated (grayscale). 100% is fully saturated (full color).

  ![](assets/hsl-color_hls-hue.webp)

- **Lightness**: 0% is completely dark (black). 100% is completely light (white). 50% is average lightness.

  ![](assets/hsl-color_hls-lightest.webp)

## Using HSL

### Darker/lighter colors

Imagine you're creating a button component and you want it to appear darker on hovering to increase its contrast. You can do this easily with the help of HSL.

![](assets/hsl-color_using-hls.webp)

```css
:root {
  /* brand color: #E13F5E */
  --primary-h: 349;
  --primary-s: 73%;
  --primary-l: 56%;
}

.button {
  background-color: hsl(var(--primary-h), var(--primary-s), var(--primary-l));
}

.button:hover {
  --primary-l: 40%;
}
```

### Color palette

By altering the `lightness`, we can create a set of shades for a color that can be used throughout the UI where possible.

![](assets/hsl-color_hls-color-pallete.webp)

## HSL transparency (HSLa)

It works exactly the same as with RGB, just add `alpha` channel with a value from 0 to 1. 0 is fully transparent. 1 is fully opaque. 0.5 is 50% transparent.

```css
hsla(349, 73%, 56%, 0.5)
```

## References

- https://css-tricks.com/hsl-hsla-is-great-for-programmatic-color-control/
- https://www.smashingmagazine.com/2021/07/hsl-colors-css/
- https://tsh.io/blog/why-should-you-use-hsl-color-representation-in-css/


HSL is the answer to resolving all of the painful points of Hexadecimal color codes.

HSL color


**CSS-in-JS** is a styling technique where Javascript is used to style the component. These are multiple implementations of this concept in the form of libraries such as [emotion](https://emotion.sh), [styled-component](https://styled-components.com/), [JSS](https://cssinjs.org). They aim to tackle the limitations of CSS, such as lack of dynamic functionality, scoping, and portability.

## Benefits

### Scoping

With CSS-in-JS, writing new styles cannot affect anything else in other places on the site, so there’s no need to worry about writing a style that has bad or unintended consequences elsewhere due to a selector in the global scope.

### Avoid naming collisions

[Naming is hard](https://hilton.org.uk/blog/why-naming-things-is-hard). CSS-in-JS libraries automatically generate unique selectors for what’s being styled. We don't need to think about naming.

### Dynamic functionality

As CSS-in-JS is essentially JavaScript code, you can apply complex logic to your style rules, such as loops, conditionals, variables, state-based styling, and more.

### Dead code elimination

CSS-in-JS helps with removing dead code. The only styles that are loaded are the styles for the components in use at any given time. There’s no shipping of any unused styles. When a component dies, so does its style.

### Developer ergonomics

It can be nice to have styles in the same file (or otherwise very close to) the component itself. In the same way, some developers feel very comfortable in JSX. Also, being able to style things without any scoping worry means developers may feel empowered about styling rather than intimidated by it.

## Disadvantages

### Runtime cost

When CSS is generated from JavaScript at runtime, in the browser, there is an inherent overhead. Some CSS-in-JS libraries try to overcome this overhead by extracting CSS files during the build time (like [linaria](https://linaria.dev)), but it comes with other [trade-offs](https://github.com/styled-components/styled-components/issues/2377)

### Learning curve

CSS-in-JS definitely has a learning curve, especially if you have used neither component-based frameworks nor web components before. Besides learning the new syntax, you also need to pick up a new way of thinking, which needs time and might slow down your development workflow for a while.

### Unreadable class names

Automatically generated selectors significantly worsen code readability. This can be a huge concern for you if you regularly use your browser’s developer tools for debugging. Currently, many CSS-in-JS libraries try to provide meaningful class names based on the declaration name or component name in development mode. Some of them even let you customize the class name generator function. In production mode, though, the class names are still hard to read and debug.

### Extra bundle size

Adding another library to a web page increases the page size, which can negatively impact page load time.

## Reference

- https://en.wikipedia.org/wiki/CSS-in-JS
- https://webdesign.tutsplus.com/articles/an-introduction-to-css-in-js-examples-pros-and-cons--cms-33574
- https://medium.com/dailyjs/what-is-actually-css-in-js-f2f529a2757
- https://github.com/styled-components/styled-components/issues/2377


CSS-in-JS is a styling technique where Javascript is used to style the component.

Css in JS


## What is a fractional NFT?

- A fractional NFT is simply a whole NFT that has been divided into smaller fractions, allowing different numbers of people to claim ownership of a piece of the same NFT. The NFT is fractionalized using a smart contract that generates a set of tokens linked to the indivisible original.
- These fractional tokens give each holder a percentage of ownership of an NFT, and can be traded or exchanged on secondary markets.

## How does it work?

To break this NFT into fractions, it must first be locked in a smart contract, which will split the ERC-721 token into multiple ERC-20 tokens as per the instructions the NFT owner has given. The owner specifies everything, from the number of ERC-20 tokens to be created, to their prices, to the metadata to be used, to any other property they deem important. Each fraction or ERC-20 token created represents partial ownership of the NFT. The fractions can then be put up for sale at a fixed price for a particular time or until they get sold out.

![](assets/nft-fractionalization_y8tfcaq.webp)

## Benefits of fractional NFT

- **Price discovery**: the asset is extremely valuable and they want help finding price discovery, fractionalizing the item and selling 20% on the market can be a valuable tool to help understand how the market values the NFT.
- **More liquidity**: owners have significantly better exit liquidity than if they owned the NFT themselves. This can be achieved through on-chain exchanges such Uniswap.
- **Curator incentives**: an NFT owner who divides their asset into fractions receives a curator fee from their chosen NFT marketplace. Although the owner can set and update the amount of this fee, it is subject to a maximum price limit to prevent reckless pricing.

## References

- https://www.coindesk.com/learn/how-can-you-share-an-nft-fractional-nfts-explained/
- https://learn.bybit.com/nft/what-are-fractional-nfts/
- https://www.leewayhertz.com/fractional-nft/
- https://medium.com/fractional-art/what-is-fractional-dd4f86e6458a


NFT fractionalization is a process of dividing a non-fungible token (NFT) into smaller, fractional tokens that represent partial ownership of the original NFT. This article provides an overview of fractional NFTs, how they work, and their benefits.

NFT fractionalization


## How tokens work on Solana - explain for EVM developers

> **Let's say you want to create a new type of fungible token, mint some to yourself, and then transfer some to your friend. What would you do?**

- As a EVM developer, you have to deploy a new ERC20 smart contract.
- On Solana, you don't need to create a new contract. There is a single token program (which was deployed by the Solana team) which responsible for creating, minting and transfering tokens.
- In order to create a new token, you send the `create` instruction to the token program. This creates a new `mint account`. Each type of token is associated with exactly one `mint account` which holds metadata about the token (likes `total supply`, `decimals`, `mint authority` - who allowed to mint, `freeze authority` - who allowed to freeze account ).

![](assets/how-tokens-work-on-solana_vuocgc7hpng.webp)

- You've just created a new token but you don't own any amount of this token yet. From `mint account`, you have to create a `token account`. A `token account` stores how many tokens a particular user has, for a particular type of token.

![](assets/how-tokens-work-on-solana_jrckbifh.webp)

- Now, you have a `mint account` and a `token account`. Let's mint some tokens. To mint, you just send the `mint` instruction to the token program, which tells the program how many tokens to mint and whom to mint them to. Only one user is allowed to mint a token of a particular type (the `mint authority` which mentioned above)

- To transfer tokens, no surprises, you send the `transfer` instruction to the token program, which tells it how many tokens to transfer and whom to transfer them. Note that the recipient must also own a `token account` for the type of token you're transferring.

![](assets/how-tokens-work-on-solana_c2fz6whh.webp)

- What about NFTs? To create an NFT, you also use the same token program (what!!!), but these are some differences in how they are created and minted.
- As you know, an NFT is just a token that has one `total supply` and zero `decimal`. To create an NFT, you just need to create a `mint account` which has zero `decimal`. After that, you mint only one token of this NFT and disable future minting. This ensures there will only ever be one.
- In practice, most people use Candy Machine to create NFTs, which abstracts all this complexity away.
- But how can I config the name and symbol for my token? To do that, you need to create a pull request to [Solana Token Registry](https://github.com/solana-labs/token-list). Include a JSON file containing your token metadata (chain id, address, symbol, logo, name ...). Click [here](https://github.com/solana-labs/token-list) for more information.

## Reference

- <https://spl.solana.com/token>
- <https://spl.solana.com/associated-token-account>
- <https://twitter.com/pencilflip/status/1454141877972779013>


A comprehensive guide explaining how tokens function on Solana, comparing it with EVM-based tokens. This article covers the creation of fungible tokens and NFTs, minting process, token transfers, and key differences in token management between Solana and EVM blockchains.

How tokens work on Solana


React 18 was released in March 2022. This release focuses on performance improvements and updating the rendering engine.

## React 18 feature quick guide

Now let's look at each of these updates in more detail.

## Concurrency in React

- Concurrency is not a feature, per se. It’s a new behind-the-scenes mechanism that enables React to prepare multiple versions of your UI at the same time.
- A key property of Concurrent React is that rendering is interruptible. React may start rendering an update, pause in the middle, then continue later. It may even abandon an in-progress render altogether.
- Another example is the reusable state. Concurrent React can remove sections of the UI from the screen, then add them back later while reusing the previous state.

## New React 18 features

### Automatic batching

- Batching is when React groups multiple state updates into a single re-render for better performance. For example, if you have two state updates inside of the same click event, React has always batched these into one re-render.

```plain_text
function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // Does not re-render yet
    setFlag(f => !f); // Does not re-render yet
    // React will only re-render once at the end (that's batching!)
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

```

- However, React wasn’t consistent about when it batches updates. For example, if you need to fetch data, and then update the state in the `handleClick` above, then React would not batch the updates, and perform two independent updates.
- Starting in React 18, all updates will be automatically batched, no matter where they originate from. This means that updates inside of timeouts, promises, native event handlers or any other event will batch the same way as updates inside of React events.

```plain_text
function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
}, 1000);

fetch(/*...*/).then(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React will only re-render once at the end (that's batching!)
})

```

### What if I don’t want to batch?

- You can use `ReactDOM.flushSync()` to opt out of batching:

```plain_text
import { flushSync } from 'react-dom'; // Note: react-dom, not react

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // React has updated the DOM by now
  flushSync(() => {
    setFlag(f => !f);
  });
  // React has updated the DOM by now
}

```

## Transitions

- Transitions allow you to mark updates as transitions, which tells React that they can be interrupted and avoid going back to Suspense fallbacks for already visible content.

```plain_text
import {startTransition} from 'react';

// Urgent: Show what was typed
setInputValue(input);

// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(input);
});

```

- Updates wrapped in startTransition are handled as non-urgent and will be interrupted if more urgent updates like clicks or key presses come in. If a transition gets interrupted by the user (for example, by typing multiple characters in a row), React will throw out the stale rendering work that wasn’t finished and render only the latest update.
- `useTransition`: a hook to start transitions, including a value to track the pending state.
- `startTransition`: a method to start transitions when the hook cannot be used.

## Suspense on the server

- Server-side rendering (abbreviated to “SSR” in this post) lets you generate HTML from React components on the server, and send that HTML to your users. SSR lets your users see the page’s content before your JavaScript bundle loads and runs. SSR in React always happens in several steps:
- On the server, fetch data for the entire app.
- Then, on the server, render the entire app to HTML and send it in the response.
- Then, on the client, load the JavaScript code for the entire app.
- Then, on the client, connect the JavaScript logic to the server-generated HTML for the entire app (this is “hydration”).
- The key part is that each step had to finish for the entire app at once before the next step could start. This is not efficient if some parts of your app are slower than others, as is the case in pretty much every non-trivial app.
- React 18 lets you use `<Suspense>` to break down your app into smaller independent units which will go through these steps independently from each other and won’t block the rest of the app. As a result, your app’s users will see the content sooner and be able to start interacting with it much faster. The slowest part of your app won’t drag down the parts that are fast. These improvements are automatic, and you don’t need to write any special coordination code for them to work.

## Strict mode

- Strict Mode is a tool that helps identify coding patterns that may cause problems when working with React, like impure renders.
- React 18 introduces a new development-only check to Strict Mode. This new check will automatically unmount and remount every component, whenever a component mounts for the first time, restoring the previous state on the second mount.
- Before this change, React would mount the component and create the effects:

```plain_text

* React mounts the component.
  * Layout effects are created.
  * Effects are created.

```

- With Strict Mode in React 18, React will simulate unmounting and remounting the component in development mode:

```plain_text

* React mounts the component.
  * Layout effects are created.
  * Effects are created.
* React simulates unmounting the component.
  * Layout effects are destroyed.
  * Effects are destroyed.
* React simulates mounting the component with the previous state.
  * Layout effects are created.
  * Effects are created.

```

## How to upgrade to React 18

- React 18 introduces a new root API which provides better ergonomics for managing roots. The new root API also enables the new concurrent renderer, which allows you to opt-into concurrent features.

```plain_text
// Before
import { render } from 'react-dom';
const container = document.getElementById('app');
render(<App tab="home" />, container);

// After
import { createRoot } from 'react-dom/client';
const container = document.getElementById('app');
const root = createRoot(container); // createRoot(container!) if you use TypeScript
root.render(<App tab="home" />);

```

## Conclusion

- In a summary, React 18 comes with a few breaking changes, depending on how you use it. But all in all, it also brings out-of-the-box performance improvements including batching more by default, which removes the need to manually batch updates in application or library code.
- Upgrading to React 18 should be straightforward, give it a try and let us know what you think.


React 18 was released in March 2022. This release focuses on performance improvements and updating the rendering engine.

React 18


A brief comparison between Remix and Next.js frameworks

## Introduction of Remix

Remix describes itself as:

> Remix is an edge native, full-stack JavaScript framework for building modern, fast, and resilient user experiences. It unifies the client and server with web standards so you can think less about code and more about your product.

Compared to Next.js, which is one of the most React frameworks used for server-side rendering and has been there for a significant time, Remix appears as a new strong competitor. Developers have started to wonder what the difference between these two frameworks is.

In this post, we will mainly focus on Remix and highlight what makes it unique and where it shines the most.

## How is Remix different from Next.js?

### Page rendering strategies

Despite the same idea of creating websites that are rendered on the server before being sent to the client, Remix and Next.js go with distinct approaches.

Remix doesn't support Static Site Generation (SSG) but it suggests using HTTP stale-while-revalidate caching directive (SWR) as an alternative. The key here is that static routes are cached using a CDN. These routes are then served to users on each visit and automatically revalidated for the next visitor.

### Routing

Both Remix and Next.js follow a file-based routing system.

In Next.js, each file inside the `/pages` directory will be automatically set as a route.

```javascript
pages/index.js ==> /
pages/users/index.js ==> /users
pages/users/create.js ==> /users/create
```

Remix also does the same but the route directory is `/app/routes`:

```javascript
app/routes/index.js ==> /
app/routes/users/index.js ==> /users
app/routes/users/create.js ==> /users/create
```

Built on top of React Router, Remix shines when it comes to nested routing. It comes with a very powerful route nesting mechanism that can put one or many routes inside another route and those act like children components that can be mounted and unmounted depending on the active URL path. We need to use an Outlet component to render the route hierarchy from the parent routes.

Next.js, on the other hand, comes with its own router and has support for routes nesting but it’s not so easy to do so compared to Remix.

### Data loading

Next.js supports different ways for loading data on the server-side like `getServerSideProps` and `getStaticProps` based on the type of web app.

Remix has a new concept with two portions:

- `loader` function - used to load data in a component, and a supplementary
- `useLoaderData hook` - used to get access to the data returned by the `loader` function

```javascript
import { useLoaderData } from "remix";

export const loader = () => {
  // fetch data from database or make API calls
  return {data}
};

export default function App() {
 // get access to data
  let {data} = useLoaderData();

  return (
    <div>
      <p>Use Data in component {data}</h1>
    </div>
  );
}
```

### Data mutation

Next.js doesn't do anything for mutations. Basically, we would have to handle everything from creating a form, fetching data, managing state, adding event handlers, to finally dealing with errors, interruptions, and race conditions.

Data mutations in Remix are built on top of two fundamental web APIs: `<form>` and HTTP. All we have to do is to use a `<Form>` component (works identically to `<form>` with a couple of extra goodies for optimistic UI etc.) and a route function named `action`. When the user submits a form, Remix with call the action for the form and reload all of the data on the page. This ensures that any updates to the data are reflected in the UI.

```javascript
export const action = async ({ request }) => {
  const form = await request.formData();
  const content = form.get("content");
  return redirect("/");
};

export default function App() {
  return (
    <div>
      <Form method="POST">
        <label htmlFor="content">
          Content: <textarea name="content" />
        </label>
        <input type="submit" value="Add New" />
      </Form>
    </div>
  );
}
```

### Error handling

Next.js define some custom pages for certain status errors like 404 or 500 errors. However, some errors around data and rendering are not supported.

Remix has an error boundary for handling errors. When we create a route component, we can also define an error boundary for catching any errors that occur in the route component. It likes having two components in a route file, with one being the actual route component and one being the fallback when errors happen in the former. One noteworthy thing is when there is an error in a nested component route and this route has no error boundary, the error bubbles up the nested tree until caught by a parent’s error boundary.

![](assets/remix-versus-nextjs_a7d49c4d71418c892f72a5c2a7dbee19_md5.webp)

## Conclusion

For React developers, Next.js is obviously the prior choice when it comes to server-side rendering for its familiar concepts and larger community. Has been around for a while, it seems like a steady pedestal and is not easy to be replaced in a short period.

Even so, Remix looks like a shiny new thing. It also provides a higher level of abstraction. Routing system might be confusing but it is a remarkable feature too. Other built-in features such as data loading, data mutations, error boundary, etc. actually improve the developer experience.

Overall, Remix is a new framework, and it will definitely become more powerful and widespread in the future.


A brief comparison between Remix and Next.js frameworks

Remix versus Nextjs


## The blockchain oracle problem

Blockchains have a fundamental limitation: they cannot natively communicate with systems of the outside world. This lack of external connectivity, known as "the oracle problem", prevents smart contracts from verifying external events, trigger actions on existing systems, and providing users the full range of functionality.

## What is a blockchain oracle?

A blockchain oracle is a third-party service that connects smart contracts with the outside world, primarily to feed information in about the world around, but the reverse is also true.

![](assets/blockchain-oracle_ins_and_outs_of_the_blockchain_ecosystem.webp) _Blockchain oracles connect blockchains to inputs and outputs of the real world (Image source: [Chainlink](https://chain.link/))_

## Types of blockchain oracles

### Input oracles

The most widely recognized type of oracle today is known as an “input oracle”, which fetches data from the real-world(off-chain) and delivers it onto a blockchain network for smart contracts consumption. A good example of this are the Chainlink Price Feeds.

### Output oracles

The opposite of input oracles are "output oracles", which allow smart contracts to send commands to off-chain systems to trigger and execute certain actions.

### Cross-chain oracles

This type of oracle can read and write information between different blockchains. Cross-chain oracles enable interoperability for moving both data and assets between blockchains.

### Compute-enabled oracles

This type of oracle provides decentralized services with secure, off-chain computation that would otherwise be impractical to do on the blockchain due to technical, legal, or financial constraints.

## Notable blockchain oracles

- Chainlink (LINK)
- Band Protocol (BAND)
- Teller (TRB)
- Decentralized Information Asset (DIA)
- API3

## Reference

- [Wikipedia - Blockchain oracle](https://en.wikipedia.org/wiki/Blockchain_oracle#:~:text=A%20blockchain%20oracle%20is%20a,that%20decentralised%20knowledge%20is%20obtained.)
- [https://chain.link/education/blockchain-oracles](https://chain.link/education/blockchain-oracles)
- [https://coin98.net/what-is-blockchain-oracle](https://coin98.net/what-is-blockchain-oracle)


Learn how blockchain oracles solve the oracle problem by connecting smart contracts with real-world data, enabling secure input, output, cross-chain communication, and off-chain computing.