ERC-165 is an interface identification mechanism that enhances compossibility as contracts can determine whether a contract supports an interface at compile time.

ERC-165 Goal

Prior to ERC-165, there was no mechanism to check whether a contract supported a specific interface, such as ERC-20. Therefore, there was no way of verifying whether a contract could accept tokens or tokens sent to a contract would be ‘stuck’ and effectively lost.

Implementation

ERC-165 introduces a standardized function to declare support for specific interfaces within a given contract. Other contracts can call this function to verify whether a certain interface is supported.

function supportsInteface(bytes4 interfaceId) external view returns (bool);

Supporting multiple Interfaces

In the wild you may have observed something like this:

function supportsInterface(bytes4 interfaceId) public view    override(ERC1155, AccessControl) returns (bool) { 
    return super.supportsInterface(interfaceId); 
}

This is required when a contract inherits multiple instances of supportsInterface for different interface standards. In the example above, the contract inherits from both ERC-1155 and Access Control. The contract must override supportsInterface function and uses the super keyword to specify that the contract's own supportsInteface function should combine the from both interfaces. This way the supportsInterface function will return true for both queries with ERC-1155 and Access Control.

Sources

1. https://eips.ethereum.org/EIPS/eip-165

Smart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts.

Upgradeability is achieved by separating storage and logic. A proxy contract contains the state and delegates execution to a logic contract. There is an opcode specifically for this called delagatecall. delegatecall, executes the code of a target address with the context of the caller. Meaning the state of the caller is used with the logic of the target.

To upgrade the logic, the proxy can be updated to reference a different logic contract with updated logic.

The Problems with Proxies

Conceptually the proxy setup is quite simple to grasp, however, it introduces a host of problems if not careful. A key issue that arises as a result of this pattern is clashes. This occurs for both the variables and function signatures of the proxy and logic contracts.

Variable clashes

Updating the incorrect state variable

This example is taken from a RareSkills article on delegatecall, please check it and RareSkills out.

Given the following contracts Proxy and Logic unintended behaviour arises as a result of variable clashes.

contract Logic {
    uint public number;

    function increment() public {
        number++;
    }
}

contract Proxy {
    address public calledAddress = 0xd9145CCE52D386f254917e481eB44e9943F39138;

    uint public myNumber;

    function callIncrement() public {        
        calledAddress.delegatecall(
            abi.encodeWithSignature("increment()")
        );
    }
}

The Proxy::callIncrement function will call the Logic::increment function (shocking I know) with the context of the Proxy contract. The way the increment function should be interpreted is: to increment the value of storage slot zero of the contract. As stated in the article "the name of the variable doesn’t matter; what is fundamental is which slot it is in."

Remember this logic was executed in the context of the Proxy contract. If storage slot zero is to be incremented by one, the calledAddress variable will then be updated to 0xd9145CCE52D386f254917e481eB44e9943F39139. This breaks the Proxy contract as it is no longer able to delegate to the Logic contract. It is imperative to ensure there are no collisions between the slots of the Proxy and Logic contract as it can lead to unexpected behaviour breaking the smart contract.

Reading from the incorrect state variable

Again referencing an example from RareSkills, the following set of contracts have a crucial flaw due to variable clashes between Proxy and Logic contracts.

contract Logic {
    uint public discountRate = 20;

    function calculateDiscountPrice(uint256 amount) public pure returns (uint) {
        return amount - (amount * discountRate)/100;
    }
}

contract Proxy {
    uint public price = 200;
    address public called;

    function setCalled(address _called) public {
        called = _called;
    }

    function setDiscount() public  {
        (bool success, bytes memory data) = called.delegatecall(
            abi.encodeWithSignature(
                "calculateDiscountPrice(uint256)", 
                price
            )
        );

        if (success) {
            uint newPrice = abi.decode(data, (uint256));
            price = newPrice;
        }
    }
}

The Logic::calculateDiscountPrice function reads the state variable discountRate to calculate the new discounted price. However, this function is executed within the context of the Proxy contract. What the Logic::calculateDiscountPrice function is really doing is multiplying the parameter amount by the value in storage slot 0, dividing it by 100 and subtracting this from the original amount value. The discountRate is supposed to be 20, however, when executing within the context of the Proxy it is 200, as that is the value in storage slot 0. This leads to the state variable price being updated to the wrong value.

Function signature clashes

In the EVM each function is identified by the first 4-bytes of its Keccak-256 hash. An issue can arise in the Proxy pattern where different functions in the logic and proxy contracts both share the same signature.

The example below is taken from an OpenZeppelin blogpost. It can be observed that the hash of collate_propagate_storage(bytes16) is the same as burn(uint256).

pragma solidity ^0.5.0;

contract Proxy {
    
    address public proxyOwner;
    address public implementation;

    constructor(address implementation) public {
        proxyOwner = msg.sender;
        _setImplementation(implementation);
    }

    modifier onlyProxyOwner() {
        require(msg.sender == proxyOwner);
        _;
    }

    function upgrade(address implementation) external onlyProxyOwner {
        _setImplementation(implementation);
    }

    function _setImplementation(address imp) private {
        implementation = imp;
    }

    function () payable external {
        address impl = implementation;

        assembly {
            calldatacopy(0, 0, calldatasize)
            let result := delegatecall(gas, impl, 0, calldatasize, 0, 0)
            returndatacopy(0, 0, returndatasize)

            switch result
            case 0 { revert(0, returndatasize) }
            default { return(0, returndatasize) }
        }
    }
    
    // This is the function we're adding now
    function collate_propagate_storage(bytes16) external {
        implementation.delegatecall(abi.encodeWithSignature(
            "transfer(address,uint256)", proxyOwner, 1000
        ));
    }
}

Therefore if a user calls the Proxy to burn some tokens it will match the signature of collate_propagate_storage(bytes16) and send 1000 tokens to the owner of the proxy instead.

Note that this cannot occur in a singular contract, as the compiler will identify a clash of signatures and throw an error.

Constructor Caveats

Code in the constructor of a logic contract is effectively useless as the code only runs once during its deployment and any resulting state changes are irrelevant as the context of execution comes from the Proxy contract. As said in the proxies blog on OpenZeppelin: "Proxies are completely oblivious to the storage trie changes that are performed by the constructor."

Therefore, in any logic contract, if there is any initial setup required, an initializer function should be used. OpenZeppelin supports this with its host of upgradeable contracts.

Transparent Proxies

Transparent proxies is a standard of implementing upgradeability via a Proxy contract, that avoids the pitfalls previously explored.

Transparent proxies have message-routing logic based on the msg.sender. If the caller is the admin of the Proxy contract, the proxy will not delegate calls. If the caller is not the admin the proxy will always delegate calls. This behaviour is demonstrated in the table below:

ERC-1967

Every proxy must store the address of the logic contract, however as previously explored there is a danger of storage variable clashes altering this value. To ensure that a clash never occurs for the address of the logic function, ERC-1967 implemented a reserved slot for storing the address of a logic contract. This ensures that the compiler will never assign a variable to this slot, preventing clashes and unexpected behaviour from occurring. All proxy contracts from OpenZeppelin implement ERC-1967.

Sources

1. https://blog.openzeppelin.com/the-transparent-proxy-pattern

2. https://docs.openzeppelin.com/contracts/5.x/api/proxy#Proxy

3. https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies

4. https://eips.ethereum.org/EIPS/eip-1967

5. https://www.rareskills.io/post/delegatecall

6. https://forum.openzeppelin.com/t/beware-of-the-proxy-learn-how-to-exploit-function-clashing/1070

7. https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357

The ERC-1155 standard specifies an interface that supports multiple tokens governed by a single contract. Additionally, tokens controlled by the contract can have different types of fungibility.

Supported fungibility types include:

• Fungible (ERC-20 like)

• Semi-fungible

• Non-fungible (ERC-721 like)

It also introduces a number of QoL features, such as bulk approvals, where one approval applies to all token types held by the contract. This removes the need for users to approve an individual token each time they transact with it. Moreover, it introduces batched transactions. As the contract supports multiple tokens, it provides a mechanism to query balances for multiple tokens in one transaction or to transfer multiple token types in one transaction. Finally, it also implements safe transfers to ensure that the receiving entity supports the ERC-1155 token type.

Semi Fungibility

This fungibility type refers to a token that possesses unique metadata and properties but can be held by multiple addresses. For example, a game may require a key to gain access to a specific level or hidden content. The token representing the key is unique and would have metadata and properties related to the content it unlocks. However, many users of the game may hold the token.

This type of token has characteristics of both an ERC-20 and ERC-721. It represents a unique asset with its own properties and metadata, like an ERC-721. However, these tokens have multiple owners and are interchangeable with one another, as they represent the same asset, much like an ERC-20.

Batch Operations

Batch operations introduce significant gas savings as they permit multiple balance queries or transfers to be completed in a single transaction. This is only possible as the ERC-1155 standard maintains the state of multiple tokens in a single contract.

Batch Query Balance:

Queries an array of addresses (accounts) for the balance they hold of the token type id. Returns an array of token balances in the order of the accounts provided to the function call.

balanceOfBatch(address[] accounts, uint256[] ids) -> uint256[]

• The length of accounts must equal the length of ids

• You can query multiple addresses for the balance of different tokens the contract holds

  • E.g. query two addresses the balance of gold(fungible), potions(semi-fungible) and unique swords(non-fungible) the each own all in one transaction

Batch Transfer:

You can transfer multiple different types of tokens from one address to another in the same transaction.

safeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] amounts, bytes data);

• ids and amounts must have the same length

• to must implement onERC1155BatchReceived

OpenZeppelin extended batch functionality:

OpenZeppelin extended the batch features included in the ERC-1155 standard, introducing a mintBatch and a burnBatch.

Mint Batch:

Mint multiple tokens in one transaction. The mint can also include multiple types of tokens, e.g. mint ERC-20 and ERC-721 tokens to the same address in a single transaction.

_mintBatch(address to, uint256[] ids, uint256[] values, bytes data);

• ids and values must have the same length

• to cannot be the zero address

• The to address must implement onERC1155BatchReceived

Burn Batch:

Burn multiple tokens in a single transaction.

_burnBatch(address from, uint256[] ids, uint256[] values);

• from cannot be the zero address

• from must have at least the amount of tokens specified in the values parameter of the token represented by the array position

• ids and values must have the same length

Supply Extension

This is an additional extension that can be used to track the total supply of each of the tokens in the ERC-1155 contract. The only balance related functionality enshrined in the ERC-1155 standard is the balanceOf and balanceOfBatch functions, that only reveal information about the tokens an address holds.

This extension adds the following functions:

• totalSupply(id) which returns the total amount of tokens with the id id.

• totalSupply() which returns the number of tokens the ERC1155 contract holds.

• exists(id) returns a bool as to whether the token of id exists

Sources

1. https://eips.ethereum.org/EIPS/eip-1155

2. https://ethereum.org/en/developers/docs/standards/tokens/erc-1155/

3. https://docs.openzeppelin.com/contracts/5.x/erc1155

4. https://docs.openzeppelin.com/contracts/5.x/api/token/erc1155#ERC1155

As a long-time onchain enthusiast who has been dabbling in DeFi and battling with Metamask since 2020; I have always marvelled at the premier onchain apps. Apps like AAVE and UniSwap are so clean and always iterating and improving. Furthermore and perhaps most importantly, in the most adversarial environment imaginable with billions of dollars at stake, these apps have never been exploited.

*I hope I didn’t just jinx that😬🤞*

But since I have started using these applications, I have graduated from university as a software engineer and have a few years of experience under my belt, I no longer marvel at onchain apps. Now they pique my curiosity. What goes into creating an onchain app? What is the best way to build one? How much effort does it take to go from nothing to a URL that hosts a clean frontend that allows users to interact with a decentralised protocol? I needed to find out, so that’s why I built an onchain app.

The Idea

Ultimately the idea doesn’t matter too much here. The purpose of this project is to understand how to build the thing, rather than building the thing itself. I know, I know if you are passionate about the application you are building, the odds of you completing it dramatically increase. But you know what, I am passionate about learning so that’ll suffice.

So what am I building?

Anyone who has attempted to develop anything onchain would have undoubtedly come across the man himself Patrick Collins. The content he has created is at the pinnacle of onchain development and security, I strongly recommend you check it out.

In one of his courses, the exercise is to build a set of smart contracts that facilitate decentralised fundraising. The project allows the owner of the contract to raise funds and withdraw them to presumably go out and do what they promised to do with the funds. However, in the onchain world, this isn’t always what happens with teams that raise big funds.

Shenanigans aside, I thought I would extend the capabilities of this project to scale to multiple users being able to create different fund-raises that anyone with a Metamask can contribute to. To build a Kickstarter-esque onchain application.

And with that decision made, it became time to select the tech stack I would use to create my new app, Go Fund Yourself.

Choosing the tech stack

Frontend

In this day and age, there is certainly no shortage of frontend frameworks to choose from. I personally use VueJs at work, so I ruled it out as I wanted to try something new. Based on the docs for different onchain libraries (more on this later), NextJs and React seem to be the most popular. While these frameworks will undoubtedly boost your employability, the contrarian within me wouldn’t allow it. Also as someone who uses VueJs regularly, I really do enjoy the templating in a vue component as opposed to JSX, so that played a factor too.

I ultimately opted for SvelteKit. I get templating syntax which is my preference. Additionally, I wanted to try a meta-framework to better understand their strengths and weaknesses and familiarise myself with the server and client-side separations when developing components. Moreover, Svelte is consistently voted as one of the most admired frontend frameworks by developer surveys and I’m a big fan of Svelte’s philosophy:

“Svelte is a superset of HTML” - Rich Harris (Svelte Founder)

Some front-end frameworks stray far from the idiomatic HTML, JavaScript & CSS that I first used to create simple websites. It was with these languages that I first fell in love with coding. I wanted to see if Svelte made good on its promise of simplicity and idiomatic use of the aforementioned languages and could emulate that feeling of when I first started building websites.

For more info on Svelte, I strongly recommend checking out RIch’s interviews with the Primeagean and Prismic. Additionally, the man himself Patrick Collins made a stream for web3 front-end development and he was using SvelteKit, I saw this as a good omen, how could I not give Svelte a crack?

Onchain Libraries

You might be thinking, what on Earth is an onchain library? These are JavaScript libraries that provide utilities for all types of interactions with blockchains. These libraries greatly simplify the process of reading/writing from/to smart contracts, managing wallet connections and updating the state of your application accordingly.

As far as I am aware, there are three major EVM libraries to consider:

1. Web3.js

2. Ethers.js

3. Wagmi

Each has its pros and cons. There’s a fantastic article on Sveltekit.io that breaks down the different library alternatives when creating an onchain SvelteKit app. Strongly recommend you check it out.

But I’ll break down my decision for you here quickly:

• Web3.js is the most mature of the three and offers a rich set of features. However, it is quite a large bundle and is not quite as performant as the other options.

• Ethers.js I have worked with in the past and found the DX to be okay, it is more performant than Web3.js, but lacks certain utilities that are offered by Wagmi.

• Wagmi has both good performance and a rich set of utilities. Furthermore, it is rapidly gaining in popularity and is used by some of the biggest projects in the onchain world.

I ultimately chose Wagmi. It’s important to note when using Svelte it will be the Wagmi core JS library that will power onchain interactions. There are specific libraries for React and Vue that offer hooks or composables, but these of course are of no use to us. However, there is an unofficial SvelteKit-specific library that has received high praise from Svelte developers. It offers Wagmi stores that simplify integrating Wagmi into your Svelte app, which I did take advantage of.

RPCs

If you are developing anything that is connected to a blockchain you will need a RPC (Remote Procedure Call). At a high level, RPC is a protocol that allows a client (you or your app) to perform operations on a server (the blockchain).

There are two major service providers that I am aware of for this: Infura and Alchemy. I have used Alchemy previously and reused an RPC that I created previously, but I urge you to investigate both and choose the best option for you.

Backend

The backend for this app is the blockchain, obviously! But which one?

The first decision is whether to deploy the contracts to a testnet or mainnet. The former does not use real assets of value whereas the latter does. I decided for my first onchain app to deploy to a testnet while learning the ropes, ensuring my own or any potential user funds are not in jeopardy. After all, this is a learning exercise.

Next decision which testnet? For this I decided to stick with Ethereum Sepolia, as it has all the integrations with major service providers you can ask for, like Alchemy and Chainlink. Also procuring Sepolia testnet eth to make transactions is pretty straightforward as there are plenty of faucets available.

Finally, I decided that I did not want all the data this app collects to be stored onchain. I used an SQLite database to store the descriptions of why each user is raising funds for their fund-raise. Storing this information on a db saves the users on gas fees. Additionally, I wanted the experience of working with SvelteKit and SQLite. I wanted to learn the pitfalls and proper patterns involved in CRUD operations with a frontend meta-framework and a db.

DevOps

“Work incredibly hard in order to be incredibly lazy“ - Patick Collins

I absolutely love this quote from Patrick. It captures the essence and ethos of software development so well. As a software engineer, you want to work exceedingly hard to automate your workflow as much as possible, so you can be lazy when developing. ‘Lazy’ meaning you can focus on only delivering value; as the tedious work that needs to be done around shipping is taken care of for you.

How does this translate to the Go Fund Yourself app?

I would like to set up the project so that any changes I push to the main branch of my repo are automatically deployed into production and accessible to users nearly immediately after I make these changes. This pertains to the changes made to the frontend, not the smart contracts which are immutable.

This raises the question of how am I hosting my frontend? After listening to the Lex Fridman podcast with Peter Levels, I was inspired to learn how to host my own applications on a VPS. There are a plethora of services that simplify the deployment and hosting process, however, according to this podcast it seems that Peter runs an entire empire using some VPS’ and Nginx. Furthermore, the hallmark of a great software engineer is the ability to rawdog it rather than using the latest abstracted solution.

So the DevOps requirement of this project is to spin up a VPS, set it up to run my SvelteKit application and then create a pipeline to allow the latest changes I have made to automatically be detected by the server, pulled in and then run so that they are accessible to the end users.

To achieve this I chose Hostinger for the VPS, Nginx for a reverse proxy, Certbot for SSL certificates to enable https and GitHub actions and Docker to create the pipeline.

Wrapping up

The purpose of this article was to explain the motivation for building Go Fund Yourself and the reasoning that went into selecting the different technologies in the tech stack.

While this started as an exercise to understand the process of onchain app development, I admittedly increased the scope of the project to include aspects of Web2 development that I haven’t had much experience in yet. I could have stored all the information about fund-raises on the blockchain, however, I chose to include an SQLite db, because I have never worked with this database before. Additionally, I wanted to understand the process of using a front-end meta-framework with a db. For deployment, I could have used Vercel or another similar service, however, I wanted to understand what it took to configure your own server and pipelines to better comprehend why these abstracted solutions have gained so much popularity. Is setting up your own server worth the heartache or should you just use Vercel? What are the tradeoffs? These are the questions I was seeking to answer.

This is just the first article in a series I am working on. Now that you know my thought process, I look forward to sharing with you how I built Go Fund Yourself. In this series, I will explore the pitfalls and learnings of each stage of the development process. I hope you can use this series to gain a better understanding of onchain development, as a blueprint to build your own onchain app or even as a tutorial to add to your portfolio on GitHub.

Make sure you subscribe to ensure you do not miss new instalments of this series:

And please feel free to mint to show support:

Look forward to seeing you in the next article where I delve into SvelteKit and front-end development. 👋

Project Setup

SvelteKit Initialisation

As aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release of the latest version Svelte 5, I made this project before that and everything you see was done using Svelte 4. Just giving you all the heads up that there will be no runes here. Luckily Svelte 4 is backwards compatible with Svelte 5, so you can use the latest version and reap all the new performance rewards without any consequences.

Step 1 of course is to create the project, which is easy enough using the CLI:

npx sv create go-fund-yourself-fe
cd go-fund-yourself-fe
npm install
npm run dev

Please note that I am currently in the root directory of my previously created fundme_foundry project.

When prompted for initial setup options, I chose:

1. Minimal template

2. no type checking

3. eslint & prettier

4. npm

SCSS

Alrighty, so personally I am a sass preprocessor type of guy, as I prefer to use SCSS to style components. A preprocessor extends the capabilities of vanilla CSS and adds features such as variables, nesting, mixins and functions.

If the above appeals to you, simply navigate to your svelte.config.js file and make the following changes to your imports and config:

import adapter from '@sveltejs/adapter-auto';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  kit: {
    adapter: adapter()
  },
  preprocess: [vitePreprocess()]
};

export default config;

Additionally, in the vite.config.js file, the following changes are required with newer versions of sass:

import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [sveltekit()],
  css: {
    preprocessorOptions: {
      scss: {
        api: 'modern-compiler'
      }
    }
  }
});

Design Philosophy

Go Fund Yourself needs a homepage.

This sounds simple enough, but while creating Go Fund Yourself I discovered I have very little in the way of design skills. I usually rely on professional designers to create great-looking frontends in Figma and do my best to bring their vision to life. Without this crutch, designing a website was initially quite an intimidating proposition.

A few questions sprang to mind when attempting to develop a design. What colours should be used? What fonts should be chosen? Should animations be incorporated to make it feel more alive and modern? How can Go Fund Yourself create a good first impression with new users?

Let’s tackle these questions one at a time.

Colour Scheme

I stumbled onto a great YouTuber by the name of Sajid. He has great practical design advice oriented towards devs. His video on random design tips starts with a guide on selecting colour palettes for a website and he even provides a site to pick the 4 distinct HSL values for you here.

These are the colour values I selected for Go Fund Yourself:

// Light mode colours
$PRIMARY_LIGHT: hsl(220, 50%, 90%); 
$SECONDARY_LIGHT: hsl(220, 50%, 10%); 
$TERTIARY_LIGHT: hsl(280, 80%, 20%); 
$ACCENT_LIGHT: hsl(160, 80%, 20%);

// Dark mode colours
$PRIMARY_DARK: hsl(220, 50%, 10%); 
$SECONDARY_DARK: hsl(220, 50%, 90%); 
$TERTIARY_DARK: hsl(280, 80%, 80%); 
$ACCENT_DARK: hsl(160, 80%, 80%);

Surfaces

Exploring style libraries to gain a better idea of how to bring a professional-looking website alive, I encountered Open Props. Open props have the idea of surfaces:

This allows content to be layered in a manner that visually informs the user of related content groupings. Each of the surfaces seen in the image above also has a box shadow to give it a more tactile feel and make the layering more apparent. Therefore shadow colour values must also be incorporated into the design.

I opted to adapt this surface concept into the CSS of the app rather than installing Open Props itself. I do not want to stand on the shoulders of giants with this project, I want to create everything from scratch and that means rawdogging the CSS in this case.

// Light mode colours
$LIGHT-SURFACE-1: hsl(220, 50%, 90%); 
$LIGHT-SURFACE-2: hsl(220, 50%, 95%);
$LIGHT-SURFACE-3: hsl(220, 50%, 100%);
$LIGHT-SHADOW-1: hsla(220, 50%, 10%, 0.3);
$LIGHT-SHADOW-2: hsla(220, 50%, 10%, 0.15);
$SECONDARY-LIGHT: hsl(220, 50%, 10%); 
$TERTIARY-LIGHT: hsl(280, 80%, 20%); 
$ACCENT-LIGHT: hsl(160, 80%, 20%);

// Dark mode colours
$DARK-SURFACE-1: hsl(220, 50%, 10%); 
$DARK-SURFACE-2: hsl(220, 50%, 15%); 
$DARK-SURFACE-3: hsl(220, 50%, 20%); 
$DARK-SHADOW-1: hsla(220, 50%, 90%, 0.3);
$DARK-SHADOW-2: hsla(220, 50%, 90%, 0.15);
$SECONDARY-DARK: hsl(220, 50%, 90%); 
$TERTIARY-DARK: hsl(280, 80%, 80%); 
$ACCENT-DARK: hsl(160, 80%, 80%);

Fonts

Previously, I used Google Fonts for all my font needs. To no one’s surprise, Google fonts is a font server provided by Google, with a plethora of fonts that can be added to your CSS.

However, recently I was made aware of Fontsource. Font source allows you to self-host fonts in your project, this provides a boost to performance as your app no longer needs to communicate with the Google font server and increases privacy compliance by also removing this interaction. I chose the Ubuntu sans-serif font for Go Fund Yourself.

You can add these fonts via the CLI:

npm install @fontsource-variable/ubuntu-sans

Main Style Sheet

Okay, now that we’ve made some key design decisions it’s time to put them into action. We will start by creating a main.scss file within a new directory in the lib directory called styles.

If you are not using a preprocessor you should just create a .css file and adapt the content appropriately.

// src/lib/styles/main.scss

@use '@fontsource-variable/ubuntu-sans';

// Light mode colours
$LIGHT-SURFACE-1: hsl(220, 50%, 90%);
$LIGHT-SURFACE-2: hsl(220, 50%, 95%);
$LIGHT-SURFACE-3: hsl(220, 50%, 100%);
$LIGHT-SHADOW-1: hsla(220, 50%, 10%, 0.3);
$LIGHT-SHADOW-2: hsla(220, 50%, 10%, 0.15);
$SECONDARY-LIGHT: hsl(220, 50%, 10%);
$TERTIARY-LIGHT: hsl(280, 80%, 20%);
$ACCENT-LIGHT: hsl(160, 80%, 20%);
$DISABLED-LIGHT: hsl(220, 50%, 35%);

// Dark mode colours
$DARK-SURFACE-1: hsl(220, 50%, 10%);
$DARK-SURFACE-2: hsl(220, 50%, 15%);
$DARK-SURFACE-3: hsl(220, 50%, 20%);
$DARK-SHADOW-1: hsla(220, 50%, 90%, 0.3);
$DARK-SHADOW-2: hsla(220, 50%, 90%, 0.15);
$SECONDARY_DARK: hsl(220, 50%, 90%);
$TERTIARY-DARK: hsl(280, 80%, 80%);
$ACCENT-DARK: hsl(160, 80%, 80%);
$DISABLED-DARK: hsl(220, 50%, 75%);

:root {
  --surface-1: #{$LIGHT-SURFACE-1};
  --surface-2: #{$LIGHT-SURFACE-2};
  --surface-3: #{$LIGHT-SURFACE-3};
  --shadow-1: #{$LIGHT-SHADOW-1};
  --shadow-2: #{$LIGHT-SHADOW-2};
  --secondary: #{$SECONDARY-LIGHT};
  --tertiary: #{$TERTIARY-LIGHT};
  --accent: #{$ACCENT-LIGHT};
  --disabled: #{$DISABLED-LIGHT};	
}

@media (prefers-color-scheme: dark) {
  :root {
    --surface-1: #{$DARK-SURFACE-1};
    --surface-2: #{$DARK-SURFACE-2};
    --surface-3: #{$DARK-SURFACE-3};
    --shadow-1: #{$DARK-SHADOW-1};
    --shadow-2: #{$DARK-SHADOW-2};
    --secondary: #{$SECONDARY-DARK};
    --tertiary: #{$TERTIARY-DARK};
    --accent: #{$ACCENT-DARK};
    --disabled: #{$DISABLED-DARK};
  }
}

body {
  background-color: var(--surface-1);
  color: var(--secondary);
  font-family: 'Ubuntu Sans Variable', sans-serif;
}

html,
body {
  height: 100%;
  margin: 0;
}

ul,
ol {
  list-style: none;
  margin: 0;
  padding: 0;
}

a {
  color: var(--accent);
}

Firstly, the font installed using fontsource was imported with the use keyword. Next, all the colours were declared as SCSS variables and a new colour was included for disabled buttons and fields for both the light and dark themes. The next two sections provide the scaffolding for theming changes to be toggled in the future. Presently, the default colour palette is set to light mode, however, when the user has dark mode enabled on their browser the dark theme colour palette overrides these values. Therefore by default, the theme of the website will be the same as the theme used by the browser. The CSS variables declared in the :root will be available to all our components as they are made available globally through inheritance.

Then the background colour, font colour and font style are all set in the body. Note fontsource will provide instructions for the font you have installed, as my font was serif, sans-serif is required in its declaration.

Finally, the height of the html and body elements are set to 100% to ensure the app takes the full height of the screen. Additionally, list styling and padding are removed by default for all ol and ul elements. This is for convenience, the nav bar and the footer components will use these lists and we would have to remove the default styling in each component, so it saves time removing globally. Also the the color of hyperlinks is changed to better fit the theme we have selected.

SvelteKit Route Files

It is time to create the landing page. This page will go in the routes directory, currently, there is one SvelteKit route file +page.svelte in this directory. Route files are marked with a + prefix in the file name. As SvleteKit uses filesystem-based routing, this +page.svelte file is the page that will load at the root URL https:localhost:5173/.

SvelteKit also offers a +layout.svlete file, which enables you to build a template to contain reoccurring elements that remain present between different pages such as a navbar or footer. Any good homepage will have a nav and a footer so let’s build out the +layout.svelte file.

// src/routes/+layout.svelte

<script>
  import '$lib/styles/main.scss';
</script>

<main>
  <slot />
</main>

They +layout also acts as an entry point for the main.scss file. Upon saving this you should notice the styles we added come to life. Additionally, a main tag was added to wrap the slot. This is for SEO purposes. slot is the tag that tells the Svelte compiler where the contents of the +page.svelte should be inserted within the structure of the +layout.svelte file.

Building the Landing Page

Nav bar

Now that the structure has been set it is time to start constructing the various pieces that the landing page is composed of, starting with the navbar. Navbars are on every page and look simple enough, but are always more time-consuming than you think in my experience. In any case, in the routes directory, a Navbar.svelte file can be added.

// src/routes/Navbar.svelte

<nav>
  <h2><a href="/">Go Fund Yourself</a></h2>
    <ul>
      <li><a href="/fund-yourself">Fund yourself</a></li>
      <li><a href="/fund-someone">Fund someone</a></li>
      <button>connect</button>
    </ul>
</nav>

Okay, it is important to note that SvelteKit has no specialised link component to change the route, it is all done via the a tag. Therefore, clicking the logo will take you to the home page or root URL /. Conversely, clicking the two list items will take you to different pages, where you can create and donate to different fund-raises respectively. Clicking on these two links will result in a 404 error, but these pages will be built later to fix this error. You can ignore it for now.

The navbar can now be added to the +layout.svelte file so that it is rendered to the main page.

// src/routes/+layout.svelte

<script>
  import '$lib/styles/main.scss';
  import Navbar from './Navbar.svelte';
</script>

<Navbar />
<main>
  <slot />
</main>

I think you’ll agree that in its present state, the navbar looks somewhere between plain to hideous, so let’s add some CSS to change that.

// src/routes/Navbar.svelte

<nav>
  <h2><a id="nav-logo" href="/">Go Fund Yourself</a></h2>
    <ul id="links-container">
      <li><a href="/fund-yourself">Fund yourself</a></li>
      <li><a href="/fund-someone">Fund someone</a></li>
      <button>Connect</button>
    </ul>
</nav>

<style scoped lang="scss">
  nav {
    align-items: center; 
    display: flex;
    flex-direction: row;
    gap: 2.5rem;
    margin-inline: auto;
    position: sticky;
    top: 0;
    width: 100%;
    z-index: 1;

    #nav-logo {
      display: block;
      position: relative;
      width: max-content;
    }

    ul {
      align-items: center;
      display: flex;
      gap: 2rem;
      position: relative;
      width: 100%;
    }
    
    button {
      background-color: var(--tertiary);
      border-radius: 6px;
      border: none;
      color: var(--surface-1);
      cursor: pointer;
      font-weight: 550;
      margin-left: auto;
      padding: 10px 12px;
      width: 100px;
    }
  }
</style>

Further changes will be added to the navbar, but this will do for now.

Footer

Footers are quite simple, as done with the navbar before it, a Footer.svelte file was created in the routes directory.

// src/routes/Footer.svelte

<footer id="site-footer">
  <section id="top-row">
    <h2 class="h3">Go Fund Yourself</h2>
  </section>
  <section id="bottom-row">
    <div id="funding-option">
      <h3 class="h6">Funding options</h3>
      <ul>
        <li><a href="/fund-yourself">Start you own fund raise</a></li>
    <li><a href="/fund-someone">Support another cause</a></li>
      </ul>
    </div>
    <div id="about-creator">
      <ul>
    <li>Go Fund Yourself &copy {new Date().getFullYear()}</li>
      </ul>
    </div>
  </section>
</footer>

<style scoped lang="scss">
  #site-footer {
    color: var(--surface-1);
    display: flex;
    flex-direction: column;
    padding-top: 2.5rem;
    padding-bottom: 2.5rem;
    position: relative;
    
    #bottom-row {
      display: flex;
      flex-direction: row;
      gap: 4rem;

      #about-creator {
    align-content: end;
        
        p {
      margin-bottom: 4px;
    }
      }
    }

    li {
      margin-bottom: 0.25rem;
    }
    
    a {
      color: var(--surface-1);
      text-decoration: none;
      
      &:hover {
        color: var(--tertiary);
      }
    }

    &::before {
      content: '';
      background-color: var(--secondary);
      height: 100%;
      left: 50%;
      position: absolute;
      top: 0;  
      transform: translateX(-50%);
      width: 100vw;
      z-index: -1;
    }
  }
</style>

Perfect, this can now be imported into the +layout.svelte file to complete the basic scaffolding of our landing page. However, there is a noticeable issue:

The +layout.svelte file can be modified to ensure that both the navbar and the footer are placed in their correct position at the top and bottom of the page respectively.

// src/routes/+layout.svelte

<script>
  import '$lib/styles/main.scss';
  import Navbar from './Navbar.svelte';
  import Footer from './Footer.svelte';
</script>

<div class="container">
  <Navbar />
  <main>
    <slot />
  </main>
  <Footer />
</div>

<style scoped lang="scss">
  .container {
    display: grid;
    grid-template-rows: auto 1fr auto;
    height: 100%;
    margin-inline: auto;
    max-inline-size: 1080px;
    padding-inline: 2rem;
  }
</style>

Much better:

Landing Page Content

When I was creating this project I was learning vim motions on vimified. Not only did it help me learn the shortcuts for vim, but it was also the inspiration for a simple yet effective landing page design.

// src/routes/+page.svelte

<div id="landing-container">
  <section id="landing-section">
    <h1>Go</h1>
    <h1>Fund</h1>
    <h1>Yourself.</h1>

    <div id="call-to-action">
      <button class="shadow-btn">Raise funds</button>
      <p>Harness the power of crowd-sourced fundraising today</p>
    </div>
  </section>
</div>

<style scoped lang="scss">
  #landing-section {
    align-items: center;
    display: flex;
    flex-direction: column;
    justify-content: center;
    margin-top: 60px;
    padding: 2.5rem;
    position: relative;

    h1 {
      font-size: 108px;
      margin: 0;
    }

    #call-to-action {
      align-items: center;
      display: flex;
      flex-direction: column;
      gap: 1rem;
      justify-content: center;
      margin-top: 2.5rem;
      padding-top: 2.5rem;	
    }
  }
</style>

You may have noticed that the class applied to the button is not present in the style of the component. Buttons are a key part of your application, they are a dynamic element and the element users interact with that action their requests. As such I have numerous different styles of buttons to convey the importance of the button and give it life.

// src/lib/styles/_buttons.scss

.connect-btn {
  background-color: var(--tertiary);
  border-radius: 6px;
  border: none;
  color: var(--surface-1);
  cursor: pointer;
  font-weight: 550;
  padding: 10px 12px;
  width: 100px;

  &:hover {
    background-color: var(--tertiary);
    transition: background-color 0.2s;
  }
}

.connected-btn {
  align-items: center;
  background-color: transparent;
  border-radius: 6px;
  border: none;
  color: var(--secondary);
  cursor: pointer;
  display: flex;
  font-weight: 550;
  gap: 1rem;
  justify-content: center;
  padding: 0.75rem;
  width: min-content;

  img,
  svg {
    max-height: 20px;
    max-width: 20px;
  }

  @media (max-width: 680px) {
    padding: 0.25rem;
  }
}

.shadow-btn {
  background-color: var(--tertiary);
  border-radius: 8px;
  border: none;
  color: var(--surface-1);
  cursor: pointer;
  font-weight: 550;
  min-width: 100px;
  padding: 12px;

  &:hover {
    box-shadow: 0px 0px 16px var(--tertiary);
  }
}

.power-btn {
  align-items: center;
  background-color: var(--surface-2);
  border: 1px solid var(--accent);
  border-radius: 12px;
  box-shadow: 0 2px var(--accent);
  color: var(--secondary);
  cursor: pointer;
  display: flex;
  gap: 0.5rem;
  padding: 12px 20px;
  
  &:hover {
    box-shadow: 0 4px var(--accent);
  }

  &:disabled {
    border: 1px solid var(--tertiary);
    box-shadow: 0 2px var(--tertiary);
  }

  img,
  svg {
    max-height: 16px;
    max-width: 16px;
  }
}

.table-filter-btn {
  background-color: transparent;
  border: none;
  color: var(--secondary);
  cursor: pointer;
  font-size: 14px;

  &:hover {
    border-bottom: 2px solid var(--tertiary);
    margin-bottom: -2px;
  }
}

.pagination-btn {
  align-items: center;
  background-color: transparent;
  border: 1px solid transparent;
  color: var(--secondary);
  display: flex;
  font-size: 14px;
  gap: 0.5rem;
  padding: 12px;

  &:hover:not(:disabled) {
    border-radius: 8px;
    border: 1px solid var(--secondary);
    cursor: pointer;
  }

  &:disabled {
    color: var(--disabled);
  }

  img,
  svg {
    max-height: 1rem;
    max-width: 1rem;
  }
}

.back-btn {
  align-items: center;
  background-color: transparent;
  color: var(--secondary);
  display: flex;
  font-size: 14px;
  gap: 0.25rem;
  padding: 12px;
  text-decoration: none;

  &:hover:not(:disabled) {
    text-decoration: underline;
    border-radius: 8px;
    cursor: pointer;
  }

  img,
  svg {
    max-height: 0.65rem;
    max-width: 0.65rem;
  }
}

.cancel-btn {
  background-color: transparent;
  border: 1px solid var(--secondary);
  border-radius: 8px;
  color: var(--secondary);
  cursor: pointer;
  padding: 0.75rem;

  &:hover {
    background-color: var(--surface-1);
  }
}

.max-btn {
  background-color: transparent;
  border: none;
  cursor: pointer;
  padding: 0.5rem;

  &:hover {
    text-decoration: underline;
  }
}

Importing these buttons into the main.scss will enable these classes to be used throughout the app.

// src/lib/styles/main.scss

@use 'buttons';

...

Animations… erm I mean transitions

Svelte has a fantastic offering of transitions to add life to different elements as they are added and removed to the DOM. A fade transition to the newly added +page.svelte content gives it more life and make the user’s entrance to the site feel more grandiose.

// src/routes/+pages.svelte

<script>
  import { onMount } from 'svelte';
  import { fade } from 'svelte/transition';

  // STATE VARS
  let landingPageVisible = false;

  // LIFECYCLE LOGIC
  onMount(() => {
    landingPageVisible = true;
    window.scrollTo(0, 0);
  });
</script>

<div id="landing-container">
  <section id="landing-section">
    {#if landingPageVisible}
      <h1 in:fade={{ delay: 100, duration: 1000 }}>Go</h1>
      <h1 in:fade={{ delay: 800, duration: 1000 }}>Fund</h1>
      <h1 in:fade={{ delay: 1500, duration: 1000 }}>Yourself.</h1>

      <button 
        in:fade={{ delay: 2200, duration: 1000 }} 
        class="shadow-btn"
      >Raise funds</button>
      <p>Harness the power of crowd-sourced fundraising today</p>
    {/if}
  </section>
</div>

fade comes from the svlete/transitions module, but it is possible to build custom transitions, that uses JavaScript or CSS to provide the animation behaviour. This article here explains custom transitions in depth.

The API for a custom transition is detailed below:

transition = (node: HTMLElement, params: any, options: { direction: 'in' | 'out' | 'both' }) => {
    delay?: number,
    duration?: number,
    easing?: (t: number) => number,
    css?: (t: number, u: number) => string,
    tick?: (t: number, u: number) => void
}

A transition is a function that has the following properties

• Takes a parameter node, which is a HTML element to which the transition will be applied.

• Can optionally, provide options for each stage of the transition, in when the element is being rendered, out when the component is being removed or both which encapsulates the previous two stages.

• Optionally returns a delay, time in ms before transition runs.

• Optionally returns a duration, the time in ms the transition will take to complete.

• Optionally returns easing, the rate of change of the transition within the duration it runs. E.g. does the animation take linear time to complete or speed up or slow down throughout the duration it runs.

• Must return either a css or tick callback that is the transition that will be applied to the element.

Here is an example of a custom transition used in Go Fund Yourself:

// src/lib/animationsAndTransitions/typewriter.js

export default function typewriter(node, { delay = 0, speed = 2 }) {
  const valid = node.childNodes.length === 1 && node.childNodes[0].nodeType === Node.TEXT_NODE;

  if (!valid) {
    throw new Error(`This transition only works on elements with a single text node child`);
  }

  const text = node.textContent;
  const duration = text.length / (speed * 0.01);

  return {
    delay,
    duration,
    tick: (t) => {
      const i = Math.trunc(text.length * t);
      node.textContent = text.slice(0, i);
    }
  };
}

The transition above does the following:

• It checks that the HTML element only contains text to which the typewriter effect will be applied and throws an error if this is not fulfilled.

• Stores the pure text in the var text

• Calculates duration based on the text length, the speed parameter which is defaulted to 2.

• Defines JavaScript function for the effect. The t value increases from 0 to 1 over the duration of the transition, as this value increases, more characters are added to the string slice, giving the effect that the characters are being typed out.

This can now be added to the call to action text below the button on the landing page on +page.svelte in the routes directory:

// src/routes/+page.svelte

...

<div id="landing-container">
  <section id="landing-section">
    {#if landingPageVisible}
      <h1 in:fade={{ delay: 100, duration: 1000 }}>Go</h1>
      <h1 in:fade={{ delay: 800, duration: 1000 }}>Fund</h1>
      <h1 in:fade={{ delay: 1500, duration: 1000 }}>Yourself.</h1>

      <button in:fade={{ delay: 2200, duration: 1000 }} class="shadow-btn">Raise funds</button>
      <p in:typewriter={{ speed: 2, delay: 2250 }}>
    Harness the power of crowd-sourced fundraising today
      </p>
    {/if}
  </section>
</div>

...

Finishing the Homepage

Promotional content

Now that there is a compelling and professional landing area for the user when they first visit the site, it is time to complete the rest of the landing page. To complete the this page, additional promotional content with call-to-action buttons was added. This will provide an explanation of the core offerings of the platform with immediate access points to these offerings. With the additional material added, the landing page code now looks as follows:

<script>
  import { onMount } from 'svelte';
  import { fade } from 'svelte/transition';
  import { typewriter } from '$lib';
  import { AidSVG, AnonymousSVG, ChainsSVG, GlobeSVG } from '$lib/assets';

  // STATE VARS
  let landingPageVisible = false;
  
  // LIFECYCLE LOGIC
  onMount(() => {
    landingPageVisible = true;
    window.scrollTo(0, 0);
  });
</script>

<div id="landing-container">
  <section id="landing-section">
    {#if landingPageVisible}
      <h1 in:fade={{ delay: 100, duration: 1000 }}>Go</h1>
      <h1 in:fade={{ delay: 800, duration: 1000 }}>Fund</h1>
      <h1 in:fade={{ delay: 1500, duration: 1000 }}>Yourself.</h1>

      <button in:fade={{ delay: 2200, duration: 1000 }} class="shadow-btn">Raise funds</button>
      <p in:typewriter={{ delay: 2200 }}>Harness the power of crowd-sourced fundraising today</p>
    {/if}
  </section>
  <section class="promo-section">
    <div class="promo-container" transition:fade>
      <div class="promo-card card">
        <h2>Raise funds for a special cause</h2>
        <p>
          This platform allows you to leverage the power of smart contracts on the blockchain to raise funds for any type of cause near and dear to your heart in a decentralized and permissionless manner.
        </p>
        <p>
          This means that Go Fund Yourself facilitates fund raising that is censorship resistant and global in its out-reach. No one can take down your fund-raising initiative and anyone with	an internet connection can contribute to your cause.
        </p>
        <p>Get started raising today.</p>
        <button 
          class="shadow-btn" 
          on:click={() => goto('/fund-yourself')}
        >Fund yourself</button>
      </div>
      <div class="promo-icon-container">
        <div class="promo-icon-card card">
      <GlobeSVG />
      <p>Raise globally</p>
    </div>
    <div class="promo-icon-card card">
      <ChainsSVG />
      <p>Raise without censorship</p>
    </div>
      </div>
    </div>
  </section>
  <section class="promo-section">
    <div class="promo-container">
      <div class="promo-card card">
        <h2>Donate to initiatives around the world</h2>
    <p>
      Donate to unique initiatives around the globe and aid different communities and people to help them achieve their goals.
        </p>
    <p>
      Being built on top of blockchain technology donations are pseudo-anonymous by default. So you can donate to different causes with piece of mind that your identity is not broadcasted every time you make a donation.
    </p>
    <p>Get started donating today.</p>
    <button 
          class="shadow-btn" 
          on:click={() => goto('/fund-someone')}
        >Fund someone</button>
      </div>
      <div class="promo-icon-container">
        <div class="promo-icon-card card">
      <AidSVG />
      <p>Aid communities across the world</p>
    </div>
    <div class="promo-icon-card card">
      <AnonymousSVG />
      <p>Pseudo-anonymous donations by default</p>
    </div>
      </div>
    </div>
  </section>
</div>

<style scoped lang="scss">
  #landing-section {
    align-items: center;
    display: flex;
    flex-direction: column;
    height: 80vh;
    justify-content: center;
    margin-top: 60px;
    padding: 2.5rem;
    position: relative;

    h1 {
      font-size: 108px;
      margin: 0;
    }

    button {
      margin-top: 5rem;
    }

    p {
      margin-bottom: 0;
      margin-top: 1rem;
    }
  }

  .promo-section {
    min-height: max-content;
    padding-block: 5rem;
    position: relative;
  }

  .card {
    background-color: var(--surface-2);
    border-radius: 20px;
    border-top: 4px solid var(--accent);
    box-shadow:
      0 2px 2px var(--shadow-1),
      0 4px 4px var(--shadow-2);
    padding: 2rem;
  }

  .promo-container {
    display: flex;
    gap: 2.5rem;

    .promo-card {
      flex: 1;

      button {
    margin: 1rem 0;
      }
    }

    .promo-icon-container {
      display: flex;
      flex-direction: column;
      gap: 1rem;

      .promo-icon-card {
        align-items: center;
    display: flex;
    flex-direction: column;
    flex: 1;
    height: auto;
    justify-content: center;
    padding: 1rem;

    p {
      font-weight: 500;
      margin-bottom: 0;
      max-width: 155px;
      text-align: center;
    }

    img {
      border-radius: 50%;
      max-height: 100px;
      max-width: 100px;
    }
      }
    }
  }
</style>

Please refer to this link for the code for SVG components that were added.

Okay, the content for the homepage is finished. However, just as was done for the landing section, animations can be added to the new content. To keep the UI decluttered and draw the user’s attention to the latest information, fade animations on scroll can be applied to the new content cards to fade in when visible and fade out when hidden.

Intersection Observer

How does one know when an element has scrolled into/out of view of the user? Fortunately, there is an established API supported by the major browsers that fulfils this purpose, the intersection observer API.

It is quite easy to work with this API, simply put by the MDN docs:

The Intersection Observer API allows you to configure a callback that is called when either of these circumstances occur:

• A target element intersects either the device's viewport or a specified element.

• The first time the observer is initially asked to watch a target element.

With this knowledge, intersection observers can be set up for both the fundraising and donation promotional sections. A state variable for each of these sections will be added, fundRaisingPromoVisibile and donationPromoVisible. These will initially be set to false and the class promo-section shared by the promo content will set the opacity to 0, ensuring the content is hidden initially.

// src/routes/+page.svelte

...

// STATE VARS
let landingPageVisible = false;
let fundRaisingPromoVisible = false;
let donationPromoVisible = false;

...

<style scoped lang="scss">
  ...

  .promo-section {
    height: max-content;
    opacity: 0;
    padding-block: 5rem;
    position: relative;
  }

  ...
</style>

These observers will fire a callback function when the element is 40% viewable and will set the viewable state variable to true, triggering the fade-in animation on scroll. Conversely, when the element is not 40% viewable the callback should fire again setting the visible state variable to false.

To create an intersection observer requires calling the observer’s constructor passing it the aforementioned callback and some initialisation options that dictate the type of intersection the observer is monitoring.

const observerOptions = {
  root: null,
  rootMargin: '0px',
  threshold: [0, 0.2, 0.4, 0.6, 0.8, 1]
};

These are the options passed to the observer constructor on the +page.svelte. The root refers to the element that is being intersected with or that is used to measure the visibility of the target element. If left null the root becomes the viewport itself or the content viewable on the screen by the user. rootMargin allow a margin around the root element to be added to expand or contract the viewable area of the target element. Finally, threshold is the ratio of the visibility of the target element again the root element. If an element is half viewable its threshold value is 0.5 if fully viewable 1 and if hidden 0. By providing an array of values for the threshold, the observer is able to update the visibility of the target element between the ticks of the provided threshold. In this case increments of 20%. For a practical demonstration of thresholds please refer to the MDN playground example in this article.

To instantiate an intersection observer is quite simple:

const observer = new IntersectionObserver(callback, options);

The options are ready, time to create the callback functions. Now as aforementioned, the goal of these callback functions is to set the visibility state variables of the content to true when 40% visible and false when less than 40% visible. This looks as follows:

// src/routes/+page.svelte

...

const showFundRaisingPromo = (entries) => {
  const [entry] = entries;

  if(entry.intersectionRatio >= 0.4) {
    fundRaisingPromoVisible = true;
  } else {
    fundRaisingPromoVisible = false;
  }
}

const renderDonationPromo = (entries) => {
  const [entry] = entries;

  if (entry.intersectionRatio >= 0.4) {
    donationPromoVisible = true;
  } else {
    donationPromoVisible = false;
  }
};

Intersection observer callbacks have an argument entries that contains a multitude of data about the intersection details of the target element. You can read more about this here.

intersectionRatio is the ratio of the target element's visibility against the root element. For example, if the root element was the viewport and half the target element was visible, the intersection ratio would be 0.5.

Now that the callbacks are prepared it is time to create the intersection observers to monitor the two content sections. These observers will be created in the onMount portion of the +page.svelte.

// src/routes/+page.svelte

...

// STATE VARS
let landingPageVisible = false;
let fundRaisingPromoVisible = false;
let donationPromoVisible = false;
let fundRaisingContainer;
let donationContainer;

// LIFECYCLE LOGIC
onMount(() => {
  landingPageVisible = true;
  window.scrollTo(0, 0);

  const observerOptions = {
    root: null,
    rootMargin: '0px',
    threshold: [0, 0.2, 0.4, 0.6, 0.8, 1]
  };

  const fundRaisingPromoObserver = new IntersectionObserver(
    renderFundRaisingPromo,
    observerOptions
  );

  const donationPromoObserver = new IntersectionObserver(
    renderDonationPromo, 
    observerOptions
  );

  fundRaisingPromoObserver.observe(fundRaisingContainer);
  donationPromoObserver.observe(donationContainer);

  return () => {
    fundRaisingPromoObserver.unobserve(fundRaisingContainer);
    donationPromoObserver.unobserve(donationContainer);

    fundRaisingPromoObserver.disconnect();
    donationPromoObserver.disconnect();
  };
});

// UTILITY FUNCTIONS
const renderFundRaisingPromo = (entries) => {
  const [entry] = entries;

  if (entry.intersectionRatio >= 0.4) {
    fundRaisingPromoVisible = true;
    console.log('Fund-raising promo is visible');
  } else {
    fundRaisingPromoVisible = false;
    console.log('Fund-raising promo is not visible');
  }
};

const renderDonationPromo = (entries) => {
  const [entry] = entries;

  if (entry.intersectionRatio >= 0.4) {
    donationPromoVisible = true;
    console.log('Donation promo is visible');
  } else {
    donationPromoVisible = false;
    console.log('Donation promo is not visible');
  }
};

In svelte you can use bind:this on an HTML element to have a reference to this element in the JavaScript code. That is what’s done for the fundRaisingContainer and donationContainer variables. The markup for these elements looks as follows:

// src/routes/+page.svelte

<section bind:this={fundRaisingContainer}>
  ...
</section>
<section bind:this={donationContainer}>
  ...
</section>

Continuing with the setup of the observers, it can be seen that the observer options are defined and then the observers are created using the callbacks and the observer options as seen below:

const fundRaisingPromoObserver = new IntersectionObserver(
    renderFundRaisingPromo,
    observerOptions
 );

 const donationPromoObserver = new IntersectionObserver(
   renderDonationPromo, 
   observerOptions
 );

Next, the observers need to be assigned a target element to observe:

fundRaisingPromoObserver.observe(fundRaisingContainer);
donationPromoObserver.observe(donationContainer);

Finally, the observers should be cleaned up and removed when leaving the homepage. The onMount lifecycle hook will run any function returned from the lifecycle hook. Therefore, the observer cleanup code can be written here:

return () => {
  // Halt observing html elements
  fundRaisingPromoObserver.unobserve(fundRaisingContainer);
  donationPromoObserver.unobserve(donationContainer);

  // Close the intersection observers
  fundRaisingPromoObserver.disconnect();
  donationPromoObserver.disconnect();
};

As can be observed from the console, the observers are functioning correctly. They fire the callbacks and update the state variables when the scroll changes and content visibility is updated. The final step is to create animations for these observers to trigger to complete the homepage.

Animations on scroll

To implement this functionality, CSS keyframes and animations can be used:

// src/lib/animationsAndTransitions/fade.scss

@keyframes fadeIn {
  0% {
    opacity: 0;
  }

  100% {
    opacity: 1;
  }
}

@keyframes fadeOut {
  0% {
    opacity: 1;
  }

  100% {
    opacity: 0;
  }
}

.fade-in {
  animation: fadeIn 0.75s ease-in forwards;
}

.fade-out {
  animation: fadeOut 0.5s ease-in forwards;
}

This file was added to the previously created animationsAndTransitions directory. The @keyframes allows animations to be generated by specifying how the style of an element should change over time. Here we change opacity from 0 to 1 or vice versa. This creates the animation of a fade-in/out. Once these changes are defined, they can be applied using the animation property. The fade-in and fade-out classes will apply the keyframes to HTML elements that possess the class. The animation property includes several parameters. Examining the fade-in class:

• First is, the name of the @keyframes animation to use. fadeIn in this case.

• Second is, the amount of time to complete one cycle of the animation. This is 0.75s above.

• Next is animation-timing-function , this defines the rate of change of the animation. E.g. linear, ease-in, etc. ease-in is used to start the animation slowly and then gradually speed up.

• Finally, animation-direction controls whether the animation plays forward, backward or alternates. forward was used above to play the animation from 0% to 100% and retain the final style of the element.

The complete list of parameters can be found here.

Next, we need to import these animations into the main.scss file using the use keyword to ensure that these new animation classes are available in all the Svelte components.

// src/lib/styles/main.scss

@use 'buttons';
@use '@fontsource-variable/ubuntu-sans';
@use '../animationsAndTransitions/fade.scss';

...

Next, these classes can be applied to the new content in +page.svelte:

// src/routes/+page.svelte

...

<section
  bind:this={fundRaisingContainer}
  class={`promo-section ${fundRaisingPromoVisible ? 'fade-in' : 'fade-out'}`}
>
  ...		
</section>
<section
  class={`promo-section ${donationPromoVisible ? 'fade-in' : 'fade-out'}`}
  bind:this={donationContainer}
>
  ...
</section>

And voilà a simple yet modern and interactive landing page.

Please refer to the GitHub repo for the full source code of the completed part 1 code.

Transitions vs CSS animations with keyframes

You may be wondering why CSS animations were used on the content sections as opposed to svelte transitions, which were used on the landing section. This is a fair point to wonder and I want to explain my rationale behind this choice.

Firstly, recall that svelte transitions can only be applied to an element when it is entering or leaving the DOM as a result of a state change. This is trivial to set up, there are already visibility state variables for each of the content sections. The content within the <section> tags could be wrapped in a conditional template {#if isVisible} … {/if} and then transitions could be applied to the content. However, the height of the content sections (.promo-section) is: max-content. This presents an issue with the intersection observer. If the content is not yet rendered because it is not visible, then the section has no content and its height is zero. This means the observer can never observe it intersecting with the viewport, as having a height of zero effectively makes the element invisible. Therefore, the visibility state variable will never be updated and the content will never show.

Of course, it is possible to specify a min-height to be portion of the vh as done with the landing section, however, I did not wish to do that. I wanted the height of the container to accommodate only the amount of space required. This is why I used keyframes and animations. The intersection observer could update state variables which would modify the class applied to the content creating the same effect. However, this approach ensures there’s no popping or excessive space taken for content on the page, creating the best user experience.

Wrapping up

I would like to reiterate that all code from this section can be found here. This article explored and discussed a number of topics:

• SvelteKit Project Set up

• The UI Deisgn Philosophy

• SvelteKit Route Files

• Svelte Transitions

• Intersection Observers

• CSS Keyframes and Animations

At the conclusion of this article, a modern homepage has been built and the foundation has been laid to create other components and pages, as well as implementing features such as toggling between light and dark themes.

The next instalment will explore these topics and should be out shortly.

If you found this article helpful please subscribe for notifications about future articles and mint to show you support!

See you in the next one👋