Forem: Theodorus Clarence

Gradient Border is Unexpectedly Hard

Theodorus Clarence — Mon, 15 Jul 2024 15:14:26 +0000

Introduction

I was doing a design revamp for this blog, and my designer came up with a button that looks like this.

Looks great, right?

I thought to myself, that would be simple enough to make: a button, with a transparent and blur background, and add in a gray-ish gradient border around it. Probably something like border: 1px solid linear-gradient() would definitely work.

Spoiler: I was wrong

Border Gradient Attempt

So I set my goal, to build a proof of concept.

I whipped out a simple codepen, and created a button with a linear gradient border.

button {
  all: unset;
  font-family: sans-serif;
  font-size: 2rem;

  padding: 1rem 2rem;
  background: #172554;
  color: white;

  border: 1px solid linear-gradient(to bottom right, red, orange, yellow, green, blue, indigo, violet);
}

That must be the most colorful gradient known to man. I was confident that it would work.

It must be a dry season because I can’t see any rainbow!

Yeah, turns out linear-gradient does not work with border.

Stacked Element Method

As a seasoned problem solver, I went to google, searched “How to make a gradient border in CSS”, and found an interesting method:

You basically create two divs, first is for the rainbow background, and second one is the button text itself. It sounds like a great idea.

I updated my code using a pseudo element as a background.

button {
  all: unset;
  position: relative;

  font-family: sans-serif;
  font-size: 2rem;

  padding: 1rem 2rem;
  background: #000;
  color: white;
  /* formula for 2 stacked radius is: (radius - (border-width / 2)) */
  border-radius: calc(12px - (2px / 2));
}

button::before {
  content: '';
  position: absolute;
  /* this is the border width */
  inset: -2px;
  z-index: -1;
  background: linear-gradient(
    to bottom right,
    red,
    orange,
    yellow,
    green,
    blue,
    indigo,
    violet
  );
  border-radius: 12px;
}

IT WORKS!

The code looks a bit complicated, but it does the job. I was really happy about it.

Adding a transparent background

I continued my work by adding the transparent and blurred background.

button {
  background: rgba(0, 0, 0, 0.1);
  backdrop-filter: blur(1px);
}

And it looks like this:

Remember that we have a rainbow div behind? Introducing a translucent background means we will see the rainbow.

If you think that maybe we can try making a rainbow background with a hollow transparent background in the middle, that would be called a gradient border 🙃. So we're back to square one.

Ultimate Solution with Mask Exclude

So I did some more digging, and found the perfect solution that can cater all cases.

There’s a new property that’s recently gained a major support across browsers which is mask-composite.

According to CSS Tricks, we can remove a certain part of element by creating mask with 2 elements on top of each other, and use mask-composite exclude.

That means, if we create two boxes with one smaller than the other, we can have a mask that can show anything we like.

With mask, the element's background will be reflected. This even includes background-image.

Final Code

This is how the final code looks like!

button {
  all: unset;
  position: relative;

  font-family: sans-serif;
  font-size: 1rem;

  padding: 1rem 2rem;
  background: rgba(255, 255, 255, 0.05);
  backdrop-filter: blur(2px);
  color: white;
  border-radius: 12px;
}

button::before {
  content: '';
  position: absolute;
  z-index: -1;
  inset: 0px;

  border-radius: inherit;
  /* this is the border width */
  padding: 1px;
  background: linear-gradient(
    to bottom right,
    #171717 0%,
    #525252 62%,
    #171717 100%
  );
  -webkit-mask: linear-gradient(#fff 0 0) content-box, linear-gradient(#fff 0 0);
  mask: linear-gradient(#fff 0 0) content-box, linear-gradient(#fff 0 0);
  -webkit-mask-composite: xor;
  mask-composite: exclude;
}

Reference: https://stackoverflow.com/a/51496341

Final Words

There you have it! A working set of gradient border with translucent background. With this new widely-supported property, we can create anything that comes to mind.

Including something like this:

ps: I can’t open-source this because it’s from work ✌️. But it's using the same method!

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Like this post? Subscribe to my newsletter to get notified every time a new post is out!

How to Create Fully Reusable React Components

Theodorus Clarence — Thu, 14 Dec 2023 12:51:04 +0000

Introduction

Creating a React component is fairly easy, just a function like this, and it’s done.

export default function Card() {
  return <div>card</div>;
}

then you can call them using JSX like <Card />.

However, to do them correctly is the reason that I write this blog. I’ve been wanting to write this for quite some time.

Doing them correctly may come naturally to developers who have been writing React for quite a while, but not for beginners. This is something that I learned the hard way over experience, nobody really taught me this. I want you who are currently reading to get them quickly.

The Common Flaw

If you look at the Card component that I created above, it has one crucial flaw: it’s not fully reusable.

But wait, it is reusable?!

Well yes, you can use them multiple times in different files.

// order page
<Card />

// product list page
{[...].map((product) => <Card />)}

But they are not fully reusable

A fully reusable component is what I call a component that is enjoyable to use. It’s not something that frustrates you, every time you need to customize the component. It’s something that actually helps you code quickly by being reusable.

Flawed Component in Action

Let’s say you have a layout like this

We can easily achieve them using this code:

*I use Tailwind CSS for this demo, but the concept applies to all solutions.

export default function ProductListPage() {
  return (
    <div className='grid-cols-3'>
      {products.map((product) => (
        <Card key={product.id} product={product} />
      ))}
    </div>
  );
}

function Card({ product }: { product: Product }) {
  return <div className='border p-1'>{product.title}</div>;
}

So we have a three-column grid, and we map all of the cards inside that grid. Inside the card we have a product props that renders the title. Pretty simple right?

Here’s how it went haywire.

Customization in Flawed Components

Then your lovely designer has requests:

Make the first card span over 2 columns (it’s for featured products)
When we click a product with a title containing ‘yay’, I want them to shoot out confetti by calling confetti().

Well, you could create two brand new components called FeatureCard and ConfettiCard, but it’s counter-productive. Everything inside is totally the same, except that one uses two columns, and one shoots confetti.

Usually, when have this kind of situation, we rely upon custom props for each condition. But it goes downhill pretty quickly as the requirements grow.

type CardProps = {
  product: Product;
  isFeatured?: boolean;
  shootsConfetti?: boolean;

  isFeaturedThreeColumns?: boolean;
  isFeaturedButMakeItPop?: boolean;
  // 20 other props that your designer needs
};

function Card({ product, ...props }: CardProps) {
  return (
    <div
      // clsx is a simple library to combine string together
      className={clsx([
        'border p-1',
        props.isFeatured && 'col-span-2',
        props.isFeaturedThreeColumns && 'col-span-3',
        props.isFeaturedButMakeItPop && 'bg-pink-500',
      ])}
      onClick={() => {
        if (props.shootsConfetti) {
          confetti();
        }
      }}
    >
      {product.title}
    </div>
  );
}

I agree that using custom props sometimes be the best solution, but we can totally this problem if we can directly pass classNames and onClick directly into the component.

Fully Reusable Component as A Solution

So what we basically need, is to add all of the props that are in a div to the component, that concludes className, onClick, onHover, title, aria-label, style, about, id, onMouseEnter, onMouseLeave. Yeah, you got my point.

It’s A LOT.

Don’t worry we have a type for that, may I introduce React.ComponentPropsWithoutRef<'div'>. So instead of adding each and every component props, we can use this helpful type.

type CardProps = {
  product: Product;
} & React.ComponentPropsWithoutRef<'div'>;

function Card({ product, ...rest }: CardProps) {
  // {...rest} is grabbing all of the props,
  // then spreading them back to our div
  return <div {...rest}>{product.title}</div>;
}

This also applies to any element you’re using: <'input'>, <'button'>, anything!

The best thing is we now get autocomplete! Woohoo!

With the updated component, we can finally make our designer happy with this implementation

export default function ProductListPage() {
  return (
    <div className='grid-cols-3'>
      {products.map((product, i) => (
        <Card
          key={product.id}
          product={product}
          className={clsx([i === 0 && 'col-span-2'])}
          onClick={() => {
            if (product.title.contains('yay')) confetti();
          }}
        />
      ))}
    </div>
  );
}

We can add the two-columns feature by adding a custom className, and the confetti feature by adding an onClick directly in the Card component.

Common Pitfalls & Solutions

By using fully reusable components, there are some pitfalls that you might encounter. I compiled some of them along with the solutions that I came up with.

Class Name Conflict

If you’re using Tailwind CSS, sometimes merging classes will cause a conflict

function Card({
  product,
  // Don't forget to take className out of the rest parameter
  className,
  ...rest
}: CardProps) {
  return (
    <div className={clsx(['mt-4', className])} {...rest}>
      {product.title}
    </div>
  );
}

<Card className='mt-12' />;

We merge the className using clsx function, so any class that we pass outside of the component will be reflected in the final code.

However, in the rendered code we will have two different margin-top classes.

<div class='mt-12 mt-4'>...</div>

Which is not good. We can use tailwind-merge library to solve that.

tailwind-merge function will return the latest value in the parameter. So it will prioritize our mt-12 over the mt-4. Basically what we need.

import { twMerge } from 'tailwind-merge';

twMerge('mt-4 bg-red hover:bg-dark-red', 'mt-12 bg-[#B91C1C]');
// → 'hover:bg-dark-red mt-12 bg-[#B91C1C]'

I usually create a wrapper with clsx like this

import clsx, { ClassValue } from 'clsx';
import { twMerge } from 'tailwind-merge';

/** Merge classes with tailwind-merge with clsx full feature */
export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs));
}

So we now can merge conflicts and compose classes neatly.

You can safely customize your component now!

type CardProps = {
  product: Product;
} & React.ComponentPropsWithoutRef<'div'>;

function Card({ product, className, ...rest }: CardProps) {
  return (
    <div className={cn(['mt-4', className])} {...rest}>
      {product.title}
    </div>
  );
}

Multiple Class Name

When you start to have more items inside the component, it can be quite confusing as to how to pass a className to a specific element.

Let’s say our Card component has a title, description, and images. We already use className props for the wrapper div. How can we customize the title class?

type CardProps = {
  product: Product;
} & React.ComponentPropsWithoutRef<'div'>;
function Card({ product, className, ...rest }: CardProps) {
  return (
    <div className={cn('mt-4', className)} {...rest}>
      <h1>{product.title}</h1>
      <p>{product.description}</p>
      <img src={product.image} />
    </div>
  );
}

// How to access h1, p, and img?
<Card className='' />;

Usually, for the normal className props, I always use it for the outermost element (wrapper). The solution is to create another object for a specific element that I might need.

type CardProps = {
  product: Product;
  classNames?: {
    title?: string;
    description?: string;
    image?: string;
  };
} & React.ComponentPropsWithoutRef<'div'>;
function Card({ product, className, classNames, ...rest }: CardProps) {
  return (
    <div className={clsx('mt-4', className)} {...rest}>
      <h1 className={cn(classNames?.title)}>{product.title}</h1>
      <p className={cn(classNames?.description)}>{product.description}</p>
      <img className={cn(classNames?.image)} src={product.image} />
    </div>
  );
}

<Card classNames={{ title: 'text-red-500', image: 'aspect-square' }} />;

Here I created a classNames object with title, description, and image property. Then we can use them to merge the class in the respective element.

Components With Ref

You might notice that the type name is ComponentPropsWithoutRef, yes there is another type called ComponentPropsWithRef.

This is a needed case if you’re also forwarding ref to your component. I won’t explain in detail about ref forwarding, maybe in the next post (comment if you’d like me to write about it).

Simply, ref forwarding is needed when you want to access the ref value of your component. Usually external library like Radix does.

You can add the type like this.

type ButtonProps = React.ComponentPropsWithRef<'button'>;

const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
  ({ className, children, ...rest }, ref) => {
    return (
      <button ref={ref} className={cn(className)} {...rest}>
        {children}
      </button>
    );
  }
);

export default Button;

Only then you can access the ref.

function Page() {
  const buttonRef = React.useRef<HTMLButtonElement>(null);

  React.useEffect(() => {
    buttonRef.current?.focus();
  }, []);

  return (
    <div>
      <Button type='submit' disabled ref={buttonRef}>
        Submit
      </Button>
    </div>
  );
}

See how I easily add type and disabled props because we’re using a fully reusable component? *chef’s kiss*

Conclusion

Please use fully reusable components. Your teammates and your future-self will thank you.

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Like this post? Subscribe to my newsletter to get notified every time a new post is out!

Next.js Authentication using Higher-Order Components

Theodorus Clarence — Sat, 18 Mar 2023 15:55:38 +0000

Introduction

Managing authentication in Next.js is quite tricky, with problems such as content flashing. In this blog, I won't address the problems and explain how to solve it in detail, because I've written a blog about that in Next.js Redirect Without Flashing Content.

In this blog, I'll cover how to handle them cleanly using Higher Order Components.

The Usual Way & The Problem

Usually for the authentication in Next.js, we define routes that need to be blocked like so:

const protectedRoutes = ['/block-component', '/profile'];

Then we have a component that checks the route like this:

export default function PrivateRoute({ protectedRoutes, children }) {
  const router = useRouter();
  const { isAuthenticated, isLoading } = useAuth();

  const pathIsProtected = protectedRoutes.indexOf(router.pathname) !== -1;

  useEffect(() => {
    if (!isLoading && !isAuthenticated && pathIsProtected) {
      // Redirect route, you can point this to /login
      router.push('/');
    }
  }, [isLoading, isAuthenticated, pathIsProtected]);

  if ((isLoading || !isAuthenticated) && pathIsProtected) {
    return <FullPageLoader />;
  }

  return children;
}

This works, but there are several problems:

It's not colocated, the placement of authentication is not located in the page itself, instead in another component such as PrivateRoute
Error Prone, when you're doing route changes, for example: if you're moving the pages/blocked-component.tsx file to pages/blocked/component.tsx, you will have to change the protectedRoutes variable into the new route.

This is quite dangerous because with the protectedRoutes variable, there are no type checking because there is no way for TypeScript to know if that's the right path. (maybe soon)

Higher-Order Component

My friend and I built a higher-order component that we can put inside the page like so:

export default withAuth(ProtectedPage);
function ProtectedPage() {
  /* react component here */
}

With this implementation, it's now colocated within the page and it won't be a problem if you change the file name.

Adding Several Types of Pages

In my experience of building simple authenticated apps, there are 3 type of authenticated pages that we need to support

For the demo, you can try it yourself on the demo page

1. Simple Protected Pages

It's for pages that need protection, such as dashboard, edit profile page, etc.

Behavior

Unauthenticated users will be redirected to LOGIN_ROUTE (default: /login), without any content flashing
Authenticated users will see this page in this following scenario:
- Direct visit using link → user will see a loading page while the withAuth component checks the token, then this page will be shown
- Visit from other pages (router.push) → user will see this page immediately

2. Authentication Pages (Login)

It's for pages such as Login and Register or any other page that suits with the behavior.

Behavior:

Unauthenticated users can access this page without any loading indicator
Authenticated users will be redirected to HOME_ROUTE (default: /).
- We're assuming that authenticated users won't need to see login anymore. Instead, they should be redirected to the HOME_ROUTE.
- It's also best to hide all links back to the login page when the users is already authenticated.

3. Optional Page

This is a more specific use case, but sometimes there are pages that you don't need to be authenticated to visit, but you still need to show the users details if they are authenticated.

Behavior:

This page is accessible to all users
You can get the user from useAuthStore.useUser()

Page Focus Synchronization

We also added a page focus listener. When you open several tabs, the authentication will be synced across tabs.

React.useEffect(() => {
  // run checkAuth every page visit
  checkAuth();

  // run checkAuth every focus changes
  window.addEventListener('focus', checkAuth);
  return () => {
    window.removeEventListener('focus', checkAuth);
  };
}, [checkAuth]);

Source Codes

We use Zustand to store authentication data globally

Zustand Store

import { createSelectorHooks } from 'auto-zustand-selectors-hook';
import produce from 'immer';
import create from 'zustand';

import { User } from '@/types/auth';

type AuthStoreType = {
  user: User | null;
  isAuthenticated: boolean;
  isLoading: boolean;
  login: (user: User) => void;
  logout: () => void;
  stopLoading: () => void;
};

const useAuthStoreBase = create<AuthStoreType>((set) => ({
  user: null,
  isAuthenticated: false,
  isLoading: true,
  login: (user) => {
    localStorage.setItem('token', user.token);
    set(
      produce<AuthStoreType>((state) => {
        state.isAuthenticated = true;
        state.user = user;
      })
    );
  },
  logout: () => {
    localStorage.removeItem('token');
    set(
      produce<AuthStoreType>((state) => {
        state.isAuthenticated = false;
        state.user = null;
      })
    );
  },
  stopLoading: () => {
    set(
      produce<AuthStoreType>((state) => {
        state.isLoading = false;
      })
    );
  },
}));

const useAuthStore = createSelectorHooks(useAuthStoreBase);

export default useAuthStore;

withAuth HOC Component

import { useRouter } from 'next/router';
import * as React from 'react';
import { ImSpinner8 } from 'react-icons/im';

import apiMock from '@/lib/axios-mock';
import { getFromLocalStorage } from '@/lib/helper';

import useAuthStore from '@/store/useAuthStore';

import { ApiReturn } from '@/types/api';
import { User } from '@/types/auth';

export interface WithAuthProps {
  user: User;
}

const HOME_ROUTE = '/';
const LOGIN_ROUTE = '/login';

const ROUTE_ROLES = [
  /**
   * For authentication pages
   * @example /login /register
   */
  'auth',
  /**
   * Optional authentication
   * It doesn't push to login page if user is not authenticated
   */
  'optional',
  /**
   * For all authenticated user
   * will push to login if user is not authenticated
   */
  'all',
] as const;
type RouteRole = (typeof ROUTE_ROLES)[number];

/**
 * Add role-based access control to a component
 *
 * @see https://react-typescript-cheatsheet.netlify.app/docs/hoc/full_example/
 * @see https://github.com/mxthevs/nextjs-auth/blob/main/src/components/withAuth.tsx
 */
export default function withAuth<T extends WithAuthProps = WithAuthProps>(
  Component: React.ComponentType<T>,
  routeRole: RouteRole
) {
  const ComponentWithAuth = (props: Omit<T, keyof WithAuthProps>) => {
    const router = useRouter();
    const { query } = router;

    //#region  //*=========== STORE ===========
    const isAuthenticated = useAuthStore.useIsAuthenticated();
    const isLoading = useAuthStore.useIsLoading();
    const login = useAuthStore.useLogin();
    const logout = useAuthStore.useLogout();
    const stopLoading = useAuthStore.useStopLoading();
    const user = useAuthStore.useUser();
    //#endregion  //*======== STORE ===========

    const checkAuth = React.useCallback(() => {
      const token = getFromLocalStorage('token');
      if (!token) {
        isAuthenticated && logout();
        stopLoading();
        return;
      }
      const loadUser = async () => {
        try {
          const res = await apiMock.get<ApiReturn<User>>('/me');

          login({
            ...res.data.data,
            token: token + '',
          });
        } catch (err) {
          localStorage.removeItem('token');
        } finally {
          stopLoading();
        }
      };

      if (!isAuthenticated) {
        loadUser();
      }
    }, [isAuthenticated, login, logout, stopLoading]);

    React.useEffect(() => {
      // run checkAuth every page visit
      checkAuth();

      // run checkAuth every focus changes
      window.addEventListener('focus', checkAuth);
      return () => {
        window.removeEventListener('focus', checkAuth);
      };
    }, [checkAuth]);

    React.useEffect(() => {
      if (!isLoading) {
        if (isAuthenticated) {
          // Prevent authenticated user from accessing auth or other role pages
          if (routeRole === 'auth') {
            if (query?.redirect) {
              router.replace(query.redirect as string);
            } else {
              router.replace(HOME_ROUTE);
            }
          }
        } else {
          // Prevent unauthenticated user from accessing protected pages
          if (routeRole !== 'auth' && routeRole !== 'optional') {
            router.replace(
              `${LOGIN_ROUTE}?redirect=${router.asPath}`,
              `${LOGIN_ROUTE}`
            );
          }
        }
      }
    }, [isAuthenticated, isLoading, query, router, user]);

    if (
      // If unauthenticated user want to access protected pages
      (isLoading || !isAuthenticated) &&
      // auth pages and optional pages are allowed to access without login
      routeRole !== 'auth' &&
      routeRole !== 'optional'
    ) {
      return (
        <div className='flex min-h-screen flex-col items-center justify-center text-gray-800'>
          <ImSpinner8 className='mb-4 animate-spin text-4xl' />
          <p>Loading...</p>
        </div>
      );
    }

    return <Component {...(props as T)} user={user} />;
  };

  return ComponentWithAuth;
}

For more code and implementation examples check out the code on GitHub

Attribution

Rizqi Tsani, co-creator of this code.
Next Auth, for the inspiration and the idea of using HOC to handle authentication.

Conclusion

This will be a great addition to your code, making it cleaner and more efficient. You should colocate your code as much as possible, and this will be a step to do that.

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Like this post? Subscribe to my newsletter to get notified every time a new post is out!

Understanding Swift's Value and Reference Types

Theodorus Clarence — Wed, 11 May 2022 08:04:52 +0000

Introduction

There are two kinds of types in Swift, which are Value and Reference Types. These types and their characteristics sometimes can be hard to remember and understand. Through this post, I'll try to explain it using a mental model and analogy which will help you easily master swift types.

Primitives

If you use common programming languages (Java, JavaScript, etc) before, you must be familiar with primitives and non-primitives data types. I'm not going to jump into the details of primitives, but here are some illustrations I got from google.

Usually, primitives conclude specific data types such as boolean, char, integer, and float.

Does Swift have primitive types?

No, Swift doesn't have primitive types. In a sense. Swift still provides 'primitive-like' data types such as Int, Bool, Double, etc. However, they are made with struct.

If you look into Swift's Int type definition, you can see that it is made with a struct

Interesting right?

Quick Intro to Mental Model

A mental model is an explanation of someone's thought process about how something works in the real world. It is a representation of the surrounding world. - Wikipedia

You might be familiar with this variable box analogy:

We think of variables as containers that hold information and allow us to access them later. We will think of this as a box that has a label on it. - StudeApps

This works wonders when you are trying to understand what a variable does.

That is a mental model. You create a certain type of analogy to help you understand a concept.

The prior analogy is not a one-size-fits-all, I won't be using it to explain value & reference type. So prepare for some changes 💪

Value and Reference Types

There are two kinds of types in Swift which are Value Types, and Reference Types. Value types are usually defined as struct, enum, and tuple. Whereas the latter is usually defined as a class

Wire Analogy

I'm going to use a new mental model for variables, which uses a wire to point to the value it holds.

Therefore each variable can point to a single value according to its data type.

Value Types

A value type is a type whose value is copied when it's assigned to a variable or constant, or when it's passed to a function - Swift Docs

Remember that 'primitive' data types like Int, Double, String, etc. are made with struct. So they follow the value type mental model.

Mental Model

Let's say we have a struct of Animal (the behavior is also the same with enum, tuple, also Int, String because they're made with struct)

struct Animal {
    var legs = 4
}

var sheep = Animal()

Then, we are assigning the cow variables with the value of sheep

var cow = sheep

Key point: the value will be copied.

Effect of Copying

After we copy, the sheep and cow variables now points to two different struct. Therefore if we mutate the cow, the sheep won't get affected, and vice versa.

struct Animal {
    var legs = 4
}

var sheep = Animal()
var cow = sheep

// mutating cow's property
cow.legs = 3

print(sheep.legs) // 4
print(cow.legs) // 3

Reference Types

A reference types is where instances share a single copy of the data when they're assigned to a variable or constant, or when they're passed to a function.

In the wire analogy, it will point to the same value. We're using a class that behaves as a reference type.

Mental Model

class Animal {
    var legs = 4
}

var sheep = Animal()
var cow = sheep

Key Point: It will share a single copy

Effect of Sharing A Single Copy

I believe you already guessed correctly how it will behave. If we mutate one variable, both will be affected.

class Animal {
    var legs = 4
}

var sheep = Animal()
var cow = sheep

// mutating cow's property
cow.legs = 3

print(sheep.legs) // 3
print(cow.legs) // 3

Proof

To prove that it is sharing a single copy, we can use === (identity equality). It will return true if two reference point to the same object instance.

Let's throw in a new instance called pig

var sheep = Animal()
var cow = sheep

// created a new instance
var pig = Animal()

Here's the wire

Then we can compare them using identity equality

print(sheep === cow) // true
print(sheep === pig) // false

When in doubt, draw the wire analogy to help you. I'm using excalidraw for the illustration

Reference Types Inside of Value Types

Important thing to note is: If you are referencing a class inside of a struct, then that variable will still behave like the reference type

class Leg {
    var count = 4
}

struct Animal {
    var name: String
    var legs = Leg()
}

var sheep = Animal(name: "Sheep")
var cow = sheep

sheep.legs.count = 3

print(sheep.legs.count) // 3
print(cow.legs.count) // 3

// referencing the same class
print("\(sheep.legs === sheep.legs)") // true

Additional Emphasis

I need to emphasize this in case you're coming from a JavaScript background.

In Swift, Array and Dictionary are all value types.

It is still made with struct 😬

How to Choose?

I don't have much experience with this yet, so I'll quote an article instead

Use a value type when:

Comparing instance data with == makes sense
You want copies to have an independent state
The data will be used in code across multiple threads

Use a reference type (e.g. use a class) when:

Comparing instance identity with === makes sense
You want to create a shared, mutable state

I believe that using value type for overall use will be sufficient. We can trust that when we change one variable/property, it won't affect the others. Thus, creating a sense of safety and reliability.

Keep a note that this difference only happens when you mutate. In absence of mutation, values and references act exactly the same way.

Functions & In-Out

Function parameter follows value types. This means you can't mutate the parameter and change the value.

Swift won't even let you mutate them. Because what is passed in the parameter will be converted into a let variable.

You can imitate reference types on function parameter by using inout

var numbers = [1,2,3]

func foo(_ arr: inout Array<Int>)  {
    arr.removeLast()
}

foo(&numbers)
print(numbers) // [1,2]

Notice the &(ampersand) which is an explicit recognition that you're aware it is being used as inout.

Under the hood, the In-Out parameter doesn't use reference types.

This behavior is known as copy-in copy-out or call by value result. For example, when a computed property or a property with observers is passed as an in-out parameter, its getter is called as part of the function call and its setter is called as part of the function return. - Swift Docs

Conclusion

You now understand that:

Swift 'primitive-like' variables are made with a struct
Value types will copy the value if assigned to a variable or passed into a function
Reference types will share a single instance if assigned to a variable or passed into a function
Mutating value types won't affect the other copy, on the other hand, mutating reference types will affect the single instance
Function parameters follows value types, but can imitate reference types by using the in-out parameter

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Like this post? Subscribe to my newsletter to get notified every time a new post is out!

12 Features to Maximize Efficiency on Next.js & Tailwind CSS Projects

Theodorus Clarence — Sun, 09 Jan 2022 08:19:31 +0000

Introduction

I made the ts-nextjs-tailwind-starter after I got tired of setting up a new project and have to initialize Tailwind CSS every single time. After some months, this starter has grown and is filled with a lot of development automation and tools that help me when I'm developing.

This is something that I use every project init, features are carefully curated, and put into this repository.

theodorusclarence / ts-nextjs-tailwind-starter

🔋 Next.js + Tailwind CSS + TypeScript starter and boilerplate packed with useful development features

Features

According to my list, these are all the features that I incorporate on ts-nextjs-tailwind-starter:

⚡️ Next.js 12
⚛️ React 17
✨ TypeScript
💨 Tailwind CSS 3 — Configured with CSS Variables to extend the primary color
💎 Pre-built Components — Components that will automatically adapt with your brand color
🃏 Jest — Configured for unit testing
📈 Absolute Import and Path Alias — Import components using @/ prefix
📏 ESLint — Find and fix problems in your code, also will auto-sort your imports
💖 Prettier — Format your code and Tailwind CSS classes consistently
🐶 Husky & Lint Staged — Run scripts on your staged files before they are committed
🤖 Conventional Commit Lint — Make sure you & your teammates follow the conventional commit
⏰ Standard Version Changelog — Generate your changelog using yarn release
👷 Github Actions — Lint your code on PR
🚘 Automatic Branch and Issue Autolink — Branch will be automatically created on issue assigned, and auto-linked on PR
🔥 Snippets — A collection of useful snippets
👀 Default Open Graph — Awesome open graph generated using og.thcl.dev, fork it, and deploy!
🗺 Site Map — Automatically generate sitemap.xml
📦 Expansion Pack — Easily install common libraries, additional components, and configs

Quite a lot huh? I'm going to take an in-depth look at each feature and automation with this post.

Easy Initial Config

Don't you hate it when you use a starter, then you see some branding or default configs left out unchanged?

I prepared a unique word that you can find, with some guide of what to override. You can remove the comments after you override them, and leave them if you haven't. Treat them as a to-do comment.

Pre-built Components

I prepared a set of components that is neutral and can be used to help boost your speed in development. These are components that have a high chance of being used, not just getting deleted after you finished cloning the repository.

All animations are configured to be motion-safe.

Don't like the theme?

You can change it with CSS Variables. I prepared all Tailwind CSS colors converted to CSS Variables in the styles/colors.css file that you can copy and use.

See more details about components on the demo page

SEO Enhancement

Do you want your project to be indexed to search engines? Yeah, me too. I optimized the SEO by preparing a custom Seo component and adding next-sitemap.

If you want to use the default meta tag, just add <Seo /> on top of your page.

You can also customize it per page by overriding the title, description as props

<Seo title='Next.js Tailwind Starter' description='your description' />

or if you want to still keep the site title like %s | Next.js Tailwind Starter, you can use templateTitle props.

Minimal Dependencies

I tried to keep the dependencies small, not the devDeps tho, you'll see why after you see a bunch of automation I create. Here are the 3 dependencies (excluding Next.js and React deps)

clsx, a utility for constructing className strings conditionally.
react-icons, easily import popular icon packs in SVG format.
tailwind-merge, override tailwind CSS classes without using !important.

The tailwind-merge can be used by importing clsxm from @/lib/clsxm. All of the pre-built components are using clsxm to ease the use of the reusable components.

Here is a thread that I made about tailwind-merge:

// Detect dark theme var iframe = document.getElementById('tweet-1475685363003768836-141'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1475685363003768836&theme=dark" }

Absolute Import & Path Alias

import Header from '../../../components/Header';

// simplified to

import Header from '@/components/Header';

Reduce the complexity of importing components by using absolute import, and a nice path alias to differentiate your code and external libraries.

Prettier with Tailwind CSS Class Sorter

In this repository, I set it up so it will automatically sort class based on the custom config file. It even works with clsx or classnames! You don't need to ask your colleague to download another VS Code extension. All of it is bound to the repository.

ESLint

This repository is prepared with ESLint to reduce human errors during development. Don't worry there won't be any annoying styling lint because all of it is taken care of with Prettier. Some cool features such as:

Auto Import Sort & Unused Import Removal

Don't you hate it when you have to revise your code because your reviewer told you to reorder imports? If they haven't automated it, do yourself a favor by recommending this starter.

Husky & Lint Staged

There are 3 Husky hooks that will help you with the automation of:

pre-commit, run eslint check with 0 tolerance to warnings and errors and format the code using prettier
commit-msg, run commitlint to ensure the use of the Conventional Commit for commit messages
post-merge, running yarn every git pull or after merging to ensure all new packages are installed and ready to go

Oh right, you also don't have to wait that long because husky only the code that you stage (using lint-staged).

What about the type check, or if the staged code made the other fail? Don't burden your efficiency, just chuck it into Github Actions to run in the background.

Github Actions

I love automation and I put some useful workflows that you can use.

Type Check, Whole ESLint & Prettier

For the sake of efficiency, we don't run whole project checks on your local machine. That takes too long just to commit simple changes. We will run it on Github Actions instead, then you can continue working while waiting for it to complete.

Here are the complete lists that will be checked:

ESLint - will fail if there are any warnings and errors
Type Check - will fail on tsc error
Prettier Check - will fail if there are any formatting errors
Test - will fail if there are any test failures

Github also provides useful inline warnings in the Files Changed tab on the PR.

Auto Create Branch

We can automatically create a branch from the latest main branch after you assign an issue.

This will create a consistent branch name with the issue number in front of them, and some issue context.

p.s. You have to install the app for your organization/account/repository from the GitHub Marketplace for this to work

Auto Link PR to Issue

We automated the branch creation, the lint & the test process on the PR, what's next? Yep, linking PR to issue. That is super annoying and I always forgot to do it. We'll automate it using our consistent branch name.

It also provides a nice description of related issues, so your reviewer can check the issue first before reviewing.

Open Graph Generator

I also provided an open graph application that you can fork and deploy to vercel for free. It is automatically used with the SEO component and will generate a dynamic open graph based on the page title and description.

It defaults to my deployment, but please fork it and self-host. Because I might change the API without notice and could break your app's opengraph.

You can play around with the API on og.thcl.dev. You can even customize it with your own brand based on the repo!

Snippets

Snippets are crucial if you want to make a consistent convention across the application. I prepared some snippets that can help you code faster and more effectively.

See more detail on this file

Regions

You might notice the #region with green highlight comments. This is something that can be used with reg snippets. You can easily separate your logic into named regions, then fold them if they are insignificant.

The lesser noise the better. You can also use ⌘K + ⌘8 to fold all regions.

Snippets Wrap

This is something that I recently added because it is annoying to wrap a component with React Fragment or refactoring className with clsx. So I created a snippet pattern called Snippets Wrap that can help you with that.

Expansion Pack

I have to keep this starter minimal, but there are some libraries that I often use in every project. So I created a bash script to install, config, and add additional components to this starter.

Currently, there are some packs in the expansion-pack repository

React Hook Form + Form Input Components
Storybook
Cypress + workflow to run on Vercel preview on push
Toast with React Query / SWR
Dialog Manager with Zustand
NProgress

Here is a demo for the React Hook Form one

Hit the terminal then grab some coffee. You're back with complete components also a sandbox page to see how to implement the library.

theodorusclarence / expansion-pack

🔋 Useful stack expansion for ts-nextjs-tailwind-starter

For more demo, check out the repository readme

Star the repository

Liking the features? This repository basically grows with me, so the features will go through changes and improvement. If you got anything in mind, leave a comment below, or open a discussion.

theodorusclarence / ts-nextjs-tailwind-starter

🔋 Next.js + Tailwind CSS + TypeScript starter and boilerplate packed with useful development features

Finally, I would be thrilled if you give a star to the repository.

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Like this post? Subscribe to my newsletter to get notified every time a new post is out!

Step by step: How to setup Storybook with Next.js and Tailwind CSS

Theodorus Clarence — Fri, 24 Dec 2021 03:19:46 +0000

Introduction

Storybook is a great way to maintain and preview isolated components. I usually add it as a 'nice-to-have' feature. During set up, I found that the resource about setting up a storybook with Next.js and Tailwind CSS is scarce. There are a bunch of bugs, and finding the solution is like finding a needle in a haystack. Hopefully, this tutorial can help you set it up smoothly.

Version

This step-by-step tutorial is written with Storybook v6.4.9 & TypeScript, if you found the tutorial is not working after some minor update, please leave a comment below.

Initializing Storybook

This command will install the storybook to your Next.js repository, there will be a prompt asking if you want to additionally install an eslint plugin, I suggest you accept.

npx -y sb init --builder webpack5

Installing PostCSS Add-ons

Tailwind CSS needs PostCSS to work, so we need to integrate it with Storybook using one of their pre-built add-ons.

yarn add -D @storybook/addon-postcss

Adding Webpack as a resolution dependency

We need this to ensure the webpack is installed as a dependency, somehow this will cause a bug if we don’t install it

Append this to your package.json

// package.json

"resolutions": {
    "webpack": "^5"
}

Then install the webpack resolutions with

yarn

Replace `.storybook/main.js`

Here is the custom main.js config that you can use

// .storybook/main.js

const path = require('path');

module.exports = {
  stories: ['../src/**/*.stories.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'],
  staticDirs: ['../public'],
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    {
      /**
       * NOTE: fix Storybook issue with PostCSS@8
       * @see https://github.com/storybookjs/storybook/issues/12668#issuecomment-773958085
       */
      name: '@storybook/addon-postcss',
      options: {
        postcssLoaderOptions: {
          implementation: require('postcss'),
        },
      },
    },
  ],
  core: {
    builder: 'webpack5',
  },
  webpackFinal: (config) => {
    /**
     * Add support for alias-imports
     * @see https://github.com/storybookjs/storybook/issues/11989#issuecomment-715524391
     */
    config.resolve.alias = {
      ...config.resolve?.alias,
      '@': [path.resolve(__dirname, '../src/'), path.resolve(__dirname, '../')],
    };

    /**
     * Fixes font import with /
     * @see https://github.com/storybookjs/storybook/issues/12844#issuecomment-867544160
     */
    config.resolve.roots = [
      path.resolve(__dirname, '../public'),
      'node_modules',
    ];

    return config;
  },
};

I've provided some comments about the bug fixes with the link.

Confirm the stories and staticDirs if they match up with your folder structure. By specifying staticDirs we can use assets from public folders.

Replace `.storybook/preview.js`

// .storybook/preview.js

import '../src/styles/globals.css';
import * as NextImage from 'next/image';

const OriginalNextImage = NextImage.default;

Object.defineProperty(NextImage, 'default', {
  configurable: true,
  value: (props) => <OriginalNextImage {...props} unoptimized />,
});

export const parameters = {
  actions: { argTypesRegex: '^on[A-Z].*' },
  controls: {
    matchers: {
      color: /(background|color)$/i,
      date: /Date$/,
    },
  },
  previewTabs: {
    'storybook/docs/panel': { index: -1 },
  },
};

I like the docs panel to be the default so I added the previewTabs config. You can remove it if you want.

This file will load the Tailwind CSS from globals.css and mock NextImage to work with Storybook.

Running the storybook

Run yarn storybookto start up the dev server.

Then you can start adding some story, here is an example

Story example

// src/components/buttons/__stories__/Button.stories.tsx

import { ComponentMeta, ComponentStory } from '@storybook/react';
import * as React from 'react';
import { HiSearch } from 'react-icons/hi';

import Button from '@/components/buttons/Button';

export default {
  title: 'Components/Buttons/Button',
  component: Button,
  argTypes: {
    children: {
      control: { type: 'text' },
    },
  },
} as ComponentMeta<typeof Button>;

const Template: ComponentStory<typeof Button> = (args) => <Button {...args} />;

export const Default = Template.bind({});
Default.args = {
  children: 'Button',
  variants: 'primary',
};

export const WithIcon = Template.bind({});
WithIcon.args = {
  children: (
    <div className='flex gap-2 items-center'>
      <HiSearch />
      <span>Search</span>
    </div>
  ),
};

Type Definition

type ButtonProps = {
  /** Button children element */
  children: React.ReactNode;
  /** Show loading spinner and disable button */
  isLoading?: boolean;
  /** Button color variant */
  variants?: 'primary' | 'secondary';
  /** Disable the button and add not-allowed cursor */
  disabled?: boolean;
} & React.ComponentPropsWithoutRef<'button'>;

If you are using TypeScript, you can directly add JSDoc to the type definition, and it will automatically generate the props description 🤯

Screenshot

Awesome.

Deploying on Vercel

To deploy on Vercel, you need to create a separate deployment with your Next.js page, then add this custom configuration

Hate config? Use my starter & expansion

This is a battery-packed starter with installable expansion just by using a single command in the terminal.

Check out the ts-nextjs-tailwind-starter!

Storybook Expansion

I created this expansion to easily configure the project, this will do all of the above tutorials, suitable to be used with my starter, you probably can use it to an existing project. No promise ✌

curl -s https://raw.githubusercontent.com/theodorusclarence/expansion-pack/main/storybook/trigger.sh | bash -s

Expansion pack repository

Plop Generator

The expansion pack is also equipped with a plop generator to easily create a storybook file for your component

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Like this post? Subscribe to my newsletter to get notified every time a new post is out!

What is useState, and why dont we use normal let?

Theodorus Clarence — Mon, 29 Nov 2021 15:06:31 +0000

Introduction

Nowadays, we are still using the useState hook to set a variable in a React component. The useState, is introduced as 'hooks', is written like this

const [count, setCount] = React.useState<number>(0);

But what really is this? Why do we have to use this hook just to set a variable that holds a number and get incremented?

Why don't we just use something like this?

let count = 0;

count++;

Well, it always works in our first counter app with Vanilla JavaScript. Why don't we use it on React then?

TLDR;

React does a re-render by calling the component function, and with every function calls, your variable will get reset every single time.

Stepping Back

Before we jump into the React Core Concept, let's step back to Vanilla JavaScript. For this demo, we are going to build a simple counter app.

let count = 0;

function add() {
  count++;
  document.getElementById('count').textContent = count;
}

Simple right? When the button—that has add() as a click listener—triggers, we add the count and update the text by accessing the documents.

If we look closely, we can see that it is doing 3 actions. Let's break it down into its own functions.

// Declare
let count = 0;

function mutate() {
  count++;
}

function render() {
  document.getElementById("count").textContent = count;
}

// event listener pseudocode
when button is clicked:
  mutate()
  render()

And we get something like this:

Video Alt:

On the left side, it is shown that the button element has an onclick attribute that run mutate() and render().
Whenever a user clicks the button, the number will increase by one

3 Actions

Before we continue, we have these 3 actions that we break down earlier:

Declare → initialize variable using let
Mutate → change the count variable
Render → update changes to the screen

Let's split the button into its own functions, so you can see it clearly.

<h1>Counter</h1>
<p id="count">0</p>
<button onclick="mutate()">Mutate</button>
<button onclick="render()">Render</button>

<script>
  let count = 0;

  function mutate() {
    count++;
    logTime();
    console.log('clicking, count: ', count);
  }

  function render() {
    document.getElementById('count').textContent = count;
  }
</script>

Video Alt:

When the mutate button is clicked, the console shows the count is increasing. However, the number on the screen doesn't change at all.
After the render button is clicked, the number on the screen changes to the last count value.

Looking at React

By bluntly translating the JavaScript code, this is what we have now.

function Component() {
  let count = 0;

  function mutate() {
    count = count + 1;
    console.log(count);
  }

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={mutate}>Mutate</button>
    </div>
  );
}

Do you see something odd?

found it?

Yes, there is no render function.

We can, of course, use the same render function by accessing document, but it's not a good practice to access them manually on React, our purpose of using React is not to manage them manually.

Render Function

What is the equivalent of render function in React then?

It is actually the function Component() itself.

Whenever we want to update the screen, React are calling Component() function to do that.

By calling the function, the count is declared again, the mutate function is also re-declared, and at last, will return a new JSX.

Here is the demo:

Video Description:

We can see that there are 2 console log in the line 13 and 15
When the page is reloaded, the console logs are running. (this is normal behavior as the initial render)
Every time the Re-render button is clicked, the logs are called. This proves that the Component() is called every render.

What triggers render function?

If we run the code with let on React, there will be no changes. That's because the render function doesn't get called.

React will trigger render function:

When the useState value changes (using setState)
When the parent component re-renders
When the props that are being passed changes

The second and the third are basically triggered because of setState too but in the parent element.

At this point, we know that every time the useState value changes, it will call the render function which is the Component function itself.

Simulating the render function

Before we convert the count variable to state, I want to demonstrate by creating a render function simulation, which uses setToggle. We can trigger re-render with render now.

function Component() {
  //#region  //*=========== Render Fn Simulation ===========
  const [toggle, setToggle] = React.useState<boolean>(false);
  function render() {
    setToggle((t) => !t);
  }
  //#endregion  //*======== Render Fn Simulation ===========

  let count = 0;

  const mutate = () => {
    count = count + 1;
    console.log(`${getTime()}| count: ${count}`);
  };

  return (
    <div>
      <h1>{count}</h1>
      <Button onClick={mutate}>Mutate</Button>
      <Button onClick={render}>Render</Button>
    </div>
  );
}

Let's see it in action

Video Alt:

Mutate button is clicked, and the count is incremented to 4
Render button is clicked, but the number on screen doesn't change, while the console log is 4.
Render function is clicked again, the number on screen is still 0, while the console log change to 0
After mutate is clicked, it increments, but not from 4, it increments starting from 0 again.

🤯 Why is it not working?

This is actually because we are re-declaring the count variable.

function Component() {
  //#region  //*=========== Render Fn Simulation ===========
  const [toggle, setToggle] = React.useState<boolean>(false);
  function render() {
    setToggle((t) => !t);
    console.log(`${getTime()} | Render function called at count: ${count}`);
  }
  //#endregion  //*======== Render Fn Simulation ===========

  let count = 0;

  const mutate = () => {
    count = count + 1;
    console.log(`${getTime()}| count: ${count}`);
  };

  return (
    <div>
      <h1>{count}</h1>
      <Button onClick={mutate}>Mutate</Button>
      <Button onClick={render}>Render</Button>
    </div>
  );
}

Every time react calls the Component function, we are re-declaring the count to be 0. The render function still works, and react updated the screen, but it updated to the re-declared count which is still 0.

Now that is why we can't use a normal variable in a React component.

Declaring Outside of Component

You might also ask:

Why don't we move the declaration outside the Component function?

Well, it makes sense, by moving the declaration we are avoiding the count being re-declared to 0. Let's try it to be sure.

let count = 0;

function Component() {
  //#region  //*=========== Render Fn Simulation ===========
  const [toggle, setToggle] = React.useState<boolean>(false);
  function render() {
    setToggle((t) => !t);
    console.log(`${getTime()} | Render function called at count: ${count}`);
  }
  //#endregion  //*======== Render Fn Simulation ===========

  const mutate = () => {
    count = count + 1;
    console.log(`${getTime()}| count: ${count}`);
  };

  return (
    <div>
      <h1>{count}</h1>
      <Button onClick={mutate}>Mutate</Button>
      <Button onClick={render}>Render</Button>
    </div>
  );
}

Video Alt:

Mutate button is clicked 3 times, and the count is incremented to 3
Render button is clicked, and the number on the screen updated to 3
When the mutate button is clicked again, the increment continues from 3 to 5
When the render button is clicked again, it is updated to the correct count.

IT WORKS! or is it?

It did just work, that was not a fluke. But there is something you need to see.

Video Alt:

Current count is = 5, it is proven by clicking the render button, it's still 5.
Then, we move to another page
Back to the counter page, but the count is still 5
Clicking the mutate button will increment from 5

Yes, the variable doesn't get cleared.

This is not great behavior, because we have to manually clean it or it will mess up our app.

Now that is why we can't use a normal variable outside a React component.

Using useState

This is the code if we are using useState

function Component() {
  const [count, setCount] = React.useState<number>(0);

  const mutateAndRender = () => {
    setCount((count) => count + 1);
    console.log(`${getTime()} | count: ${count}`);
  };

  return (
    <div>
      <h1>{count}</h1>
      <div className='mt-4 space-x-2'>
        <Button onClick={mutateAndRender} variant='light'>
          Add
        </Button>
      </div>
    </div>
  );
}

And this is the demo

Video Alt:

You may notice that the console.log count is late by 1, ignore it for now.

Add button is clicked, then the count is added, and simultaneously updated on screen
When moving to another page and back, the count is reset back to 0.

So in recap, useState does 4 things:

Declaration, by declaring using this syntax

   const [count, setCount] = React.useState<number>(0);

Mutate and Render, changing the value and automatically render the changes using setCount
Persist the data in each re-render → when the render function is called, useState won't re-declare the count value.
Reset the value when we move to another page, or usually called: when the component unmounts.

Why the count is late

const mutateAndRender = () => {
  setCount((count) => count + 1);
  console.log(`${getTime()} | count: ${count}`);
};

This is because the setCount function is asynchronous.

After we call the function, it needs time to update the count value. So when we call the console.log immediately, it will still return the old value.

You can move the console.log outside of the function so it will run on re-render (Component())

function Component() {
    ...

    const mutateAndRender = () => {
      setCount((count) => count + 1);
    };

    console.log(`${getTime()} | count: ${count}`);

  return ...
}

3 Actions Diagram

Here is the updated diagram, now you know what useState and setState do.

Recap

Great job, you have finished the first React Core Concept Series. I'll definitely continue this series as there are still many hooks to cover. Please hold on to the mental model that I put in this blog post, as I'm going to reference it again soon on the next post.

With this post, we learned that

We can't use normal let because React calls the Component function itself to do the re-rendering.
Re-rendering will cause all of the code in the Component function to be run all over again including the variable and function declaration, as well the console logs and function calls.
Using the useState hook will help us update the variable, and the number on the screen while still persisting the data between re-renders.

See you in the next blog post. Subscribe to my newsletter if you don't want to miss it.

Quiz

There is actually a pop quiz on my website, I suggest you take it to test your knowledge.

Here is the link to the quiz

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

React Loading State Pattern using Toast & SWR

Theodorus Clarence — Sat, 13 Nov 2021 12:28:49 +0000

Introduction

Managing the react loading state can be a bit annoying, we need to set it to isLoading before fetching, then set it back to false after it is done. Then we also need to set it up to the button so we can show the loading state, or give some text as an indicator.

Here is what it looks like with the common loading pattern:

const [pokemon, setPokemon] = React.useState<Array<Pokemon>>();
const [isLoading, setIsLoading] = React.useState<boolean>(false);

const getData = () => {
  setIsLoading(true);

  axios
    .get<PokemonList>('https://pokeapi.co/api/v2/pokemon?limit=20')
    .then((res) => {
      setPokemon(res.data.results);
    })
    .finally(() => setIsLoading(false));
};

return <button disabled={isLoading}>{isLoading ? 'loading' : 'fetch'}</button>;

it is annoying to do, and we didn't even cover error state yet.

What should we manage in a loading process?

When we are fetching data, we need to do some things so the waiting experience can be more bearable. Here are some things that we can do:

Loading indicator

Users need to know when their application is in a loading state. This is important so they are not blankly waiting, and get the mindset that they should wait for a bit.

Loading indicator can be a spinner, normal text, some animations, or toast.

Success indicator

We need to tell the user if the loading has succeeded, so they can continue with their work.

Error indicator

When the data fetching goes wrong, we have to let the user know about it.

Blocking action

A common example is when we are submitting a form, we don't want the user to submit twice. We can do that by disabling the button when there is a loading state going on.

Another example is blocking the modal close button when loading, so the user doesn't accidentally close it.

The easy way

I found that this pattern is the most hassle-free, and we can use custom hooks to grab the loading state.

Here is what we are going to build:

Video Description:

getData button is clicked, then there is a loading toast showing.
When it is loading, the button is disabled and showing a loading spinner
After 2 seconds, the loading toast turns into an error toast
getData button is clicked again, then there is a loading toast showing
After 2 seconds, the loading toast turns into a success toast, then all the data loads correctly

ps: the wait cursor is kind of weird in the recording.

With this pattern, we get all 4 things covered, easily.

We get the loading state using toast
We can show error indicator and show the error message from the API
We can show success indicator
Last, all buttons are disabled.

We are using React Hot Toast for the loading, success, and error indicator. All of it are managed only using 1 wrapper function like this:

toast.promise(
  axios
    .get<PokemonList>('https://pokeapi.co/api/v2/pokemon?limit=20')
    .then((res) => {
      setPokemon(res.data.results);
    }),
  {
    loading: 'Loading...',
    success: 'Data fetched successfully',
    error: (err: any) =>
      err?.response?.data?.msg ?? 'Something is wrong, please try again',
  }
);

Configuration

First, we need to install the react-hot-toast

yarn add react-hot-toast

I'm using Next.js for the demo, but the config for CRA is basically the same. Add this to the _app.tsx

import { AppProps } from 'next/app';

import '@/styles/globals.css';

import DismissableToast from '@/components/DismissableToast';

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <>
      <DismissableToast />
      <Component {...pageProps} />
    </>
  );
}

export default MyApp;

I added a dismiss button because it doesn't have it by default, you can grab the DismissableToast code from my library.

Usage

Let's say we want to fetch data on mount from an external API using Axios.

We just need to wrap the axios call with the toast function.

React.useEffect(() => {
  toast.promise(
    axios
      .get<PokemonList>('https://pokeapi.co/api/v2/pokemon?limit=20')
      .then((res) => {
        setPokemon(res.data.results);
      }),
    {
      loading: 'Loading...',
      success: 'Data fetched successfully',
      error: (err: any) =>
        err?.response?.data?.msg ?? 'Something is wrong, please try again',
    }
  );
}, []);

That's it! The toast will show status when loading, and when it is a success or an error.

Further Reusablity

You can compose it even more by declaring the defaultToastMessage, then overriding it if you need to.

export const defaultToastMessage = {
  loading: 'Loading...',
  success: 'Data fetched successfully',
  // you can type this with axios error
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  error: (err: any) =>
    err?.response?.data?.msg ?? 'Something is wrong, please try again',
};

toast.promise(axios, {
  ...defaultToastMessage,
  loading: 'Override loading',
});

Accessing loading state

Now, what if we want to get that loading state to disable a button?

We can do that with toast API that I wrapped in a custom hook.

import { useToasterStore } from 'react-hot-toast';

/**
 * Hook to get information whether something is loading
 * @returns true if there is a loading toast
 * @example const isLoading = useLoadingToast();
 */
export default function useLoadingToast(): boolean {
  const { toasts } = useToasterStore();
  const isLoading = toasts.some((toast) => toast.type === 'loading');
  return isLoading;
}

And we can use it just like this

const isLoading = useLoadingToast();

<button disabled={isLoading}></button>;

With the isLoading state, the rest is all your creativity, you can show some skeleton, change the loading text, give loading spinners, anything you like.

Gotcha: 2 Axios Calls

If you got 2 axios calls, you can chain the next axios call, and add another then to get the value.

toast.promise(
  axios
    .post('/user/login', data)
    .then((res) => {
      const { jwt: token } = res.data.data;
      tempToken = token;
      localStorage.setItem('token', token);

      // chaining axios in 1 promise
      return axios.get('/user/get-user-info');
    })
    .then((user) => {
      const role = user.data.data.user_role;
      dispatch('LOGIN', { ...user.data.data, token: tempToken });

      history.replace('/');
    }),
  {
    ...defaultToastMessage,
  }
);

SWR Integration

Using SWR to fetch data is even more awesome because we only need to show the loading state on the first fetch. Here is the demo:

Video Description:

First time visited, a loading toast is shown then turns into success toast.
When visited for the second time, there is no loading toast and the data is prefilled with cache.

This is the syntax of SWR:

const { data, error } = useSWR<PokemonList>(
  'https://pokeapi.co/api/v2/pokemon?limit=20'
);

Hmm, this is not a promise, how do we use the toast then?

We can use another custom hook ✨

I made this hook so we can wrap the useSWR just like the toast.promise function.

useWithToast for SWR

import * as React from 'react';
import toast from 'react-hot-toast';
import { SWRResponse } from 'swr';

import { defaultToastMessage } from '@/lib/helper';

import useLoadingToast from '@/hooks/useLoadingToast';

type OptionType = {
  runCondition?: boolean;
  loading?: string;
  success?: string;
  error?: string;
};

export default function useWithToast<T, E>(
  swr: SWRResponse<T, E>,
  { runCondition = true, ...customMessages }: OptionType = {}
) {
  const { data, error } = swr;

  const toastStatus = React.useRef<string>(data ? 'done' : 'idle');

  const toastMessage = {
    ...defaultToastMessage,
    ...customMessages,
  };

  React.useEffect(() => {
    if (!runCondition) return;

    // if toastStatus is done,
    // then it is not the first render or the data is already cached
    if (toastStatus.current === 'done') return;

    if (error) {
      toast.error(toastMessage.error, { id: toastStatus.current });
      toastStatus.current = 'done';
    } else if (data) {
      toast.success(toastMessage.success, { id: toastStatus.current });
      toastStatus.current = 'done';
    } else {
      toastStatus.current = toast.loading(toastMessage.loading);
    }

    return () => {
      toast.dismiss(toastStatus.current);
    };
  }, [
    data,
    error,
    runCondition,
    toastMessage.error,
    toastMessage.loading,
    toastMessage.success,
  ]);

  return { ...swr, isLoading: useLoadingToast() };
}

In addition, I added the isLoading to the return so we don't need to call the useLoadingToast hooks anymore

Usage

const { data: pokemonData, isLoading } = useWithToast(
  useSWR<PokemonList>('https://pokeapi.co/api/v2/pokemon?limit=20')
);

Awesome, it's looking good and clean.

You can still override the toast messages just like this

const { data: pokemonData, isLoading } = useWithToast(
  useSWR<PokemonList>('https://pokeapi.co/api/v2/pokemon?limit=20'),
  {
    loading: 'Override Loading',
  }
);

Conclusion

I hope this can add to your pattern collection.

You can look at the demo source code on github, but keep in mind there is additional promise to delay the loading time.

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Should we use CSR, SSR, SSG, or ISR on Next.js?

Theodorus Clarence — Sun, 24 Oct 2021 14:49:06 +0000

Introduction

On my last blog, you have explored the technical side of how does it work underneath, now what you will need is how to choose between them. I'll give you 4 metrics and some use cases to help you decide.

These metrics will generally work for most of the cases but there might be some cases that are not fit with this metric.

Prerequisites

This post will not cover the technical difference between Client-Side Rendering, Server-Side Rendering, Static Site Generator, and Incremental Static Regeneration.

You are encouraged to read my blog about Understanding Next.js Data Fetching (CSR, SSR, SSG, ISR) first.

Something to note

Please do note that when we are talking about a website, you can use more than 1 fetch method. Use the necessary fetch method for each page.

Review

Let's review the last blog to remember what are the characteristics of each.

Client-Side Rendering (useEffect) → the data is fetched after every single render
Server-Side Rendering → the data is fetched before every single render
Static Site Generator → the data is fetched once at build time
Incremental Static Regeneration → the data is fetched once on build time and will be fetched again after a certain cooldown and served on the second visit.

Keep an eye on the frequency of each fetch method.

Metrics

Usually, when I'm deciding what fetch method I should use, I consider these 4 metrics.

Metric 1: 🔄 Data Integrity

Data integrity is how fresh do you want the data to be.

High

High integrity means that we want fresh data—the most updated one—every single render. This is usually crucial for pages that are interactive and contain some critical value that can't be stale.

Simply put:

We need the most updated data, every. single. time.

Sites that benefit high data integrity:

Products page that contains price → imagine you have a product page, and the price shown is not the most updated one. You might lose some dough.
The comment section on Twitter → we want to see the most recent comment
Social media → we want to see the most up-to-date content obviously.

Medium

Medium integrity means that we want to serve fresh data, but it is not much of a problem if some users get stale data.

Simply put:

We should get fresh data, but it's okay if some still see the stale one.

Sites that benefit medium data integrity:

Blog post with CMS → you can tolerate it when someone gets the stale page with minor typos
Profile page → it is rarely updated and it is not that critical

Please note that only you can decide what is critical. If you are mainly making a website to showcase your profile and portfolio with a high update rate, then it can be considered critical.

Low to none

Pages that fall into this category usually won't change or rarely change.

Simply put:

We don't really care, just fetch and show it.

Sites that benefit low to none data integrity:

About page
A page with fixed data that won't change → ex: a pokemon stat page (we will use this as an example later)

Table Result

As we can see on the illustration:

High: CSR and SSR, as it fetches on every render
Medium: ISR, we still can get the fresh data, but some user will still get the stale one
Low to none: SSG, it is only fetched on build time

Metric 2: 🔍 SEO

SEO (Search Engine Optimization) is going to be useful when we want our content to be easily found on google and bringing in that good organic visitors.

I only have 2 categories for this, which are SEO Friendly and Not SEO Friendly.

SEO Friendly

This category is expected when we are pre-rendering the content on the website, the general difference is when we are doing pre-render, we can see the content on the page source. This type of rendering will help search engines index our page and might put us up on the SEO ranking.

SSR, SSG, ISG categorizes as SEO Friendly because the HTML is prefilled with the content without having to fetch it on the client-side.

Sites that can benefit SEO

Shopping website → it will be great if our products show up on search engine
Quora-type website → site that provides an answer of course relies on SEO. You probably not going to search something directly from quora or stack overflow, but you start on google.
Social media → contents need to be able to be searched on the internet

Not SEO Friendly

It is definitely not bad. Although we don't get any content on the page source, it doesn't mean that the search engine crawler can't index your page. The search engine can still index it, but it is not as friendly as the pre-rendered pages.

CSR is categorized as Not SEO Friendly because we do not get any content until after the page renders.

Sites that don't really need SEO

Authentication Gated Apps → things like a dashboard, premium content, or paid courses.
Registration page

Table Result

SEO Friendly: SSR, SSG, and ISR all have very great SEO because they pre-render the fetched content
Not SEO Friendly: CSR is not that good because we only get the data after render

Metric 3: ⏩ Performance

Performance is whether it is loading when we visit the page or not. It should be very easy to differentiate now if you have read the first blog.

Please note that performance in this metrics strictly means to the load time before First Contentful Paint, not to be generalized to the whole application performance.

Instant

Instantly loads because the fetching does not happen when we request.

Loads before/after render

There will be a slight loading on before or after renders.

Table Result

Well, we obviously want better performance, so this is not something that you choose as the main metrics, but rather to consider.

Instant: SSG & ISR
Loads before/after render: CSR & SSR

Metric 4: ⏰ Build Time

Build time is the amount of time it takes to build and deploy the website.

This metric is to be considered when we are generating a bunch of pages with parameters, for example, product/[name] or pokemon/[name]

Fast (only one page)

When we are using CSR and SSR, we only build 1 page because the data won't be fetched at build time.

For example, if we are visiting /pokemon/bulbasaur then we will take that parameter and use it to fetch it before or after render.

Slow (every single page)

When we are using SSG and ISR, we are fetching it on build time and creating a page out of the response. So if we have 1000 products, it will take quite some time.

Build Time Example

Alt:

/ssr/poke/[name] only have 1 page even though it is serving 100 pokemon
/ssg/poke/[name] have all of the pokemon names built into a page.

This is something that you'll need to consider if you have thousands of products, or you want to show all of the pokemon out there. We can't wait for them to finish building, using CSR or SSR should be the right answer.

Cheatsheet

Examples

CSR

https://next-usecase.thcl.dev/csr

Video:

there is a loading indicator when visited
the data (repository detail) that is served is the most up to date

It's ideal for a dashboard and authentication-gated website. We need the latest data, and we don't really care about SEO.

SSG

I'll give SSG example first so we can compare it with SSR

https://next-usecase.thcl.dev/ssg

Video:

Data fetched on build time at 13:58:38, when the current time is already 2 hours late—16:28:30
It is instant and has no loading
There are 10 pokemon data to choose

This one is great for pokemon data because the data probably won't change for quite some time. And maybe you have a question:

Why not just store it as JSON and create every page?

We usually use SSG for convenience, adding hundreds of pages is quite repetitive and we can maintain it better if we use getStaticProps

SSR

You probably notice and have it in mind that apps that have high data integrity and have a good SEO should use SSR, for example, products page, comment section. The obvious example should be Quora, Reddit, Facebook, etc.

But it is not always the case, here is the same pokemon app using SSR:

https://next-usecase.thcl.dev/ssr

Video:

Clicking the page takes a second or two before the page shows up
Fetch time is the current time (meaning the data is fresh)
There are considerably a lot of pokemon to choose

This use case fits because there are about 900 pokemon, and if we build all of them using SSG, it is going to take a while. That is why you should also consider the build time metric.

Well actually 900 is not that much, but imagine Amazon or eBay.

ISR

ISR is quite fun and might be the common grounds between the 4 fetch methods, but we need to emphasize the data integrity. ISR can still give stale data, so it will be dangerous if you are using it on a critical process.

For this example, I suggest you visit it yourself

What to do:

Try to star the repo that is linked in the demo page (disclosure: you are going to star my personal repository, kindly keep it starred if you like this post 😉)
Wait for about 5-10 seconds
Refresh the page twice (remember how ISR works)

Demo page: https://next-usecase.thcl.dev/isr

You done? Cool!

We can see that the data will still update, but we can have medium data integrity and still have a good performance.

This is very useful if you are creating a blog with CMS, and it will be updated without having to rebuild the whole site.

Additional Resource

There is a pattern that uses ISR and SWR library, it follows optimistic UI by mutating the value, and regenerating on the background.

I'm not going to cover this topic, but Joe Bell has a really great article about it.

Conclusion

Save the 4 metrics cheatsheet, and try to consider each of them when you want to choose.

Remember you can use multiple fetch methods on different pages. You can use CSR on the dashboard, and also use SSR on the product page. Use the best one.

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Mindfully Commit with a Descriptive Message

Theodorus Clarence — Sat, 18 Sep 2021 11:41:23 +0000

Introduction

Do you do this?

Stop. Even if you are working alone and nobody reads your commit, you're eventually going to forget your 3-month-old project.

"Was the X feature added?", "Did I fixed the hamburger menu bug?".

You can't really know what feature you are adding, or what bug you are fixing not until you jump into the code to check what changed. Imagine you work as a team, and you have to review 10 commits that are not descriptive, so you need to read the code and the logic on that PR.

Step 1: Descriptive Commit Message

The guideline of a descriptive commit message is you should at least know what were you working with just by reading the commit message. The convention is usually using imperative sentences, and present tense.

For example:

change aspect ratio for company profile video
add hamburger menu for mobile
remove unused imports
fix hamburger menu not opening on mobile
add test for helper functions
refactor remove todo logic
add documentation on hamburger menu
install react-icons

Even without looking at the code changes, you can generally know what is going on.

By spending 10 seconds to decide what descriptive commit message that we should use, we can save up minutes of looking up code changes in the future.

Step 2: Grouping

We've learned that using a descriptive commit message helps a lot during code review or revisiting old projects.

At the first step, we can infer what is going on by looking at the commit message. But, we have to read the full sentence to know if it was a feature that is added or removed, a bug that was fixed, or a package that was installed. Isn't it nicer if we can recognize the function of the commit just by the first word? Also, there are some people that like to use emojis to differentiate. You can if you like, but I'm trying to minimize mental mapping.

There are a lot of conventions out there, and I usually use Conventional Commit. I will spare you the details—should we use capital or not, should we use past tense or present tense, should we add a full stop—on the later step. But this grouping step roughly follows Conventional Commit

Let's say that we have these categories—only a small example, you can add more categories if you need to:

feat, for addition or removal of a feature.
fix, for squashing bugs
chore, for installing npm packages
test, for adding test suites
refactor, for refactoring code flow but not changing the feature itself
style, for styling code structure like spacing, reorder or remove unused imports, etc.

Our last commit can improve into this:

feat change aspect ratio for company profile video
feat add hamburger menu for mobile
style remove unused imports
fix hamburger menu not opening on mobile
test add test for helper functions
refactor remove todo logic
docs add documentation on hamburger menu
chore install react-icons

In this step, we can be more effective when differentiating commit. We can skim commits and find what category we are looking for.

Step 3: Generating Changelog

Let's say you are creating an NPM package, and you need to generate a Changelog for your users so they are aware of the changes. For instance, you can look up your git log, and copy all commit message that is in feat and fix category. This 2 category is the most used when creating a changelog because your user doesn't really need to know that you remove unused import, or adding a semicolon to code because you forgot.

ps: when doing a normal project, you can add more categories to the changelog if you want.

Handpicking those is grunt work, and nobody wants to do it if you have a bunch of commits. That is why we can use standard-version to generate the report.

We can easily run a command, and it will automatically bump the version, generate changelog, commit, and add a tag to our project.

Here is the report that is generated only using our commit, we can also specify what categories we want to include.

But, there is a catch when we are using an auto-generate package like standard-version. We need to follow certain rules so the standard-version program is not confused. Let's proceed to step 4.

Step 4: Conventional Commits

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages.

Do read up the guide on their website.

This set of rules will help us create a good commit message that we can easily read, and can be auto-generated into a changelog. I usually put up this markdown in the readme file, so others can follow it too. Feel free to read up my summary and copy it to your projects.

Still, read the guide on their website, it is more comprehensive there.

Commit Message Convention Readme

## Commit Message Convention

This website follows [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)

Commit message will be checked using [husky and commit lint](https://theodorusclarence.com/library/husky-commitlint-prettier), you can't commit if not using the proper convention below.

### Format

@@@text
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
@@@

*change the @ to \`, devto won't allow nested backticks for some reason

Example: `feat(pre-event): add speakers section`

### 1. Type

Available types are:

- feat → Changes about addition or removal of a feature. Ex: `feat: add table on landing page`, `feat: remove table from landing page`
- fix → Bug fixing, followed by the issue (not what you do to fix that bug). Ex: `fix: illustration overflows in mobile view`
- chore → Installing new dependencies, or bumping deps
- docs → Update documentation (README.md)
- style → Updating style, and not changing any logic in the code (reorder imports, fix whitespace, remove comments)
- refactor → Changes in code, same output, but different approach
- ci → Update github workflows, husky
- test → Update testing suite, cypress files
- revert → when reverting commits
- perf → Fixing something regarding performance (deriving state, using memo, callback)
- vercel → Blank commit to trigger vercel deployment. Ex: `vercel: trigger deployment`

For breaking change, add (!) after the types. Ex: `feat!: drop support for internet explorer`

### 2. Optional Scope

Labels per page Ex: `feat(pre-event): add date label`

\*If there is no scope needed, you don't need to write it

### 3. Description

Description must fully explain what is being done.

### Important Rules

**If there are multiple changes, then commit one by one**

- After colon, there is a single space. Ex: `feat: add something`
- When using `fix` type, state the issue. Ex: `fix: file size limiter not working`
- Use imperative, and present tense: "change" not "changed" or "changes"
- Don't use capitals in front of the sentence
- Don't add full stop (.) at the end of the sentence

Using that set of rules will guarantee a working changelog. But still, whether the commit message is going to be meaningful, it is on you.

Step 5: Add Commitlint

If you are working with some new developers in your team, they might not fully know this convention. While you can give this blog to them 😉, it is a great practice to add a linter for your project, so no one can mess up the commit message.

This will enforce the use of conventional commit for your commit message.

Check out this post to add Commitlint using Husky

Summary

We learn that we should use a more descriptive commit message, add some category to it, use Conventional Commits rules as a guide so we can generate changelog, and add Commitlint so we can't mess it up.

How to show Now Playing in Spotify with Next.js

Theodorus Clarence — Wed, 15 Sep 2021 09:49:58 +0000

Introduction

On my personal website, I use Spotify API to show what song is currently playing. Now, I will try to explain on how do I do that.

Next.js has a built-in API in a single application, so choosing Next.js is a perfect choice so we don't expose our API keys.

Website Demo

1. Create an Application on Spotify Developer

Go to Spotify Developer Website.
Click Create An App
Fill in App Name, App description, then Create

Next, you will be provided with Client ID and Client Secret (Don't give this secret to anyone)

Open edit settings, then fill out http://localhost:3000 on RedirectURIs

The first step is done! Now, you need to do authentication to get access & refresh token

2. Authenticate Your Account

To do authentication, we need to prepare CLIENT_ID and put it into this link below:

https://accounts.spotify.com/authorize?client_id=CLIENT_ID_HERE&response_type=code&redirect_uri=http
%3A%2F%2Flocalhost:3000&scope=user-read-currently-playing

example:

https://accounts.spotify.com/authorize?client_id=eaccb97f6d0e405897adf1dd80b95c01&response_type=code&redirect_uri=http
%3A%2F%2Flocalhost:3000&scope=user-read-currently-playing

Open that link in a browser, then you will get redirected into a uri, copy the website link

Example of the redirect link:

http://localhost:3000/?code=AQBeA9SD7QbA9hUfv_TfmatYxT51CY87msMnOZmMbhf7ZaxfbvG7oKEsATOJBxDyFap0Aq6uftY0v4Hq1QSy3MgQBfAHhmrifty-62rfDRlFnd0AzXRBOMpoOSA6SNw_uTPp7AixAE5zosgiIIf7efhzf1QOJfLh1HUYi248z8jk1x2jjKG2YLvMyJuP0rjB5tP5UHjoFGBvKbULpchkF6yiJHnS

code that you have is the one after (=). Don't forget to write it down.

Next we need to get authorization client that is already encrypted with base64, use this website to encrypt with the format of client_id:client_secret

For example:

Next, write down the encrypted base64

After that, open up terminal/cmd, and run this command, don't forget to change the base64 and the code to yours.

curl -H "Authorization: Basic CHANGE_BASE64_HERE"
-d grant_type=authorization_code -d code=CHANGE_CODE_HERE -d redirect_uri=http%3A
%2F%2Flocalhost:3000 https://accounts.spotify.com/api/token

*make sure the command is in one line

Example:

curl -H "Authorization: Basic ZWFjY2I5N2Y2ZDBlNDA1ODk3YWRmMWRkODBiOTVjMDE6YTQxOTVjMmQwYTQyNDM2MDllNjk3ZTYwMmU3MGI3NjI=" -d grant_type=authorization_code -d code=AQBeA9SD7QbA9hUfv_TfmatYxT51CY87msMnOZmMbhf7ZaxfbvG7oKEsATOJBxDyFap0Aq6uftY0v4Hq1QSy3MgQBfAHhmrifty-62rfDRlFnd0AzXRBOMpoOSA6SNw_uTPp7AixAE5zosgiIIf7efhzf1QOJfLh1HUYi248z8jk1x2jjKG2YLvMyJuP0rjB5tP5UHjoFGBvKbULpchkF6yiJHnS -d redirect_uri=http%3A%2F%2Flocalhost:3000 https://accounts.spotify.com/api/token

You will get a JSON like this:

{
  "access_token": "BQDKxO7h1I1wA3esGK9zCFWn97XORJEPjwAHAEIxCnDXcmy9GbEuPacquwWvpiM4d33gJVHVOP9KUxY8AXkpXc-_zRFZBfneHM2vEeV1Fbfr-0Mw94oimlNf77dRiyxPpm4IUVNLloUWgYcfkAO0",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "AQAtxXvnzRTt4c2-2_Av2WyJQKWxUW_hMVN6QNiqv2i8A2ZElVarmvdhqyc8Pf-Z5n827FTFxTpHq5E3kOsrlRWM3TuJWxjVQsW0icR0zo3BXRFLt2FB2Qfj-pFaZwY-qc8",
  "scope": "user-read-currently-playing"
}

Example on the terminal:

what we need to write down is the refresh_token. That token will last infinitely

Now you can do the request with Next.js or another backend application

3. Creating API routes in Next.js

If you need a reference to create the app, you can check my repository. Don't forget to star it!

You can also use my nextjs-tailwind-starter by using:

npx create-next-app -e https://github.com/theodorusclarence/nextjs-tailwind-starter project-name

or, if you prefer typescript, there is also a starter template

After all app is installed, add querystring dependency

yarn add querystring

or

npm i querystring

Next, make an api route in /pages/api/spotify.js

// /pages/api/spotify.js
import querystring from 'querystring';

const {
  SPOTIFY_CLIENT_ID: client_id,
  SPOTIFY_CLIENT_SECRET: client_secret,
  SPOTIFY_REFRESH_TOKEN: refresh_token,
} = process.env;

const basic = Buffer.from(`${client_id}:${client_secret}`).toString('base64');
const NOW_PLAYING_ENDPOINT = `https://api.spotify.com/v1/me/player/currently-playing`;
const TOKEN_ENDPOINT = `https://accounts.spotify.com/api/token`;

const getAccessToken = async () => {
  const response = await fetch(TOKEN_ENDPOINT, {
    method: 'POST',
    headers: {
      Authorization: `Basic ${basic}`,
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: querystring.stringify({
      grant_type: 'refresh_token',
      refresh_token,
    }),
  });

  return response.json();
};

export const getNowPlaying = async () => {
  const { access_token } = await getAccessToken();

  return fetch(NOW_PLAYING_ENDPOINT, {
    headers: {
      Authorization: `Bearer ${access_token}`,
    },
  });
};

export default async (_, res) => {
  const response = await getNowPlaying();

  if (response.status === 204 || response.status > 400) {
    return res.status(200).json({ isPlaying: false });
  }

  const song = await response.json();
  const isPlaying = song.is_playing;
  const title = song.item.name;
  const artist = song.item.artists.map((_artist) => _artist.name).join(', ');
  const album = song.item.album.name;
  const albumImageUrl = song.item.album.images[0].url;
  const songUrl = song.item.external_urls.spotify;

  return res.status(200).json({
    album,
    albumImageUrl,
    artist,
    isPlaying,
    songUrl,
    title,
  });
};

Add .env.local with authorization data that we have written (change the data below with yours)

SPOTIFY_CLIENT_ID=eaccb97f6d0e405897adf1dd80b95c01
SPOTIFY_CLIENT_SECRET=a4195c2d0a4243609e697e602e70b7
SPOTIFY_REFRESH_TOKEN=AQAtxXvnzRTt4c2-2_Av2WyJQKWxUW_hMVN6QNiqv2i8A2ZElVarmvdhqyc8Pf-Z5n827FTFxTpHq5E3kOsrlRWM3TuJWxjVQsW0icR0zo3BXRFLt2FB2Qfj-pFaZwY-qc8

Your API is ready with route: GET https://localhost:3000/api/spotify

4. Use API with Next.js

For data fetching, we can use SWR. SWR is a great library that can fetch the API periodically. SWR will do refetching each time we refocus a the window. Also, install react-icons to get the spotify logo.

yarn add swr react-icons

or

npm i swr react-icons

Add SWR in pages/index.jsx like this:

import useSWR from 'swr';

export default function Home() {
  const fetcher = (url) => fetch(url).then((r) => r.json());
  const { data } = useSWR('/api/spotify', fetcher);
  return (
    <>
      <section className='bg-gray-600'>
        <main className='flex items-center justify-center'>
          {console.log(data)}
        </main>
      </section>
    </>
  );
}

There will be 2 types of JSON data that will be sent by the Spotify API:

When there is no song playing

   {
     "isPlaying": false
   }

When there is a song playing

   {
     "album": "Menari Dengan Bayangan",
     "albumImageUrl": "https://i.scdn.co/image/ab67616d0000b273d623688488865906052ef96b",
     "artist": "Hindia",
     "isPlaying": true,
     "songUrl": "https://open.spotify.com/track/08OPqLv99g8avzmxQepmiw",
     "title": "Besok Mungkin Kita Sampai"
   }

So, we can conditionally render the data like this:

<a
  target='_blank'
  rel='noopener noreferer'
  href={
    data?.isPlaying
      ? data.songUrl
      : 'https://open.spotify.com/user/erence21?si=yTsrZT5JSHOp7tn3ist7Ig'
  }
  className='relative flex items-center p-5 space-x-4 transition-shadow border rounded-md hover:shadow-md w-72'
>
  <div className='w-16'>
    {data?.isPlaying ? (
      <img
        className='w-16 shadow-sm'
        src={data?.albumImageUrl}
        alt={data?.album}
      />
    ) : (
      <SiSpotify size={64} color={'#1ED760'} />
    )}
  </div>

  <div className='flex-1'>
    <p className='font-bold component'>
      {data?.isPlaying ? data.title : 'Not Listening'}
    </p>
    <p className='text-xs font-dark'>
      {data?.isPlaying ? data.artist : 'Spotify'}
    </p>
  </div>
  <div className='absolute bottom-1.5 right-1.5'>
    <SiSpotify size={20} color={'#1ED760'} />
  </div>
</a>

You can check out the live deployment on spotify-playing.theodorusclarence.com

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀

Understanding Next.js Data Fetching (CSR, SSR, SSG, ISR)

Theodorus Clarence — Thu, 02 Sep 2021 13:53:51 +0000

When I started to learn Next.js, I got overwhelmed with the list of abbreviations that looks similar, I didn't know what it is and what is the difference. It is quite confusing because when using Create React App, we usually only use 1 strategy to fetch data from API which is using useEffect.

Next.js has many data fetching strategies. Although initially Next.js was well known to be a Server-Side Rendering Framework, it turns out that Next.js has 4 methods of Data Fetching. Here is the short explanation each so you get familiar with the abbreviation of CSR, SSR, SSG, ISR.

CSR - Client-Side Rendering, this is the usual kind of data fetching using useEffect, it will fetch the data from the API every single page request on the client-side (after the page is rendered, then the function will run).
SSR - Server-Side Rendering, will run a special function to fetch data from API every page request on the server-side (before the page is loaded, that special function will run first, creating a delay, then after that, it will serve the page).
SSG - Static Site Generation, will run a special function to fetch data once when that page builds.
ISR – Incremental Static Regeneration, this is a new thing, shortly put, a combination of SSG, and SSR, where it served statically, but at a certain time and certain condition that page will rebuild and fetch the data from the API again.

Don't worry if you didn't get that, because I will be explaining it thoroughly, just familiarize the words first.

I mentioned before that there is a special function that will run when using a specific data fetching method. Keep that in mind as I will show you what is that special function.

This code example will fetch a date-time from an API using axios, then render it on the page. It is useful to see the date-time so we can truly know when the API is hit.

Client-Side Rendering (CSR)

Special Function: useEffect

Demo Site

Code Example

export default function CSRPage() {
  const [dateTime, setDateTime] = React.useState<string>();

  React.useEffect(() => {
    axios
      .get('https://worldtimeapi.org/api/ip')
      .then((res) => {
        setDateTime(res.data.datetime);
      })
      .catch((error) => console.error(error));
  }, []);

  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

Demo

Terms:

PT → Preview Time, the time shown when the API is hit. Can be seen in the middle.
RT → Real-Time, the real ticking time updating every second, can be seen on the right bottom corner

Video Description:

Page reloads on 15:46:03 Real-Time (RT), then a LOADING indicator is shown
After about 1s, Preview Time is showing 15:46:04(PT)

Keys to Emphasize

useEffect function, this function is the key indicator that a page is using Client-Side Rendering.
LOADING indicator, because the data fetching runs after the page is rendered, the data is not fetched instantly, therefore showing a loading state.
Data is fetched on every page request, which is why the time shown is different for each reloads.

Server Side Rendering (SSR)

Special Function: getServerSideProps

Demo Site

Code Example

export default function SSRPage({ dateTime }: SSRPageProps) {
  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

export const getServerSideProps: GetServerSideProps = async () => {
  const res = await axios.get('https://worldtimeapi.org/api/ip');

  return {
    props: { dateTime: res.data.datetime },
  };
};

Demo

Video Description:

Clicked the link on 16:32:38(RT), a slight pause for 2s, then page loads showing 16:02:40(PT)

Keys to Emphasize

getServerSideProps function, this function is the key indicator that a page is using Server-Side Rendering.
DELAY before render, and no LOADING indicator, the data is fetched before the page is rendered, so there will be a slight delay where the API is being hit at the moment, then it will show the page without loading indicator
Data is fetched on every page request, which is why the time shown is different for each reloads.

CSR vs SSR

Here is the difference between CSR vs SSR, keep an eye on delay and loading indicators.

Video Description:

When clicking CSR, with no delay a LOADING text is visible for a second, then the Preview Time loads.
When clicking SSR, a slight delay happened, then the page loads.

Keys to Emphasize

CSR hit the API after the page loads.
SSR hit the API before the page loads.

Short addition

I will probably create a new post about the pros and cons of each method, but when using CSR the SEO is not really great because the data is only fetched after the page renders. This is useful and convenient when we are creating a page with a gated authentication, as you don't really need SEO for pages like the dashboard, edit profile page, etc.

But, for the SSR, although it creates a delay, data that was fetched is injected and helps SEO. This is quite useful for a thread or post that we need to get traffic into, like Reddit or some sort.

Static Site Generation (SSG)

Special function: getStaticProps

Demo Site

Code Example

export default function SSGPage({ dateTime }: SSGPageProps) {
  return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

export const getStaticProps: GetStaticProps = async () => {
  const res = await axios.get('https://worldtimeapi.org/api/ip');

  return {
    props: { dateTime: res.data.datetime },
  };
};

Demo

Video Description:

Preview Time is showing 13:39:36(PT). But the real-time is 16:16:59(RT), about 3 hours late.
Reloading and going back and forth to the home page did not change anything.

Keys to Emphasize

getStaticProps function, this function is the key indicator that a page is using Static Site Generation.
Fetched when running yarn build, the API will be hit ONLY when the application is building. This is why the time is at 13:39, while the real-time is 16:17.
Data will not change because no further fetch, which is why the time shown is the same for each reloads.

Incremental Static Regeneration

Special function: getStaticProps + revalidate

Demo Site

Code Example

export default function ISR20Page({ dateTime }: ISR20PageProps) {
    return (
    <main>
      <TimeSection dateTime={dateTime} />
    </main>
  );
}

export const getStaticProps: GetStaticProps = async () => {
  const res = await axios.get('https://worldtimeapi.org/api/ip');

  return {
    props: { dateTime: res.data.datetime },
    revalidate: 20,
  };
};

Demo

Disclaimer: Revalidate time is set to 20 seconds.

Video Description:

At first, it was 16:40:12(PT), and real-time when reloading is 16:40:25(RT) and 16:40:29(RT). In those 2 reload, Preview Time (PT) did not change.
Then, when 16:40:32(RT) (20s after initial), reload is done twice, the first time on 16:40:36(RT) and 16:40:40(RT). The Preview Time change to 16:40:37(PT) after the second reload.

Keys to Emphasize

Now, this is might be confusing for you, but here is the key I want you to look at.

When in a 20-second cooldown span–16:40:12(RT) - 16:40:32(RT), reloading doesn't trigger changes. This is because the page is in a cooldown state, as we set on the revalidate key.
After the 20-second cooldown–16:40:32(RT), we did 2 reloads.
1. First Reload at 16:40:36(RT), we know that it is not on the cooldown state anymore. The first visit after the cooldown state is off, is going to trigger page rebuild. Page rebuild meaning, only this certain page is going to be rebuild. Not the whole application. The fetch API will run in the background, but there will be no changes on the Preview Time
2. Second Full Reload at 16:40:40(RT), the Preview Time change to 16:40:37(PT). Exactly a second after the page rebuild (which means the rebuild takes about 1s). This second reload is going to serve that rebuilt page from the previous reload.

Revisiting Page vs Full Reload

Terms:

Revisiting pages → navigating using next/link (going back to home, then to that page again)
Full reload → doing reload at a website (command+r)

Video Description:

Revisiting pages at the first time 18:38:45(RT), will trigger rebuild, but after the second revisit, the Preview Time did not change.
After a full reload, then Preview Time is changed to 18:38:45(PT)

Note:

The first reload does not have to be a full reload, we can go back to the home page, then to that page again (revisit), it will trigger the rebuild as long as we are not in the cooldown state.
But, the second reload must be a full reload. Going back to the home page, then to the page again won't change the new Preview Time.

Now, this is a case where we are assuming that only 1 person is accessing the website. But, that reloads will happen every person visit while still respecting the cooldown state.

Is it going to be rebuilt every 20s then?

No.

When the cooldown is off, if no one visits the page, then that page will not rebuild, even after long past the 20s.

But, the first person that visits when the cooldown state is off, is going to trigger a rebuild. That person won't be seeing changes. But, the changes will be served for the next full reload.

Conclusion

That's all, folks!

If you have understood this material, I suggest you to read more about How to choose between them. I provide 4 metrics for you to consider and some example!

Originally posted on my personal site, find more blog posts and code snippets library I put up for easy access on my site 🚀