DEV Community: Tom Dohnal

TypeScript `Satisfies` keyword—New TypeScript 4.9 feature

Tom Dohnal — Fri, 11 Nov 2022 17:32:30 +0000

(You can find a video version of this article on YouTube! 📺)

The problem

Imagine you're faced with the following problem:

You have a type City that can be either CityName or CityCoordinates:

type City = CityName | CityCoordinates;

CityName is a string representing one of the specified cities:

type CityName = "New York" | "Mumbai" | "Lagos";

CityCoordinates is an object with x and y properties denoting the coordinates of your city:

type CityCoordinates = {
  x: number;
  y: number;
};

And the User type has birthCity and currentCity, both of which are you type City:

type User = {
  birthCity: City;
  currentCity: City;
};

Then, you want to create a new variable user that adheres to the User type.

You want to assign "Mumbai" to the birthCity property (that's of the type CityName) and { x: 6, y: 3 } to the currentCity property (that's of the type CityCoordinates).

What you would normally do is something like this 👇

const user: User = {
  birthCity: "Mumbai",
  currentCity: { x: 6, y: 3 },
};

That's all well and good and, as of TypeScript 4.8 of less, the only way to make sure that the user variable matches the shape of the User type.

Now, say you want to make the birthCity property of the user variable uppercase.

If you were to do that, however, you'd make TypeScript upset and get an error:

// yields this TypeScript error 👇
// Property 'toUpperCase' does not exist on type 'City'.
//   Property 'toUpperCase' does not exist on type 'CityCoordinates'.
user.birthCity.toUpperCase();

The way that TypeScript sees the birthCity property is that it can be either CityName or CityCoordinates.

It doesn't "know" that you want the user variable to have the CityName type for the birthCity and the CityCoordinates for the currentCity.

`satisfies` to the rescue

Before the satisfies keyword was introduced, there wasn't a good way to achieve this.

More specifically, it wasn't possible to both

ensure that a variable matches the specified type
make TypeScript infer a more specific type based on the values provided to this variable

Now that we've got the satisfies keyword, this very thing is now possible!

The syntax is as follows 👇

const user = {
  birthCity: "Mumbai",
  currentCity: { x: 6, y: 3 },
} satisfies User

The inferred type of the user variable is going to be 👇

{
  birthCity: "Mumbai";
  currentCity: {
    x: number;
    y: number;
  }
}

This will enable us to access string-specific methods (like .toUpperCase()) on the birthCity property and access the x and y number properties on the currentCity variable 👇

// we can call `toUpperCase`
user.birthCity.toUpperCase();

// ...and we can access the `x` (or `y`) properties
// and call `number`-specific methods on them
user.currentCity.x.toFixed(2);

And, on top of that, if we were to assign a value that doesn't match the User type to the user variable, we would get protected from type errors 👇🏻

const user = {
  // assigning "Beijing" yields this error 👇
  //   Type '"Beijing"' is not assignable to type 'City'
  birthCity: "Beijing",
  currentCity: { x: 6, y: 3 },
} satisfies User

In conclusion, with satisfies we can get the best of both worlds. Type safety saves us from runtime errors and powerful type inference gives us most specific types for free.

Source code

You can find the source code for this tutorial on Typescript Playground.

If you liked this tutorial, you can also check out and subscribe to my YouTube channel. Or/and subscribe to my newsletter to get notified when I publish new articles on my website!

Creating Animated Gradient Texts (pure HTML and CSS!)

Tom Dohnal — Wed, 02 Nov 2022 22:29:53 +0000

(You can find a video version of this article on YouTube! 📺)

Check out an interactive version of this blog post on my own blog! (Includes custom widgets created to help you understand the key concepts faster!)

Let's learn how to create animated gradient texts (the ones you might know from vercel.com). This is what we'll build! 👇🏻

We'll use plain HTML and CSS but feel free to use your favorite UI or styling
library as you follow along!

Creating gradient text (w/o animation)

First, we'll create a text with a gradient background but no animation.

For starters, let's put some HTML markup to work with together and apply some boilerplate CSS styles:

<head>
  <style>
    body {
      background: #000;
      padding: 64px;
      margin: 0;
      font-family: sans-serif;

      /* make the rendered glyphs a bit smoother around the edges */
      -webkit-font-smoothing: antialiased;
      -moz-osx-font-smoothing: grayscale;
    }

    h1 {
      margin: 0;
      font-size: 160px;
      font-weight: 800;
      color: #fff;
      letter-spacing: -0.03em;
    }

    .heading-line {
      line-height: 1;
      display: block;
      position: relative;
      text-align: center;
    }
  </style>
</head>

<body>
  <h1>
    <span class="heading-line heading-line-first">Animated.</span>
    <span class="heading-line heading-line-second">Gradient.</span>
    <span class="heading-line heading-line-third">Text.</span>
  </h1>
</body>

If you'd like, you could use the fancy pants nth-child(...) selectors instead of heading-line-first etc. 😇

To add the gradients, we'll set the color to transparent, the background-image to linear-gradient(...) with our favorite colors, and background-clip to text to only render the gradient within the boundaries of the text. 👇🏻

.heading-line {
  /* ... */

  /* set the color of the text to transparent */
  color: transparent;

  /* we need to clip the gradient background so that
  so only the text bit will have the gradient background
  (otherwise the entire rectangle the text is in would have it) */
  -webkit-background-clip: text;
  background-clip: text;
}

.heading-line-first {
  background-image: linear-gradient(to left, #ed8936, #ed64a6);
}

.heading-line-second {
  background-image: linear-gradient(to left, #38b2ac, #0bc5ea);
}

.heading-line-third {
  background-image: linear-gradient(to left, #ecc94b, #48bb78);
}

This is what you should end up with 👇🏻

Animating the gradient

In this section, we're only going to animate the gradient background. To add some more spice to the animation, we're also going to animate white background of each heading. That's gonna be covered in the next section though!

We now have a solid foundation to implement the animation!

Let's think about how the animation should look from a visual standpoint.

When the page loads, what colors should all the headings be? It should probably look like this, where the first heading has the gradient background and the rest have white backgrounds 👇🏻

Then, after a little while, the first gradient should start fading away and the second one should start fading in. 👇🏻

Finally, the first line should be white and the second should have the gradient. 👇🏻

The same applies to the third line. Once that's finished, the first line's gradient appears again and the cycle restarts.

You can see how the gradients are fading in and out as we move the slider 👇🏻

To access the interactive widget you can play with, view this article on my blog

To make the animation, we want to divide it into 6 parts. In each part, either

one heading will have the gradient background (the rest will have white background)
two headings will be fading in/out

We can use the table below to know what exact behavior we want to model in CSS:

Part	Heading 1	Heading 2	Heading 3
1	Gradient	No gradient	No gradient
2	Fading out	Fading in	No gradient
3	No gradient	Gradient	No gradient
4	No gradient	Fading out	Fading in
5	No gradient	No gradient	Gradient
6	Fading in	No gradient	Fading out

We have now done most of the hard work. Now it's time to translate the table above into CSS.

The key thing we'll be animating is the opacity of the gradient background.

When we want the gradient to be visible, we'll set it to 1 and when we want it to be invisible, we'll set it to 0.

Before we can do that, however, we need to make sure that there is a white background underneath the gradient.

To do that, we'll need to wrap the heading lines in span elements, add class heading-line-gradient to them and leverage the ::before pseudo-element.

<h1>
  <span class="heading-line heading-line-first">
    <span class="heading-line-gradient">Animated.</span>
  </span>
  <span class="heading-line heading-line-second">
    <span class="heading-line-gradient">Gradient.</span>
  </span>
  <span class="heading-line heading-line-third">
    <span class="heading-line-gradient">Text.</span>
  </span>
</h1>

The .heading-line-gradient will have the gradient background and .heading-line::before will have the white background.

/* move these style from .heading-line 
   to .heading-line-gradient */
.heading-line-gradient {
  color: transparent;
  background-image: linear-gradient(to left, #ed8936, #ed64a6);
  -webkit-background-clip: text;
  background-clip: text;
}

/* move this from .heading-line-first */
.heading-line-first > .heading-line-gradient {
  background-image: linear-gradient(to left, #ed8936, #ed64a6);
}

/* move this from .heading-line-second */
.heading-line-second > .heading-line-gradient {
  background-image: linear-gradient(to left, #38b2ac, #0bc5ea);
}

/* move this from .heading-line-third */
.heading-line-third > .heading-line-gradient {
  background-image: linear-gradient(to left, #ecc94b, #48bb78);
}

/* white text underneath the gradient text */
.heading-line::before {
  line-height: 1;
  display: block;
  position: absolute;
  color: #fff;
  pointer-events: none;
  width: 100%;
}

.heading-line-first::before {
  content: "Animated.";
}

.heading-line-second::before {
  content: "Gradient.";
}

.heading-line-third::before {
  content: "Text.";
}

Finally, let's focus on the animation! We'll start with the first heading. We'll be animating the opacity of the heading-line-gradient class.

To define the animation, we'll use the @keyframes rule and we'll use the animation property to apply it.

We'll set the animation duration to 8s and set infinite as the number of iterations. 👇🏻

@keyframes first_heading_gradient {
  0%,
  /* 16.667 = 1/6 */
  16.667% {
    opacity: 1;
  }

  /* 33.333% = 2/6 */
  33.333%,
  /* 83.333% = 5/6 */
  83.333% {
    opacity: 0;
  }

  100% {
    opacity: 1;
  }
}

.heading-line-first > .heading-line-gradient {
  /* ... */
  animation: first_heading_gradient 8s infinite;
}

We'll do the same for the second and third headings. 👇🏻

@keyframes second_heading_gradient {
  0%,
  16.667% {
    opacity: 0;
  }

  33.333%,
  50% {
    opacity: 1;
  }

  66.667%,
  100% {
    opacity: 0;
  }
}

@keyframes third_heading_gradient {
  0%,
  50% {
    opacity: 0;
  }

  66.667%,
  83.333% {
    opacity: 1;
  }

  100% {
    opacity: 0;
  }
}

.heading-line-second > .heading-line-gradient {
  /* ... */
  animation: second_heading_gradient 8s infinite;
}

.heading-line-third > .heading-line-gradient {
  /* ... */
  animation: third_heading_gradient 8s infinite;
}

This is what you should end up with 👇🏻

Animating white background

To make the animation stand out, we'll have to animate the white background of the heading as well.

Take one more look the what we want to achieve 👇🏻

You can notice that the white background is sort of fading in when the gradient is fading out and vice versa.

The effect is subtle, but it gives the animation a little bit more spice.

We can't, however, animate the white background for the whole duration of the gradient animation. That would look odd as the text would be almost invisible at one point.

Instead, we'll only start fading the white background away when the gradient is halfway through its fade-in animation and vice versa.

Play around with this widget to see how the opacity of the gradient and white background should behave 👇🏻

Now that we have a better understanding of when to animate the white background, let's create a table that we'll later translate to CSS.

This table only deals with the first heading but the same logic applies to the second and third heading as well.

Now that we're animating the white background as well, we'll need to split the animation into 12 steps (instead of 6).

Part	Gradient opacity	White background opacity
1	1	0
2	1 (start to fade out)	0 (start to fade in)
3	0.5 (still fading out)	1 (already faded in)
4	0 (faded out)	1
5	0	1
6	0	1
7	0	1
8	0	1
9	0	1
10	0 (start fading in)	1
11	0.5 (halfway faded in)	1 (start fading out)
12	1 (faded in)	0 (faded out)

I know that this table seems to be a bit overwhelming and a bit tedious to put together

You can (and I highly encourage you to) create analogical tables for animating the second and third headings.

Anyways, we have done a lot of hard work, the last bit remaining is to express this table in CSS.

Let's start with the first heading. 👇🏻

@keyframes first_heading_white_text {
  0%,
  /* 16.667 = 2/12 */
  16.667% {
    opacity: 0;
  }

  /* 25% = 3/12 */
  25%,
  /* 16.667 = 9/12 */
  91.667% {
    opacity: 1;
  }

  100% {
    opacity: 0;
  }
}

.heading-line-first::before {
  /* ... */
  animation: first_heading_white_text 8s infinite;
}

Analogically, we want to animate the second and third headings' white backgrounds. 👇🏻

@keyframes second_heading_white_text {
  0%,
  25% {
    opacity: 1;
  }

  33.333%,
  50% {
    opacity: 0;
  }

  58.333%,
  100% {
    opacity: 1;
  }
}

@keyframes third_heading_white_text {
  0%,
  58.333% {
    opacity: 1;
  }

  66.667%,
  83.333% {
    opacity: 0;
  }

  91.667%,
  100% {
    opacity: 1;
  }
}

.heading-line-second::before {
  /* ... */
  animation: second_heading_white_text 8s infinite;
}

.heading-line-third::before {
  /* ... */
  animation: third_heading_white_text 8s infinite;
}

🎉🥳 We are DONE!!! 🥳🎉

Source code

You can find the source code for this tutorial on CodeSandbox.

If you liked this tutorial, you can also check out and subscribe to my YouTube channel and my blog!

TypeScript ANY vs UNKNOWN—A Deep Dive

Tom Dohnal — Sun, 14 Nov 2021 21:23:30 +0000

In this blog post, we'll dive deep into what any and unknown types are, what are their similarities and differences, and when (not) to use them.

(You can find a video version of this article on YouTube! 📺)

TLDR;

// ANY
const anyValue: any = 'whatever'

// OK in TypeScript (error in runtime!) 👇
anyValue.do.something.stupid() 


// UNKNOWN
const unknownValue: unknown = 'whatever, too'

// Fails TypeScript check (prevents runtime error) 👇
unknownValue.do.something.stupid()

Mnemonics to help you remember the difference 👇

any -> first letter is an "A" -> Avoid TypeScript
unknown -> first letter is a "U" -> Use TypeScript

The any Type
The unknown Type
Use Cases

The `any` Type

The any type is something like an escape hatch from TypeScript.

What does that mean?

If your variable is of type any, you can:
1. Assign whatever you want to it 👇

let anyValue: any

anyValue = 'hi, how is you? :)'
anyValue = { login: () => { alert('password?') } }

2. "Do" whatever you want with it 👇

let anyValue: any = false

// OK in TypeScript but error in runtime
// ("...is not a function")
anyValue.toUpperCase()

// OK in TypeScript but error in runtime
// ("...Cannot read properties of undefined")
anyValue.messages.hey(':)')

Generally speaking, using any allows you to use variables without type checking.

(https://devrant.com/rants/3015646/i-dont-usually-post-memes-but-this-one-is-just-a-little-too-on-the-nose)

This means that you lose the main benefit TypeScript has to offer–preventing runtime errors due to accessing non-existing properties.

You might now wonder why the heck would I even use any if it means giving up type checking altogether?

Generally speaking, you should strive to avoid it. To do that, I'd advise you to:
1) Use "strict": true in your tsconfig.json file to disable implicit any types

Implicit any means that if you don't annotate a variable or a function parameter in TypeScript, it'll be any by default. With "strict": true, the TypeScript compiler will throw an error if you've got an unannotated variable of type any.

2) Use the no-explicit-any rule in TypeScript ESLint. This will give you an ESLint warning whenever you use any.

However, there are some situations where any is helpful. We'll cover the main use cases in the final section in depth. Nonetheless, it can be useful when migrating JavaScript code to TypeScript or when dealing with untyped external libraries.

Careful! Some built-in TypeScript types use any
When using functions like JSON.parse(...) or fetch(...).then(res => res.json()), the type of the result is any by default.

You can use something like JSON.parse(...) as { message: string } to give it a proper type. Nonetheless, it's useful to know about these as it's very easy to accidentally use any without even knowing about it.

You can use rules such as no-unsafe-assingment in TypeScript ESLint to get warnings in such scenarios.

Why does TypeScript behave in this not type-safe manner? Well, one of the possible explanations is that there was no other way to type these built-in JavaScript functions as there was no unknown type that would be better suited for this job. Let's have a look at what it does and how it differs from the any type.

The `unknown` Type

The unknown type was added to TypeScript in 2018 with its version 3.0 release. Its purpose was to provide a type-safe alternative to any.

From the official docs:
TypeScript 3.0 introduces a new top type unknown. unknown is the type-safe counterpart of any. (https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type)

What does that mean?
As the phrase "type-safe counterpart of any" suggests, the unknown type is similar to the any type in some way but different in others (namely, unlike any, it's type-safe).

Let's first examine the similarities.

You can assign whatever you want to an unknown type
This works pretty much the same way as the any type 👇

let unknownValue: unknown

unknownValue = 'hey, how\'re you doing? :)'
unknownValue = { signUp: () => { alert('email?') } }

With variables of type any you could do anything with such variables (call them, access random properties on them, etc.). This is not the case with unknown.

With unknown, TypeScript makes no assumptions about your variables.

let unknownVariable: unknown

// Error in TypeScript 👇
unknownVariable.toUpperCase()

// Error in TypeScript 👇
unknownVariable.how.are.you('today?')

// Error in TypeScript 👇
const newVariable = unknownVariable + 10

This is very helpful as it prevents you from accidentally accessing non-existent properties, treating strings like functions etc.

You can think of the unknown type as of something like

type unknown = string | number | boolean | object | null | ...

Disclaimer: this is not the actual definition of the unknown type. It's just a simplified model to give you a better intuition.

Type narrowing with `unknown`

As we saw in the code snippet above, TypeScript doesn't allow you to do almost anything with the unknown type.

On one hand, it's very useful as it keeps your code type-safe and prevents you from the dreaded runtime JavaScript TypeErrors.

On the other hand, it's quite limiting as we'd like to be able to manipulate our variables, call properties on them, etc.

We've got 2 options for how to do that.

1) Type Guards
We can use type guards to narrow down the possible types. You can use if statements or custom type predicates to do that.

function logSecretMessage(message: unknown) {
  if (typeof message === 'string') {
    // in this if-block we know `message` is of type string
    // so we can call the `toLowerCase()` method on it
    console.log(message.toLowerCase())
  } else {
    console.log(message)
  }
}

2) Type Assertions (not type-safe)
Alternatively, we can always use type assertions. This is way easier but we lose the type-safety as we use whatever type we want and TypeScript will just "trust" us that we made no mistake:

const unknownVariable: unknown = 'hello';

// OK 👇
(unknownVariable as string).toUpperCase();

// OK in TypeScript but it *fails* in runtime 👇
(unknownVariable as number).toFixed(2)

Use Cases for `any` and `unknown` Types

Now that we've got understanding of what the any and unknown types mean, let's have a look at when (not) to use each of them.

The rule of thumb is that any should be avoided since using it makes you lose most of the TypeScript benefits. If you don't know what type a certain variable or a function parameter is, always prefer unknown.

With that being said, there are some valid use cases for any.

Migrating to TypeScript (from JavaScript)

any is very useful when migrating JavaScript codebase into TypeScript.

Let's say you've got a large JavaScript file which exports many functions and you want to convert it to TypeScript. Without using any, you'd need to type every single function in this file.

That's a lot of work and you might just be interested in typing one of the exported functions.

In this case, you can use any to quickly type the functions you're not interested in and only give proper types to the one function you're currently working with.

It might be also useful to create an alias for any (such as type TODO = any) so that you can later come back to your temporarily typed functions and give them proper types.

// auth.ts (migrating from auth.js)
type TODO = any

// We can just type the `signUp` function
export function signUp(options: {
  email: string
  password: string
}) { /* ... */ }

// Use `TODO` to quickly type the `resetPassword` function
export function resetPassword(options: TODO) { /* ... */ }

// Use `TODO` to quickly type the `logIn` function
export function logIn(options: TODO) { /* ... */ }

Functions with unknown arguments

As previously stated, the unknown type should be preferred when dealing with variables which types we can't determine.

An example could be a generic logger function 👇

function logger(message: unknown) {
  if (development) {
    console.log(message)
  } else {
    sendMessageToAPI(message)
  }
}

Had we used any instead, we could have accidentally tried to use properties such as .toLowerCase() (wrongly) assuming that message is of type string.

Thus, using unknown instead keeps things safe for us 😇

Custom Checkbox in React (Animated and Accessible)

Tom Dohnal — Thu, 21 Oct 2021 18:06:48 +0000

In this article, you're going to learn how to create a custom animated (yet accessible) checkbox. The technique that you'll learn is also applicable for styling radio inputs.

(You can find the video version of this article on YouTube)

How NOT to create a custom checkbox?

Let's first have a look at some possible (but wrong) approaches to creating custom checkboxes and explore their drawbacks.

As you can't really use CSS (as you'd normally do for styling form elements like buttons or text inputs) to style your checkboxes, you might be tempted to do something like this:

// ❌ Do NOT do this. (Bad a11y + hard to integrate with form libraries)
function Checkbox() {
  const [isChecked, setIsChecked] = useState(false)

  return (
    <div
      className={`checkbox ${isChecked ? 'checkbox--active' : ''}`}
      onClick={() => { setIsChecked(!isChecked) }}
    />
  )
}

// + provide styles for .checkbox .checkbox--active classes

There are several problems with this approach.

1) It's bad for for the accessibility
If your user happens to be using a screen reader, there is no way that the screen reader can recognise that your div is actually a checkbox (let alone recognise if the checkbox is checked or not).

2) It breaks the native form behaviour
The div element doesn't emit change events so it's harder to integrate it with form libraries. Moreover, the "form data" on the div element aren't sent to the server upon form submission.

You could fix this by using aria-role="checkbox" on the div element, other aria-* attributes and a lot of JavaScript.

However, there is a simpler way...

How to create a custom checkbox?

First, we'll have a look at how we'll approach it conceptually so that we have a "big picture" of the implementation.

We're going to use three different HTML elements for creating a custom checkbox. A label, an input[type="checkbox"], and span (or svg or whatever you'd like 😉).

The input[type"checkbox"] is going to be visually hidden (but still accessible for screen readers), and we're gonna use the label element as a parent element so that clicking anywhere in the checkbox triggers the change event on the input[type="checkbox"].

Using label as a parent element is valid HTML as per https://www.w3.org/TR/html401/interact/forms.html#edef-LABEL

We'll use aria-hidden="true" on the custom (span or svg) checkbox so that it's hidden for screen readers as its purpose is only "decorative". We're also going to toggle checkbox--active class on it so that we can style it differently for "checked" and "unchecked" states.

With that said, let's write some JSX

import { useState } from "react";

function Checkbox() {
  const [isChecked, setIsChecked] = useState(false);

  return (
    <label>
      <input
        type="checkbox"
        onChange={() => {
          setIsChecked(!isChecked);
        }}
      />
      <span
        className={`checkbox ${isChecked ? "checkbox--active" : ""}`}
        // This element is purely decorative so
        // we hide it for screen readers
        aria-hidden="true"
      />
      Don't you dare to check me!
    </label>
  );
}

To visually hide the native checkbox, create (and import) a new CSS file with the following:

/* taken from https://css-tricks.com/inclusively-hidden/ */
input[type="checkbox"] {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

To learn more about visually hiding things in CSS, visit this blog post on CSS Tricks

If you now hit save and open the browser, you'll see something like this:

The native checkbox is hidden but we still need to style our custom one.

Let's do it in the next section!

Styling Our Custom Checkbox

Let's first include some styles for our custom checkbox:

.checkbox {
  display: inline-block; // set to `inline-block` as `inline elements ignore `height` and `width`
  height: 20px;
  width: 20px;
  background: #fff;
  border: 2px #ddd solid;
  margin-right: 4px;
}

.checkbox--active {
  border-color: purple;
  background: purple;
}

This is going to result in something like this:

While it reacts to our input, it's missing something–a checkmark indicating if the checkbox is checked or not. Let's turn our span into an svg and add a checkmark.

// ...

function Checkbox() {
  // ...

  return (
    <label>
      {/* ... */}
      <svg
        className={`checkbox ${isChecked ? "checkbox--active" : ""}`}
        // This element is purely decorative so
        // we hide it for screen readers
        aria-hidden="true"
        viewBox="0 0 15 11"
        fill="none"
      >
        <path
          d="M1 4.5L5 9L14 1"
          strokeWidth="2"
          stroke={isChecked ? "#fff" : "none"} // only show the checkmark when `isCheck` is `true`
        />
      </svg>
      Don't you dare to check me!
    </label>
  );
}

(You can find the source code for this section on CodeSandbox)

Animating Checkbox using React Spring

In this section, we'll make the checkbox even prettier while maintaining its accessibility.

We'll be using React Spring library for the animations. You might be able to pull this animation off just with plain CSS but as we'll be animating the SVG Path and we'll need JavaScript to measure its length to make the animation possible, library like React Spring will come in handy.

I've created a whole series on animating SVGs with React Spring. Be sure to check it out if you want to learn about it in more detail!

First, let's tackle the easier bit–animating the background and border colours.

After adding react-spring as a dependency using your favourite package manager, let's import animated and useSpring from the library and turn svg into animated.svg and path into animated.path so that they're set and ready to be animated.

// ...
import { animated, useSpring } from "react-spring";

function Checkbox() {
  return (
    <label>
      {/* ... */}
      <animated.svg /* ... */>
        <animated.path /* ... *//>
      </animated.svg>
      {/* ... */}
    </label>
  );
}

Once we're done, we'll use the useSpring hook to animate backgroundColor and borderColor attributes. This is going to be analogical to toggling the values of those properties by using the checkbox--active CSS class.

// ...

function Checkbox() {
  // ...
  const checkboxAnimationStyle = useSpring({
    backgroundColor: isChecked ? "#808" : "#fff",
    borderColor: isChecked ? "#808" : "#ddd"
  });

  return (
    <label>
      {/* ... */}
      <animated.svg
        style={checkboxAnimationStyle}
        /* ... */
      >
        {/* ... */}
      </animated.svg>
      {/* ... */}
    </label>
  );
}

Finally, we'll remove the checkbox--active class from our CSS file as it's no longer needed.

Animating the Checkmark

We'll be using a famous technique for animating SVG Paths (using strokeDashoffset and strokeDasharray) in this tutorial. I created a whole blog post explaining this subject in much more detail.

To animate the checkmark, we first need to measure (and store) its length. We'll use useState(...) to store its length, pass a callback to the ref property of our SVG Path, and call ref.getTotalLength() to measure its length.

// ...

function Checkbox() {
  // ...
  const [checkmarkLength, setCheckmarkLength] = useState(null);

  return (
    <label>
      {/* ... */}
      <animated.svg /* ... */>
        <animated.path
          {/* ... */}
          ref={(ref) => {
            if (ref) {
              setCheckmarkLength(ref.getTotalLength());
            }
          }}
        />
      </animated.svg>
      {/* ... */}
    </label>
  );
}

Now that we've got the length of the path, we can set the strokeDasharray to checkmarkLength and use useSpring to animate the strokeDashoffset between 0 and checkmarkLength. And we'll set the stroke to #fff no matter of the isActive state value.

If you're not use how this works, see my blog post where I explain this very technique in detail.

// ...

function Checkbox() {
  // ...

  const checkmarkAnimationStyle = useSpring({
    x: isChecked ? 0 : checkmarkLength
  });

  return (
    <label>
      {/* ... */}
      <animated.svg /* ... */>
        <animated.path
          // ...
          stroke="#fff"
          strokeDasharray={checkmarkLength}
          strokeDashoffset={checkmarkAnimationStyle.x}
        />
      </animated.svg>
      Don't you dare to check me!
    </label>
  );
}

export default Checkbox;

If you now try your code out, you'll see that it's working quite okay!

While our animation is working quite smoothly, I think we can still add a little bit of spice to take it to the next level.

First, let's tweak the config of the useSpring hook. Let's import the config variable from React Spring which includes some predefined configs and use config: config.gentle in our useSpring(...) calls. This is going to give our animations a little bit more of a playful feel.

// ...
import { /* ... */ config } from "react-spring";

function Checkbox() {
  // ...
  const checkboxAnimationStyle = useSpring({
    // ...
    config: config.gentle
  });

  // ...

  const checkmarkAnimationStyle = useSpring({
    // ...
    config: config.gentle
  });

  // ...
}

Next, if you look at the animation really closely, you'll notice that the checkmark animation only appears for a brief moment. That's because the checkmark is white for the whole duration of the animation while the background is animating from white to purple. So during the time when the background is white, the checkmark is barely visible (as it's white on a white background).

We can tackle this by using the useChain hook from React Spring. This hook enables us to trigger the useSpring(...) animations one after another. In our case, we'll use it to delay the checkmark animation a bit so that it only starts animating when the background of the checkbox is already mostly purple. We'll do the opposite when animating in the other direction.

Let's import useChain along with useSpringRef from react-spring. Then, we'll use the useSpringRef hook to create references to our useSpring calls which we'll then pass into the useChain function:

// ...
import {
  // ...
  useSpringRef,
  useChain
} from "react-spring";

function Checkbox() {
  // ...
  const checkboxAnimationRef = useSpringRef();
  const checkboxAnimationStyle = useSpring({
    // ...
    ref: checkboxAnimationRef
  });

  // ...

  const checkmarkAnimationRef = useSpringRef();
  const checkmarkAnimationStyle = useSpring({
    // ...
    ref: checkmarkAnimationRef
  });

  useChain(
    isChecked
      ? [checkboxAnimationRef, checkmarkAnimationRef]
      : [checkmarkAnimationRef, checkboxAnimationRef],
    [0, 0.1] // -> delay by 0.1 seconds
  );

  // ...
}

If we now play the animation, it looks bonkers!

You can find the source code for the whole tutorial on CodeSandbox

React SVG Animation (with React Spring) #4

Tom Dohnal — Tue, 05 Oct 2021 19:02:31 +0000

In the fourth edition of the React SVG Animation series, we'll learn how to create this 👇

(You can find a video version of this article on YouTube! 📺)

We're going to implement it by animating morphing SVG paths. (It sounds fancier than it should.) The code itself is going to be pretty straightforward but we'll need to spend some time in a graphic editor (like Figma) to get our SVG ready.

(Full source code available on CodeSandbox)

How Does the Animation Work in Theory?
How to Prepare the SVG for the Animation? (optional)
How to morph SVG paths using React Spring?
Bonus: How to Morph SVG Paths with a Different Number of Points?

How Does the Animation Work in Theory?

Let's say we've got this SVG (it look kinda like a frowning mouth) 👇

And we want to animate it into this smiling mouth

Both the frowning and smiling mouths are represented as SVG <path> elements.

The shape of the path is determined by the d attributes. It looks like this: d="M2 2 C18 26 68 62 126 62 C188 62 238 26 254 2" and you can think of it as a series of points (denoted by the numbers) which are connected via different types of lines/curves (denoted by the letters).

In order to animate from one shape to another, we need to animate all the "numbers" in the path definition (the d attribute). Luckily, this is quite easy with a library like React Spring.

If we have a path definition of a smile and of a frown, we can do something like this:

const smilePathDefinition = "M2 2 C18 26 68 62 126 62 C188 62 238 26 254 2"
const frownPathDefinition = "M2 2 C18 -26 68 -62 126 -62 C188 -62 238 -26 254 2"

const animatedProps = useSpring({
  d: shouldSmile ? // `shouldSmile` can be accepted as props or held in local state
    smilePathDefinition : frownPathDefinition
})

return <svg /* ... */>
  <path d={animatedProps.d} /* ... */ />
</svg>

Have a look at this video to get a better understanding of what's going on:

In order for the animation to work properly, the path definitions (the d attributes) must have the same amount of points ("numbers"). (There are some workarounds but let's keep it simple now)

How to Prepare the SVG for the Animation? (optional)

If you're only interested in the coding part of the tutorial, you can skip this section.

As described in the previous section, the animation itself is pretty straightforward in terms of coding. What's a bit more difficult is putting together the SVG Paths in a way that they all have the same amount of points so that they can animate from one to the other.

In order to ensure the same number of points, we'll have to spend some time in a graphics editor of our choice–Figma.

First, we'll need to find the images of the emojis that we'll be animating. We can do that on Emojipedia where you can search for different types of emojis in different "flavours". I generally find the Twitter emojis to be the most simple (thus the most suitable for animations).

You can now download the emojis that we'll be using: disappointed 😞, neutral 😐, and excited 😍

Once you've downloaded the images, open Figma and place all the images next to each other:

Next comes the hardest part of the tutorial. We'll need to use the pen tool in Figma and manually trace the paths of our emoji images in a way that every part which morphs into another part has the same number of points. This means that the eyes in all three emojis should all have the same number of points and the mouths should all have the same number of points as well.

In order to achieve that, let's first copy all three images, decrease their opacity and lock them:

Then, you should trace the edges of the eyes and mouth of the emojis using the pen tool in Figma. Try to use as few points as possible–it will be easier that way. (Four points worked for me.)

Instead of tracing both eyes, do it just once and then copy your path and flip it horizontally.

Do the same for the mouth:

When you're done, copy both the eyes and the mouth, place them over the other two images and adjust the bezier curve handles accordingly while trying to keep the points as close to their original location as possible.

You should end up with something like this:

We've already done the hardest part! Now we need to prepare the emojis for SVG exports.

Let's add a circle according to the template for each of them:

Then, let's fill the eyes and mouths with colours according to the template and remove the stroke:

Group the emojis so that they're ready for export

And, finally, export the images as SVGs!

How to Morph SVG Paths Using React Spring?

Now that we've got the SVG images, let's dive into the code!

First, we'll bootstrap a new react project (e. g. using create-react-app) and add the react-spring library using a dependency manager of our choice.

Next, let's add the SVG of the disappointed face into the code:

function App() {
  return (
    <svg
      width="240"
      height="240"
      viewBox="0 0 240 240"
      fill="none"
      xmlns="http://www.w3.org/2000/svg"
    >
      <circle cx="120" cy="120" r="120" fill="#FFCD4C" />
      <path
        d="M192 135.5C188 135.5 178.5 126 164.5 123C150.5 120 141 125.5 137 123C133 120.5 152 99.0001 172 104.5C192 110 196 135.5 192 135.5Z"
        fill="#664300"
      />
      <path
        d="M48.3939 135.897C52.3939 135.897 61.8939 126.397 75.8939 123.397C89.8939 120.397 99.394 125.896 103.394 123.397C107.394 120.897 88.3939 99.3966 68.3939 104.897C48.3939 110.397 44.3939 135.897 48.3939 135.897Z"
        fill="#664300"
      />
      <path
        d="M119.5 162.5C145 162.5 159.5 189.5 155 194.5C150.5 199.5 153 188.5 119.5 188.5C86 188.5 87.5002 197 84.0001 194.5C80.5001 192 94.0001 162.5 119.5 162.5Z"
        fill="#664300"
      />
    </svg>
  );
}

We can see that the SVG comprises of four different elements.
1) The circle element: The head of the emoji
2) The first path element: The left eye of the emoji
3) The second path element: The right eye of the emoji
4) The third path element: The mouth of the emoji

If we take a look at the neutral SVG and the cheerful SVG, we can see that they follow the same pattern–one circle element for the head and three path elements for the mouth and eyes respectively.

Moreover, the circle element is completely the same for all three emojis as their heads don't change among themselves.

If you take a closer look at the path elements, they all are very similar. The only difference is the d attribute which defines the shape of the path. And that is the attribute we're going to focus on and animate.

Animating the Emoji Mouth

Let's first focus on animating the emoji mouth. First, let's extract all the path definitions (the d attributes) defining the mouths in the above-mentioned SVG files into an array. The first array item should be the frowning mouth, the second one the neutral mouth, and the last one the cheerful mouth

const mouths = [
  "M119.5 162.5C145 162.5 159.5 189.5 155 194.5C150.5 199.5 153 188.5 119.5 188.5C86 188.5 87.5002 197 84.0001 194.5C80.5001 192 94.0001 162.5 119.5 162.5Z",
  "M122.501 160C148.001 160 173.001 159.5 173.001 167.5C173.001 175.5 156.001 173 122.501 173C89.0008 173 66.5 175 66.5 167.5C66.5 160 97.0006 160 122.501 160Z",
  "M120.999 145C158.499 145 171.5 138 176 142.5C187.5 154 164.499 198.5 120.999 198.5C77.4995 198.5 54.929 161.5 62 145C66.2855 135 83.5 145 120.999 145Z"
];

For some reason, Figma added an unnecessary H122.501 at the end of the second path definition in the original SVG. I removed it in the code above as it would introduce and extra point to the path thus breaking the animation.

Then, we'll need to import animated and useSpring from the react-spring library:

import { animated, useSpring } from "react-spring";

Next, let's change all path elements to animated.path so that they're compatible with React Spring animations:

<animated.path /* ... */ />
<animated.path /* ... */ />
<animated.path /* ... */ />

We'll also need to keep track of which emoji should be displayed–let's import and use a useState(...) hook to do that. We'll use numbers 0, 1, and 2 to indicate which emoji should be shown. This is going to correspond to the index of the active item in the mouths array:

// ...
import { useState } from "react";

// ...

function App() {
  const [activeIndex, setActiveIndex] = useState(0);

  // ...
}

Next, we'll need buttons to make switching between the different emojis possible. The buttons are just going to call setActiveIndex(...).

function App() {
  // ...

  return (
    <div>
      {/* ... */}
      <div>
        {["disappointed", "neutral", "excited"].map((text, index) => (
          <button
            type="button"
            key={index}
            onClick={() => {
              setActiveIndex(index);
            }}
            style={{
              background: activeIndex === index ? "purple" : "white",
              color: activeIndex === index ? "white" : "black"
            }}
          >
            {text}
          </button>
        ))}
      </div>
    </div>
  );
}

Finally, the animation itself! Let's first add a useSpring call. We'll the current mouth path as { mouth: mouths[activeIndex] }. React Spring can handle animating between path definitions the same way it can handle animating properties like translate(...).

// ...

function App() {
  // ...
  const animationProps = useSpring({
    mouth: mouths[activeIndex]
  });

  // ...
}

Next, let's replace the hard-coded path definition with the one we get as animationProps.mouth:

// ...

function App() {
  // ...

  return (
    <div>
      <svg /* ... */>
        {/* ... */}
        <animated.path d={animationProps.mouth} /* ... */ />
      </svg>
      {/* ... */}
    </div>
  );
}

If you now click the buttons, the mouth will be animating. Yay! 🙌

You can find the code for this section on CodeSandbox

Animating the Emoji Eyes

Now that we know how to animate the emoji mouths, we'll use the very same approach for animating the emoji eyes as well.

We'll use two array to hold the path definitions of the left and right emoji eyes:

// ...
const leftEyes = [
  "M48.3939 135.897C52.3939 135.897 61.8939 126.397 75.8939 123.397C89.8939 120.397 99.394 125.896 103.394 123.397C107.394 120.897 88.3939 99.3966 68.3939 104.897C48.3939 110.397 44.3939 135.897 48.3939 135.897Z",
  "M60.4997 109.5C60.5744 123 64.9997 132.5 76.9996 132.5C88.9996 132.5 92.4998 124.5 92.4997 112C92.4996 99.5 86.9998 87 76.9996 87C66.9995 87 60.4249 96 60.4997 109.5Z",
  "M10.3812 33.1735C-0.61879 51.1735 4.38095 95.6736 81.3809 107.174C125.381 63.1733 117.381 18.1732 97.3811 7.67327C77.3814 -2.82666 57.8813 11.1733 53.3809 24.6736C47.3812 20.6735 21.3812 15.1736 10.3812 33.1735Z"
];

const rightEyes = [
  "M192 135.5C188 135.5 178.5 126 164.5 123C150.5 120 141 125.5 137 123C133 120.5 152 99.0001 172 104.5C192 110 196 135.5 192 135.5Z",
  "M179.5 109.5C179.575 123 174.963 133.5 164 133.5C153.037 133.5 147 122 147 109.5C147 97 153.5 87 164 87C174.5 87 179.425 96 179.5 109.5Z",
  "M230 32.5002C241 50.5002 236 95.0003 159 106.5C115 62.5 123 17.4999 143 6.99994C163 -3.5 182.5 10.5 187 24.0002C193 20.0002 219 14.5002 230 32.5002Z"
];
// ...

On top of animating the path definitions, we'll also be animating the colour of the eyes as the cheerful emoji has got red eyes. Let's grab the colour hex codes from the SVGs and store them in an array as well:

// ...
const eyeColours = ["#664300", "#664300", "#DE2A42"];
// ...

Let's now leverage our newly created arrays in the useSpring(...) function:

// ...

function App() {
  // ...
  const animationProps = useSpring({
    // ...
    leftEye: leftEyes[activeIndex],
    rightEye: rightEyes[activeIndex],
    eyeColour: eyeColours[activeIndex]
  });

  // ...
}

Finally, pass the newly created animationProps onto the respective SVG paths:

// ...

function App() {
  // ...

  return (
    <div>
      <svg /* ... */>
        {/* ... */}
        <animated.path
          d={animationProps.rightEye}
          fill={animationProps.eyeColour}
        />
        <animated.path
          d={animationProps.leftEye}
          fill={animationProps.eyeColour}
        />
        {/* ... */}
      </svg>
      {/* ... */}
    </div>
  );
}

If you now hit save, it's safe to say, I think, that we're done! ✅

You can find the code for this section on CodeSandbox

Bonus: Animating SVG Paths with a Different Number of Points

So far, we've focused on how to animate SVG paths with the same number of points. Although the animation itself was quite straightforward, it required a non-trivial effort to put the SVGs together in our vector editor (Figma).

In this section, we'll learn how to create the same emoji animation that we've created in the section above without the need to use of any vector editing software.

It won't come without a cost, though. It's going to require a bit more of a programming effort.

How Do Custom Interpolators Work?

Let's first define what we mean be the interpolator.

For our purposes, an interpolator is a function that can be called with a value from 0 to 1. If you call it with 0, you get back the path definition of the original element. If you call it with 1, you get back the path definition of the element you're trying to morph into. If you call it with 0.5, you get back the path definition of a shape that's halfway through its animation journey. And so on. 🙂

We'll use the flubber library in order to create these interpolator functions. This library enables us to create these function if we provide it the path definitions of the shapes from and to we want to animate.

The "magic" part is that the library doesn't require the path definitions to have the same number of points as it's going to do its magic (maths 🙂) and return an interpolator which we can use to create a smooth animation.

Let's Dive Into the Code

We're going to begin where we left off and install flubber.

Next, we need to replace our carefully crafted SVG for the ones from the Twemoji Github.

Open the disappointed emoji, the neutral emoji, and the excited emoji.

Next, replace the path definitions in the mouths, leftEyes, and rightEyes array for the ones you find in the above-mentioned emojis.

Use tools like SVG Path Editor to convert relative paths to absolute ones or Ellipse to Path Converter to turn ellipses into paths. Also, you'll need to split some of the path definitions into parts by finding where each segment of the path ends (marked by the letter Z in the path).

const mouths = [
  "M 23.485 28.879 C 23.474 28.835 22.34 24.5 18 24.5 S 12.526 28.835 12.515 28.879 C 12.462 29.092 12.559 29.31 12.747 29.423 C 12.935 29.535 13.18 29.509 13.343 29.363 C 13.352 29.355 14.356 28.5 18 28.5 C 21.59 28.5 22.617 29.33 22.656 29.363 C 22.751 29.453 22.875 29.5 23 29.5 C 23.084 29.5 23.169 29.479 23.246 29.436 C 23.442 29.324 23.54 29.097 23.485 28.879 Z",
  "M25 26H11c-.552 0-1-.447-1-1s.448-1 1-1h14c.553 0 1 .447 1 1s-.447 1-1 1z",
  "M18 21.849c-2.966 0-4.935-.346-7.369-.819-.557-.106-1.638 0-1.638 1.638 0 3.275 3.763 7.369 9.007 7.369s9.007-4.094 9.007-7.369c0-1.638-1.082-1.745-1.638-1.638-2.434.473-4.402.819-7.369.819"
];

const leftEyes = [
  "M 11.226 15.512 C 10.909 15.512 10.59 15.551 10.279 15.628 C 7.409 16.335 6.766 19.749 6.74 19.895 C 6.7 20.118 6.816 20.338 7.021 20.435 C 7.088 20.466 7.161 20.482 7.232 20.482 C 7.377 20.482 7.519 20.419 7.617 20.302 C 7.627 20.29 8.627 19.124 10.996 18.541 C 11.71 18.365 12.408 18.276 13.069 18.276 C 14.173 18.276 14.801 18.529 14.804 18.53 C 14.871 18.558 14.935 18.57 15.011 18.57 C 15.283 18.582 15.52 18.349 15.52 18.07 C 15.52 17.905 15.44 17.759 15.317 17.668 C 14.95 17.233 13.364 15.512 11.226 15.512 Z",
  "M9,16.5a2.5,3.5 0 1,0 5,0a2.5,3.5 0 1,0 -5,0",
  "M 16.65 3.281 C 15.791 0.85 13.126 -0.426 10.694 0.431 C 9.218 0.951 8.173 2.142 7.766 3.535 C 6.575 2.706 5.015 2.435 3.541 2.955 C 1.111 3.813 -0.167 6.48 0.692 8.911 C 0.814 9.255 0.976 9.574 1.164 9.869 C 3.115 13.451 8.752 15.969 12.165 16 C 14.802 13.833 17.611 8.335 16.883 4.323 C 16.845 3.975 16.77 3.625 16.65 3.281 Z"
];

const rightEyes = [
  "M 24.774 15.512 C 25.091 15.512 25.41 15.551 25.721 15.628 C 28.591 16.335 29.234 19.749 29.26 19.895 C 29.3 20.118 29.184 20.338 28.979 20.435 C 28.912 20.466 28.839 20.482 28.768 20.482 C 28.623 20.482 28.481 20.419 28.383 20.302 C 28.373 20.29 27.373 19.124 25.004 18.541 C 24.29 18.365 23.592 18.276 22.931 18.276 C 21.827 18.276 21.2 18.529 21.196 18.53 C 21.129 18.558 21.065 18.57 20.99 18.57 C 20.718 18.582 20.481 18.349 20.481 18.07 C 20.481 17.905 20.561 17.759 20.684 17.668 C 21.05 17.233 22.636 15.512 24.774 15.512 Z",
  "M22,16.5a2.5,3.5 0 1,0 5,0a2.5,3.5 0 1,0 -5,0",
  "M 19.35 3.281 C 20.209 0.85 22.875 -0.426 25.306 0.431 C 26.782 0.951 27.827 2.142 28.235 3.535 C 29.426 2.706 30.986 2.435 32.46 2.955 C 34.89 3.813 36.167 6.48 35.31 8.911 C 35.187 9.255 35.026 9.574 34.837 9.869 C 32.886 13.451 27.249 15.969 23.835 16 C 21.198 13.833 18.39 8.335 19.118 4.323 C 19.155 3.975 19.23 3.625 19.35 3.281 Z"
];

The eyeColours array stays the same.

You might now see something like this and wonder if it's broken:

To fix this, change the viewBox to 0 0 36 36 which is the viewbox used in the original emoji. Also, we'll need to change the parameters of the circle used for the emoji head.

// ...

function App() {
  // ...

  return (
    {/* ... */}
      <svg viewBox="0 0 36 36" /* ... */ >
        <circle cx="18" cy="18" r="18" fill="#FFCD4C" />
        {/* ... */}
      </svg>
  );
}

Finally, let's dive into the nitty-gritty of the interpolators.

We'll keep track of the interpolators in the local state (using useState(...)). We'll use three interpolators–one for animating the mouth and one for each of the eyes.

When we click the button to trigger the animation, we'll update the interpolator state to hold the specific interpolators for the animations. For example–if the current state of the emoji is "dissapointed" and we want it to animate to "neutral", we'll update the interpolator state to this exact interpolators. We'll then use the useSpring(...) to animate from 0 to 1 to trigger the animation.

First, initialise the interpolator state:

// ...

function App() {
  // ...
  const [interpolators, setInterpolators] = useState({
    mouth: () => mouths[activeIndex],
    leftEye: () => leftEyes[activeIndex],
    rightEye: () => rightEyes[activeIndex],
  });
  // ...
}

Their initial state is set to "trivial" interpolators–they return the same paths no matter what number we supply to the function.

Next, we need to make some adjustments to the useSpring(...) function. We'll always be animating from 0 to 1, which needs to be reflected in the from and to options. We'll also set the clamp to true which will prevent the animated number from overreaching 1 which would break our interpolators. Finally, we'll set the reset option to true to make the animated value always go back to 0.

// ...

function App() {
  // ...
  const animationProps = useSpring({
    from: { x: 0 },
    to: {
      x: 1,
      eyeColour: eyeColours[activeIndex], // this stays the same as it doesn't need a custom interpolator
    },
    config: {
      clamp: true, // interpolation function can't go above 1
    },
    reset: true,
  });
  // ...
}

We'll then adjust the animated.path elements to make use of the interpolators. We'll leverage to .to(...) function which enables us to pass an interpolator function to interpolate an animated value:

// ...

function App() {
  // ...

  return (
    <div>
      <svg /* ... */>
        {/* ... */}
        <animated.path
          d={animationProps.x.to(interpolators.rightEye)}
          // ...
        />
        <animated.path
          d={animationProps.x.to(interpolators.leftEye)}
          // ...
        />
        <animated.path
          d={animationProps.x.to(interpolators.mouth)}
          // ...
        />
      </svg>
      {/* ... */}
    </div>
  );
}

Finally, we need to adjust the onClick button handler. The gist of is that we want to create new interpolators from the previous value of activeIndex to the new value of activeIndex on the button click.

In order to do that, we'll pass a callback to the setActiveIndex function in which we'll update the interpolators using the interpolate(...) function from the flubber library.

// ...
import { interpolate } from "flubber";

function App() {
  // ...

  return (
    <div>
      {/* ... */}
      <div>
        {["disappointed", "neutral", "excited"].map((text, index) => (
          <button 
            // ...
            onClick={() => {
              setActiveIndex((prevIndex) => {
                setInterpolators({
                  mouth: interpolate(mouths[prevIndex], mouths[index], {
                    maxSegmentLength: 0.5
                  }),
                  rightEye: interpolate(
                    rightEyes[prevIndex],
                    rightEyes[index],
                    {
                      maxSegmentLength: 0.5
                    }
                  ),
                  leftEye: interpolate(leftEyes[prevIndex], leftEyes[index], {
                    maxSegmentLength: 0.5
                  })
                });

                return index;
              });
            }}
            // ...
          >
            {/* ... */}
          </button>
        ))}
      </div>
    </div>
  );
}

The maxLengthSegment ensure the smoothness of the animation. The lower the number, the smoother it is. But be careful–it comes at a cost of performance.

We're done! 🥂 Here's the final result:

You can find the code for this section on CodeSandbox

React SVG Animation (with React Spring) #3

Tom Dohnal — Mon, 01 Mar 2021 20:21:05 +0000

In the third edition of the React SVG Animation series, we're going to create this 👇

(You can find a video version of this article on YouTube! 📺)

We're going to implement it by animating lines in SVG (the path element) and we'll learn how to extract animation logic into re-usable custom hooks.

(Full source code available on CodeSandbox)

How to prepare the SVG for the animation?
How we're going to build the animation?
How to animate lines in SVG?
How to create a re-usable animation hook?
Final touches

How to prepare the SVG for the animation?

Before we start talking about the animation, we need to have something to animate.

After creating a new React app using your favourite tool (e. g. create-react-app) and installing react-spring@next using your favourite package manager, copy and paste this SVG. 👇

Note that we're using the next version of the react-spring library as the newest version (v9) is still in the rc stage.

function Image() {
  return (
    <svg
      xmlns="http://www.w3.org/2000/svg"
      width="286"
      height="334"
      fill="none"
      viewBox="0 0 286 334"
    >
      <path
        fill="#A78BFA"
        stroke="#A78BFA"
        strokeWidth="2"
        d="M 143, 333 C 31.09 261.823 1 73.61 1 73.61 L 143 1 v 332 z"
      />
      <path
        fill="#8B5CF6"
        stroke="#8B5CF6"
        strokeWidth="2"
        d="M 143, 333 C 254.911 261.823 285 73.61 285 73.61 L 143 1 v 332 z"
      />
      <path
        stroke="#4ADE80"
        strokeWidth="24"
        d="M75 153.5l68.081 77.5L235 97"
      />
    </svg>
  );
}

You can see that the SVG is comprised of three path elements which correspond to the two left and right part of the "shield" and the checkmark.

Let's extract them into separate components so that it's easier for us to work with them independently.

First, grab the last path element and create a Checkmark Component:

function Checkmark() {
  return (
    <path
      stroke="#4ADE80"
      strokeWidth="24"
      d="M75 153.5l68.081 77.5L235 97"
    />
  );
}

Next, we'd like to extract the left and right part of the shield. As the animation is identical for both parts of the shield, it's a good idea to create a ShieldPart component which will accept a color and a d (path definition) as props. We'll then pass the corresponding colour and path definition to the ShieldPart components.

function ShieldPart({ color, d }) {
  return (
    <path
      fill={color}
      stroke={color}
      strokeWidth="2"
      d={d}
    />
  );
}

Once you've created those components, put the inside the svg instead of the path elements.

<svg
  // ...
>
  {/* Left shield part */}
  <ShieldPart
    d="M 143, 333 C 31.09 261.823 1 73.61 1 73.61 L 143 1 v 332 z"
    color="#A78BFA"
  />
  {/* Right shield part */}
  <ShieldPart
    d="M 143, 333 C 254.911 261.823 285 73.61 285 73.61 L 143 1 v 332 z"
    color="#8B5CF6"
  />
  <Checkmark />
</svg>

We're now good to go and can start talking about the animation itself.

(You can see the source code for this section on CodeSandbox)

How we're going to build the animation?

Let's have a proper look at the animations we're going to build. 👀👇

If you look really carefully, you can see that the animation consists of three parts.

First, the edges of the shield animate:

Then, the shield gets filled with colour:

Lastly, the checkmark animates:

Animating the shield "background" colour is quite straightforwards–we're justing going to animate the fill property (an SVG equivalent of background property) from #fff (white) to the desired colour.

However, how do we go about animating the shield edges and checkmark? Well, we need a bit of "SVG trickery" to do that. Let's learn out it in the next section.

How to animates lines in SVG?

What do we even mean by "lines" in SVG? We do not mean the line element but a path element with a stroke.

Let's use our "checkmark" path element as an example.

<path
  stroke="#4ADE80" // defines the colour of the "line"
  strokeWidth="24" // defines the width of the "line"
  d="M75 153.5l68.081 77.5L235 97"
/>

Strokes in SVGs are similar to borders in HTML. The stroke property defines the colour of the "line" (roughly equivalent to border-color in HTML) and stroke-width defines the "thickness" of the "line" (roughly equivalent to border-width in HTML).

"What the heck does stroke and stroke-width have to do with animating the SVG," you might think. And you're right (partially 😉). We're going to animate neither of those properties but they do need to be present on the path for the animation to make sense. If the path would only have the fill property (something like background in HTML) and not stroke, we wouldn't be able to animate it.

Now that we've learnt about the prerequisites for the animation, let's move on and learn about another two properties (and these will actually be directly involved in the animation)–stroke-dasharray and stroke-dashoffset.

The stroke-dasharray property is used to turn your "solid" line into a "dashed" line and defines how wide one "dash" is.

See the demonstration below. 👇

You can notice that if we set the range to its max value (which is equal to the length of the checkmark), the one "dash" covers the whole checkmark. This will be the key to the animation!

The stroke-dashoffset property defines how much "shifted" the "dashes" are.

Have a look. 👀👇

You might have noticed that if you set the stroke-dasharray property equal to the length of the path (which you can get using .getTotalLength()), it appears as if there were no stroke-dasharray set at all.

But is it really the case? Well, it certainly appears so, but it doesn't mean that it's the case. Actually, the line is still dashed, but the gap in the dashes is not visible as it's "after" the end of the checkmark.

What if we, though, combined stroke-dasharray set to the length of the path with stroke-dashoffset? What would it look like? 🤔 Let's have a look:

What?! How's that possible? It looks like what we've wanted to achieve! The checkmark is animating!

As the stroke-dashoffset changes from 0 to the length of the checkmark, the checkmark is disappearing. That's because the "gap" (which's length is also equal to the length of the checkmark) gets "before" the "dash". If the stroke-dashoffset is set to 0, only the "dash" part is visible. If it's set to the length of the checkmark, only the "gap" part is visible.

Therefore, to animate the checkmark, you have to:
1) Set its stroke-dasharray to its length (you can get it by .getTotalLength()
2) Animate its stroke-offset from the length (obtained by .getTotalLength()) to 0.

Let's do that in the next section!

Animating `path` in React Spring

First, we need to find out the length of the path. You can either call the .getTotalLength() function on the path element and hard-code the value, or you can use useState from React, and set the length of the path by passing a callback to the ref property:

function Checkmark() {
  const [length, setLength] = useState(null);

  return (
    <path
      ref={(ref) => {
        // The ref is `null` on component unmount
        if (ref) {
          setLength(ref.getTotalLength());
        }
      }}
      // ...
    />
  );
}

Next, we'll make the Checkmark accept a toggle property which will trigger the animation.

We'll also set its stroke-dasharray equal to the length that we keep track of.

Finally, we're going to animate the stroke-dashoffset. We'll use the useSpring hook for that. If the toggle is truthy, we'll set its value to 0 (the checkmark will appear). If it's falsy, we'll set it to the value of length (the total length of the checkmark) and it'll disappear.

function Checkmark({ toggle }) {
  const [length, setLength] = useState(null);
  const animatedStyle = useSpring({
    // we do *not* animating this property, we just set it up
    strokeDasharray: length,
    strokeDashoffset: toggle ? 0 : length
  });

  return (
    <animated.path
      style={animatedStyle}
      ref={(ref) => {
        // The ref is `null` on component unmount
        if (ref) {
          setLength(ref.getTotalLength());
        }
      }}
      // ...
    />
  );
}

If you're not familiar with using useSpring, animated, and React Spring in general, check out my previous posts about animating SVGs using React!

Finally, we need to pass the toggle variable from our main Image component down to the Checkmark component.
We'll set it to false initially and use the useEffect hook together with setImmediate to set it to true once the component mounts and the checkmark length is measured (using the .getTotalLength()).

function Image() {
  const [toggle, setToggle] = useState(false);

  useEffect(() => {
    // `setImmediate` is roughly equal to `setTimeout(() => { ... }, 0)
    // Using `setToggle` without `setImmediate` breaks the animation
    // as we first need to allow for the measurement of the `path`
    // lengths using `.getTotalLength()`
    setImmediate(() => {
      setToggle(true);
    });
  }, []);

  return (
    <svg
      // ...
    >
      {/* ... */}
      <Checkmark toggle={toggle} />
    </svg>
  );
}

(You can find the full source-code for this section on Codesandbox)

How to create a re-usable animation hook?

Thus far, we've only applied what we've learnt to the checkmark animation. However, a very similar animation could be applied to animate the edges of the shield.

That's why it might be a good idea to extract the logic of animating a "line" in SVG into a separate hook.

The hook is going to be responsible for measuring the path length and animating the path based on the toggle variable.

So it's going to accept toggle as an argument and return a style variable (for the animation) and a ref variable (for the path length measurement).

function useAnimatedPath({ toggle }) {
  const [length, setLength] = useState(null);
  const animatedStyle = useSpring({
    strokeDashoffset: toggle ? 0 : length,
    strokeDasharray: length
  });

  return {
    style: animatedStyle,
    ref: (ref) => {
      // The ref is `null` on component unmount
      if (ref) {
        setLength(ref.getTotalLength());
      }
    }
  };
}

We're the going the use this hook in the Checkmark component:

function Checkmark({ toggle }) {
  const animationProps = useAnimatedPath({ toggle });

  return (
    <animated.path
      {...animationProps}
      // ...
    />
  );
}

If you now refresh the page, the animation should look exactly the same as before this refactor.

Next, let's use the very same useAnimatedPath hook for animating the edge of the shield in the ShieldPart component.

// do *not* forget to make the `ShieldPart`
// component accept the `toggle` prop
function ShieldPart({ color, d, toggle }) {
  const animationProps = useAnimatedPath({ toggle });

  return (
    <animated.path // `path` -> `animated.path`
      {...animationProps}
      // ...
    />
  );
}

Finally, pass the toggle prop onto the ShieldPart components:

function Image() {
  // ...

  return (
    <svg {/* ... */}>
      {/* Left shield part */}
      <ShieldPart
        toggle={toggle}
        // ...
      />
      {/* Right shield part */}
      <ShieldPart
        toggle={toggle}
        // ...
      />
      {/* ... */}
    </svg>
  );
}

If you now refresh the page, you won't really be satisfied as you'll barely see the shield edges being animated.

That's because we're not animating the fill (something like background in HTML) of the shield and the colour of the shield edges match the colour of the shield background. Let's do it and finish the animation in the next section.

(You can find the full source code of the section on CodeSandbox)

Final touches

First, let's tackle animating the fill (something like background in HTML) of the ShieldPart component.

We'll use a useSpring hook for the animation and will animate from #000 (white colour) when the toggle is falsy to the color property that the ShieldPart component accepts when the toggle property is truthy.

function ShieldPart({ color, d, toggle }) {
  // rename: `animationProps` -> `animationStrokeProps`
  const animationStrokeProps = // ...
  const animationFillStyle = useSpring({
    fill: toggle ? color : "#fff"
  });

  return (
    <animated.path
      {...animationStrokeProps}
      // as the `animationStrokeProps` have a `style` property 
      // on it, it would be overriden by just passing
      // `style={animationFillStyle}`
      style={{
        ...animationStrokeProps.style,
        ...animationFillStyle
      }}
      // *remove* the `fill={color}`
      // ...
    />
  );
}

If you now refresh the page, the animation will look better. Just a little bit better, though. That's because everything is animating all at once. Instead, we want to animate the edges of the shield first, then fill the shield with colour and only then animate the checkmark.

In order to do that, let's leverage the delay property which we can pass to the useSpring function.

First, let's make our custom useAnimatedPath accept a delay as an argument:

function useAnimatedPath({ toggle, delay }) {
  // ...
  const animatedStyle = useSpring({
    // ...
    delay
  });

  // ...
}

Next, let's set a delay of 250 ms for the animation of fill in the ShieldPart component:

function ShieldPart({ color, d, toggle }) {
  // ...
  const animationFillStyle = useSpring({
    // ...
    delay: 250
  });

  // ...
}

Finally, put a delay of 500 to the useAnimatedPath hook in the Checkmark component:

function Checkmark({ toggle }) {
  const animationProps = useAnimatedPath({
    // ...
    delay: 500
  });

  // ...
}

Note that the exact numbers we put to the delay property are somewhat arbitrary. There is no right or wrong way number, just watch the animation and fine-tune the exact numbers to your liking

Hit refresh in your browser and the animation should look like this 🎉👇

You can find the full source-code for this article on CodeSandbox!

React SVG Animation (with React Spring) #2

Tom Dohnal — Sun, 20 Dec 2020 18:40:40 +0000

Are you a video learner? This blog post is also available in a video form on YouTube:

Look at the animation below 👇

You'll learn how to create this SVG animation in React Spring and what's tricky about animating transform: scale(...) and transform: rotate(...) in SVG.

(Full source code available on CodeSandbox)

How to Prepare the SVG for Animation?
Why the "Naive" Approach Does NOT Work?
How Does transform-origin Work in SVG?
Final touches
Bonus: How to do this in Framer motion and GSAP?

How to Prepare the SVG for Animation?

I assume you already know how to include SVGs in React. If not, check out my previous post (or YouTube video) where I explain everything from scratch.

For this animation, we're using an SVG I found on the unDraw website. After you download the SVG and convert the SVG to JSX, go ahead and locate the three icons in the SVG code and create separate React components out of them. (So that it's easier to work with.)

You should end up with something like this:

import React from 'react'

function Icon1() {
    return <g>{/* ... */}</g>
}
function Icon2() {
    return <g>{/* ... */}</g>
}
function Icon3() {
    return <g>{/* ... */}</g>
}

function App() {
    const icons = [<Icon1 />, <Icon2 />, <Icon3 />]

    return (
        <svg /* ... */>
            {icons}
            {/* ... */}
            {/* ... */}
        </svg>
    )
}

Next, add a toggle button which will trigger the enter/leave animation

import React, { useState } from 'react'

// ...
// ...

function App() {
    const [toggle, setToggle] = useState(false)

    // ...
    // ...

    return (
        <>
            <button
                type="button"
                onClick={() => {
                    setToggle(!toggle)
                }}
            >
                Toggle animation
            </button>
            {/* ... */}
            {/* ... */}
        </>
    )
}

You're now ready to start animating!

You can see the code for this section on CodeSandbox:

Why the "Naive" Approach Does NOT Work?

If you're familiar with animating HTML elements (or you've read the previous tutorial), you might think: "Oh, this animation is kinda easy, I'm just gonna use transform: rotate(...) scale(...) on the icon components and I'll be good to go".

Honestly, it seems like the perfectly reasonable thing to do. So pull up React Spring (or your favourite animation tool) and give it a try:

// ...
import { animated, useSprings } from 'react-spring'

// ...
// ...

function App() {
    // ...
    // ...

    const springs = useSprings(
        3,
        icons.map(() => ({
            transform: toggle ? 'rotate(0deg) scale(1)' : 'rotate(360deg) scale(0)',
        })),
    )

    const animatedIcons = springs.map((style, index) => (
        <animated.g style={style}>{icons[index]}</animated.g>
    ))

    return (
        <>
            {/* ... */}
            <svg /* ... */>
                {animatedIcons} {/* `animatedIcons` instead of `icons` */}
                {/* ... */}
            </svg>
        </>
    )
}

The code looks quite okay in my opinion. Nonetheless, if you trigger the animation you'll be unpleasantly surprised as you'll see this:

While the icons are being animated, they all seem to be rotating around a single point rather than each being rotated individually around their own centre points.

That's weird, you think. You might even have used transform: rotate(...) or transform: scale(...) for animating HTML elements and you're sure that it worked just fine. Yes, you're right, this would work just fine if we were animating HTML elements. But animating SVG elements is a bit trickier...

You can see the source code for this section on Codesandbox:

How Does `transform-origin` Work in SVG?

If you look at the (somewhat broken) animation above, you'll notice that the items are rotating around a point somewhere in the top-left corner of the screen. That's not what you want, you want the icons to be rotating around their own centre points. Is there a way to do that? The thing you're looking for is called transform-origin

According to MDN web docs, the transform-origin property "sets the origin for an element's transformations". Well, what does it really do? I think it's best demonstrated in a combination with transform: rotate(...) where it specifies the point which the element you're animating should revolve around.

How come you've never needed transform-origin for animating HTML elements? It's because its default value is 50% 50% (could be written as center) for HTML elements which corresponds to their middle points. For SVG elements, however, the default value is 0, 0 which corresponds to the top-right point in the SVG's viewbox.

Look at animation below to see how animating transform: rotate(...) with default transform-origin works in SVG. 👇

The first idea on how to fix you might have could be this: If the default value of transform-origin is 0, 0 for SVGs and 50% 50% (could be written as center) for HTML elements, let's manually set the transform-origin to center for the SVG and it's gonna behave how I want (rotate around the centres of the elements).

If you were to try it, however, you wouldn't like the result. That's because setting transform-origin: center works differently for HTML and SVG elements. For HTML elements, it sets the origin point to the centre of the actual element you're animating. For SVG element it sets the origin point to the centre of the viewbox which contains your SVG element.

Have a look at the animation below to get a visual intuition for what's going on. 👇

After all the struggle it seems like there is not an easy solution for making SVG elements rotate around their own centre points. If you think that, I've got good news for you. It can be fixed by adding one extra line of CSS. Add transform-box: fill-box in addition to transform-origin: center and watch the animation behave just like you wanted!

The transform-box property specifies what the transform-origin property should relate to. Its default value is transform-box: view-box which makes the transform-origin relate to the SVG viewbox. If you set it to transform-box: fill-box, it's going to relate to the element it's applied to. So the centre of the rotation is going to be the centre of the element you're rotating rather than the centre of the viewbox.

Have a look at the animation below for a more visual explanation. 👇

Now that we've dived deep into the SVG transform intricacies, it's time to apply what we've learnt to our SVG animation:

// ...
// ...

function App() {
    // ...
    // ...

    const animatedIcons = springs.map((style, index) => (
        <animated.g
            style={{
                transformOrigin: 'center', // <- make it centre
                transformBox: 'fill-box', // <- of the element
                ...style,
            }}
        >
            {icons[index]}
        </animated.g>
    ))

    // ...
    // ...
}

You can see the source code of this section on CodeSandbox

(One downside to using transform-box: fill-box is that it is not supported in legacy browsers (IE11). You could still achieve setting the transform-origin to the centre of the element by using exact pixel values like this: transform-origin: 120px 160px where 120px 160px would be the centre of the SVG element.)

Final touches

Compare the animation we've got at this point with what we'd like it to look like:

What we've got 👇

What we'd like it to look like 👇

The latter animation has got more of a playful feel to it. It boils down to two things.

Staggered effect (icons animating one after another)
Wobbly effect (adding "bounciness")

Add staggered effect

To add the staggered effect, let's use the delay option passed to the useSpring function. (We used this approach in the previous tutorial, too.)

We leverage the fact that an index is passed to the .map(...) function and add a different delay for each of the icons:

// ...
// ...

function App() {
    // ...
    // ...

    const springs = useSprings(
        3,
        icons.map((_, index) => ({
            // ...
            // ...
            delay: index * 50, // 1st icon -> 0ms, 2nd icon -> 50ms, 3rd icon -> 100ms
        })),
    )

    // ...
    // ...
}

Add wobbly effect

Adding the wobbly effect comes down to configuring the spring animation. More specifically, decreasing the friction. Friction controls the spring "resistance". The higher the friction, the less "bouncy" animation. The lower the friction, the more "bounciness".

It's usually best to fine-tune the exact numbers of the animation configuration manually.

// ...
// ...

function App() {
    // ...
    // ...

    const springs = useSprings(
        3,
        icons.map((_, index) => ({
            // ...
            // ...
            config: {
                friction: 16, // the default value is 26 (we *decrease* it to add bounciness)
            },
        })),
    )

    // ...
    // ...
}

You can see the code for this section on CodeSandbox:

Bonus: How to do this in Framer motion and GSAP?

Everyone uses a different animation library. Nonetheless, the animation principles are pretty much the same. Some libraries do more of the manual work for you (e. g. Framer Motion which applies makes the "rotate" and "scale" animations work with SVG out-of-the-box), some are more bare-bones like React spring. Some libraries are framework specific (React Spring and Framer Motion) and some are more general (GSAP where you have to orchestrate your animation using useEffect and useRef).

If you're interested, have a look at the implementation of the same animation in React Spring, Framer Motion, and GSAP on Codesandbox

TwitterFOMO—Open-Source Website Showing Most Liked Tweets in WebDev

Tom Dohnal — Sun, 22 Nov 2020 15:13:27 +0000

You can find the source on https://github.com/tomdohnal/twitter-fomo. The website is on https://twitterfomo.dev

The app is built in Next.js. Components are created using ChakraUI. I used react-spring for the animations. The SVG images are from undraw.co.

(Also started a YouTube channel where I explain how I did the SVG animations! You can check it out on https://www.youtube.com/channel/UCE7h4of6ywpAG87KXHV6UrQ)

I use a simple cron job on Heroku which is run every hour to fetch the most-liked tweets and upload them to a Postgres DB using Prisma. The app itself is hosted on Vercel.com.

I'd love to hear your feedback! Especially, I'd like to hear what you'd suggest doing to filter out "off-topic" tweets so that only the webdev related ones are shown.

React SVG Animation (with React Spring) #1

Tom Dohnal — Sat, 21 Nov 2020 23:05:45 +0000

Are you a video learner? This blog post is also available in a video form on YouTube:

Look at the animation below 👇

You'll learn how to build it using React and react-spring library.

How to Find an SVG to Animate?
How to Include an SVG in React?
How to Prepare the SVG for Animation?
How to Animate the SVG Elements?
How to Make the Animation Look Good?
How to Create More Advanced Animations?

How to Find an SVG to Animate?

The first step you should take to create an animated SVG is to pick an SVG image you want to animate. If you're a skilled illustrator, you can create your own. But if you're like me, websites like undraw.co will do the trick. However, the SVG we're animating is no longer there at the time of writing this article but you can still find it here.

How to Include an SVG in React?

There are two ways of including an SVG in React code.

The first one is using <img src="kitten.svg" alt="kitten" /> just like with .jpg or .png images. However, this approach is not suitable for animations as you lose control over the individual parts of the SVG you want to animate.

The second approach is using "inline SVG". This means putting the SVG code right into React (JSX)!

To do that, view the source code of this image, and copy it. Then, head over to https://svg2jsx.com and paste the copied SVG code into the editor on the left. This tool will convert the SVG to JSX. (It will close every unclosed SVG elements and convert attributes such as stop-color to stopColor)

Now copy the code from the editor on the right-hand side and paste it into your editor. The SVG will appear in your browser!

You can view the code for this section in the embedded CodeSandbox below. 👇

(I decreased the width and height of the original svg so that it fits in the CodeSandbox embed)

How to Prepare the SVG for Animation?

To be able to animate specific parts of the SVG image, you should extract them to individual React components so that it's a bit easier to work with. (Remember, you can treat the SVGs just like HTML and split it into many components.)

Because we want to animate the envelopes let's create a component for each envelope. Now comes the hard—finding out which of almost 300 lines of SVG code create the envelopes.

Open the browser devtools and try to locate the envelope using the element picker. If you locate a part of the SVG which you think is a part of the envelope, you can try deleting it (using the delete key) and see if the envelope (or its part) actually gets removed. (Use ctrl + z or cmd + z to bring it back).

After playing with the devtools for a bit, you can identify that each envelope is composed of two path elements followed by a g element.

Now, you can head over to your editor, create <Envolope1 />, <Envolope2 />, <Envolope3>, and <Envelope4 />. You should use a g element as the parent element in your Envelope components to group the items in it. (Think of the g element as an SVG alternative to the div element.)

The last steps in this part is to create an array of the Envelope component on top of your main component and include it to where the envelopes where in the svg:

function Icon() {
  const envelopes = [
        <Envelope1 key="envelope1" />,
        <Envelope2 key="envelope1" />,
        <Envelope3 key="envelope1" />,
        <Envelope4 key="envelope1" />,
    ]

    return (
        <svg>
            // ...
            // ...
            {envelopes}
        </svg>
    )
}

The image itself should look exactly the same as at the end of the previous section.

You can view the code for this section in the embedded CodeSandbox below. 👇

How to Animate the SVG Elements?

Finally, here comes the fun part! 🎉

First, you need something to trigger the animation. Let's use a simple button which will toggle a variable. Based on the value of that variable, the envelopes will arrive or go away.

import React, { useState } from 'react'

function Icon() {
    const [toggle, setToggle] = useState(false)
  // ...
  // ...

    return (
        <>
            <button type="button" onClick={() => { setToggle(!toggle) }}>
                Toggle animation
            </button>
            <svg>
                // ...
                // ...
            </svg>
        </>
    )
}

Now that you have a toggle variable to trigger the animation you can start animating.

For animating an array of elements with react-spring you should use the useSprings hook. (Read the documentation to learn more about it.)

To create the animation effect the transform: translate3d(...) and opacity are used. The value passed to the translate3d(...) function or opacity is going to change based on the toggle variable.

The useSprings hook will return an array of animated values which we can map over.

import { useSprings } from 'react-spring'

function Icon() {
    // ...
    // ...

    const envelopes = [
    // ...
    // ...
  ];

    const springs = useSpring(
      envelopes.length, // the number of springs to create
        envelopes.map(() => {
            return {
                transform: toggle
                    // toggle === true -> initial position
          ? `translate3d(0px, 0px, 0px)`
                    // toggle === false -> move the envelopes to the left
          : `translate3d(-400px, 0px, 0px)`,
                opacity: toggle ?
                    // toggle === true -> full opacity
                    1
                    // toggle === false -> full transparency
                    : 0
            }
        })
  )
  // ...
  // ...

    return (
        <>
            // ...
            // ...
        </>
    )
}

After creating the springs you are now ready to map over them! The springs variable is an array of so-called "animated values" which you pass to the style property of elements wrapped in animated.g from react-spring.

Let's see the code excerpt with comments!

import { useSprings } from 'react-spring'

function Icon() {
    // ...
    // ...

    const envelopes = [
    // ...
    // ...
  ];

    const springs = useSpring(
      // ...
      // ...
  )

    const animatedEnvelopes = springs.map((animatedStyle, index) => (
    // use `animated.g` instead of `g` as the `animatedStyle`
    // is a special react-spring flavour of the `style` property
    <animated.g
      key={index} // YOLO
      style={animatedStyle} // apply the animated style
    >
      {envelopes[index]}
    </animated.g>
  ));

    return (
        <>
            // ...
            // ...
            <svg>
                // ...
            // ...
                {animatedEnvelopes} // use `animatedEnvelopes` instead of `envelopes`
                // ...
                // ...
            </svg>
        </>
    )
}

That wraps up this section! You now have the envelopes moving as you press the "Toggle animation" button.

You can find all the code for this section in the CodeSandbox

How to Make the animation look good?

You can probably see that the animation we created doesn't really look so good.

There are at least 3 problems:

Problem 1: The Trajectory Is Too Short

The animation trajectory seems to be a bit too short. That's because you can't see the envelopes when they go past the viewBox of the svg.

Fortunately, the fix is quite easy. You just need to manually adjust the viewBox.

(The viewBox specifies what points are visible in the svg element. It's used like this: viewBox="x0 y0 width height" where x0 specifies the left-most point, y0 specifies the top-most point and width and height specify the width and height. 🙃)

We need to give the svg some extra space on the left, therefore adjust the viewBox from 0 0 733.51 728.97 to -200 0 933.51 728.97. (Change the first number to create some space on the left and the third number to not crop the right-hand part of the image).

Problem 2: Envelopes Don't Animate in a Natural Direction

Even though the envelopes are slightly rotated we only animate them in one direction (left-right). It would seem more natural to animate in two directions (left-right + top-bottom).

How to find out how much vertical movement we should add? You could either fine-tune the translate property manually or use a bit of trigonometry. Let's do the latter. 😉

First, let's find out what angle the envelopes are rotated at. You can use the devtools to find that.

So the rotation angle is around 83deg. And the horizontal part of the animation is 400px. We get the vertical part of the animation as: vertical = 400px * cos(83deg) which yields around 49px.

So change the translate3d(-400px, 0px, 0px) to translate3d(-400px, -49px, 0px) and you'll be good to go.

Problem 3: Envelopes don't animate individually

Envelopes animate as a group which doesn't really look natural. Creating a staggered effect would make the animation seem much more natural.

Fortunately, it's two lines of code in react-spring as we can specify delay for each animated value.

const springs = useSprings(
    envelopes.length,
    envelopes.map((_, i) => {
      return {
        // ...
        // ...
                // as we map over the envelopes, increase the delay
                // first envelope -> delay: 0ms
                // second envelope -> delay: 100ms
                // etc.
        delay: i * 100,
      };
    })
  );

(It's worth noting that you could also use the useTrail hook instead of useSpring with delay to create a staggered effect.)

Yay! 😲The animation now looks much better! You can find the source code in the CodeSandbox below:

How to Create More Advanced Animations?

This is just the beginning—animating the using the translate3d(...) property is quite similar in SVG and HTML. However, things get more tricky if you try to animate scale, rotate properties.

If you're interested, you can follow me here or/and check out the YouTube channel where I'll be posting the tutorials.

Blocking Fallback for getStaticPaths–New Next.js 10 feature

Tom Dohnal — Sun, 01 Nov 2020 10:22:58 +0000

Why was fallback: 'blocking' introduced?
How does fallback: 'blocking' work?
When (not) to use fallback: 'blocking'?

Why was `fallback: 'blocking'` introduced? 🤔🤔

When Vercel released the 9.3 version of their popular Next.js framework, two brand new data fetching methods were introduced: getStaticProps and getServerSideProps.

If you want to use getStaticProps with, for example, a detail page of a product (pages/products/[id].js) you use getStaticPaths along with getStaticProps to define which product IDs you want to generate the page for.

If, however, you have a large e-commerce site with 10,000 products, you wouldn't want to return the IDs of all products from the getStaticPaths as building 10,000 pages would take ages.

Instead, you might just return the IDs of the most popular products and use fallback: true in getStaticPaths.

If you then a product page of some obscure product that's not frequently visited (e. g. /products/43284) for the first time, you'd be presented with a loading screen 💻 before the page gets generated (and the product data is fetched in getStaticProps).

(If you don't want to fetch other products than you specified, use fallback: false and Next.js will return a 404 🛑 for those pages.)

Every subsequent visit will serve the page statically 🚀 as the page is built (and cached) on the first visit.

However, having to use the loading indicator during the first visit has some issues:

Some og:* crawlers (Facebook, Twitter, LinkedIn, ...) don't support JS and thus fail to fetch correct og:* tags for fallback: true pages
AMP pages 📲 don't work correctly with fallback: true as they get stuck loading. (https://github.com/vercel/next.js/issues/14256)

Therefore, the Next.js team introduced a third option for the fallback field: 'blocking'.

(See https://github.com/vercel/next.js/issues/15637)

How does `fallback: 'blocking'` work? 😲😲

If you're using fallback: true in your page, you have to use something like this in your code 😕:

const router = useRouter()

if (router.isFallback) {
    return <Loading />
}

return <ProductDetail product={product} />

This is for the case when the user visits a page with fallback: true for the first time (a page which has not yet been built and whose props from getStaticProps hasn't been fetched).

If, however, you use fallback: 'blocking' in getStaticPaths, you don't use the if (router.isFallback) check. That's because when the user visits a page with fallback: 'blocking' which has not yet been built, Next.js is first going to build the page and only after it's built it's going the send the response to the user's browser.

You can play ▶️ with the CodeSandbox below the see how fallback: false, fallback: true, and fallback: 'blocking' differ.

When (not) to use `fallback: 'blocking'`?

Generally, the Next.js team encourages you not to use it unless is necessary. Using fallback: 'blocking' doesn't help the SEO (as Google and other search engine crawlers run JS code and will wait for a fallback: true page to load). Using fallback: 'blocking' makes the user wait 🥱 without any response while the page is being built and it's better to use fallback: true and show a loading skeleton while the page is being built instead.

If, however, you're experiencing issues with OG tags, AMP, or something else due to the usage of fallback: true, feel free to switch to fallback: 'blocking' 🤗.

You can see the comparison between fallback: false, fallback: true, and fallback: blocking below: ⬇️⬇️⬇️

fallback: false

fallback: true

fallback: 'blocking'

SSR (Next.js) - part 2/2: IS IT EVEN WORTH IT? 💎

Tom Dohnal — Thu, 16 Apr 2020 21:09:28 +0000

Migrating to SSR (Next.js) - part 2/2: IS IT EVEN WORTH IT? 💎

In this article we'll explore the pros and cons of server-side rendering as opposed to "client-only" single-page apps (and statically generated sites). We'll go through the UX 📱, business 🧳, and product development 👩🏿‍💻perspectives. You'll learn when you should opt for server-side rendering, when statically generated sites are a better choice, and under which circumstances you'll be better off with a "basic" SPA.

What are the pros of SSR? 👍🏽

Improved UX/Speed 🏎

The first argument which favours using SSR is the improved page speed.

If you navigate to a single-page application in your browser, the browser will first fire a request to download the HTML and JavaScript, and only after the JavaScript is downloaded and evaluated, it can fire an additional request to fetch some data from your API. Meanwhile, the user is presented with a blank screen, spinner or skeleton 💀.

When you visit a website which uses SSR, the browser will fire a request, but, unlike with the SPAs, the response contains all you need -- JavaScript files, HTML content and your data. There are no spinners, skeletons -- no elements jumping around 🤸🏽‍♂️. The content is delivered faster and the time to the first paint improves.

However, like with every tool, it might be an overkill for your use-case. Think about if improving your page load by some hundreds of milliseconds is worth it. It might be crucial in for e-commerce sites (which are in an extremely competitive environment), but might be an overkill for application which are only usable after logging in

With the growing popularity of the JAM Stack, you can get similar benefits (even better) in terms of speed for pages which don't require to be highly dynamic -- blogs, marketing sites or even some e-commerce sites.

Better for SEO (controversial 🧐)

I've seen the SEO argument being used countless times, but frankly, I don't believe it is such a big deal all the time. Let's first clarify why some people claim it to be a big deal.

The way Google (and other) crawlers 🦎 (which are scraping your website to display it in the search results) has traditionally worked is following:
1) Visit a website
2) Read the HTML delivered from the server/CDN
3) Save it.

Problems arose as libraries like React or Vue came into existence. As described in the previous blog post, almost no HTML is received in the first response from the server/CDN. It's only after JavaScript gets executed that you can see some meaningful content.

And that's the root of the SEO problem -- crawlers would only see the one div or a spinner and wouldn't wait for the actual content to show up. Therefore, your page wouldn't get properly indexed. However, this is no longer the case with the Google crawler as it waits ⏳ for all the content to load up (including the one dynamically generated by JavaScript).

Where it might still be necessary is if you want to get a preview of your page when sharing to social media. But if this were your only concern, I think prerendering using a tool like react-snap might be a better solution. 💡

You may still get some SEO improvements by using SSR even for crawlers which wait until all the content loads up. Indirectly -- if the search ranking algorithm accounts for the page speed (which should improve when using SSR), your site should rank higher 📈 in the search results.

What are the cons of SSR? 👎🏻

The need for a server 🖱

As opposed to the "traditional" SPAs where you don't even need a server to run your code, you need a server to render the code on the server (it's called server side rendering after all...). What this means is that you have to pay 💰💰💰 for a server to execute your "front-end" code. If you already have a server, the resource consumption might go up.

What can you do about it? Well, think about if SSR is the right solution for your use-case. You might be better off leveraging JAM Stack or a traditional SPA. Or, with the new 9.3 Next.js release, you can easily combine SSR with static pages which prevents wasting 🗑 server resources.

It's harder for the development (sometimes) 😵

If you were to roll your own SSR solution, you might be surprised that it's not as straightforward as creating a "traditional" SPA. You have to take care of rendering the components to HTML, sending them to the browser, hydration, making sure that you can fetch the data both on the server and the client... 😿

Of course, if you use frameworks like Next.js or Nuxt.js, they abstract a lot of these pain points away so you don't have to worry about them 😌. However, for larger projects which want to start using SSR or which were using SSR before these frameworks existed, the migration process to such a framework might seem daunting and they need to implement SSR by themselves.

Summary

In this acricle, we explored which applications benefit from using SSR and what are the potential downsides. My personal view is that the need for SSR gradually decreases 📉. Especially, it's really easy to use statically generated sites with the newest edition of Next.js.

SSR (Next.js) - part 1/2: WHAT IS SSR AND HOW IT DIFFERS FROM OTHER APPROACHES?

Tom Dohnal — Thu, 02 Apr 2020 21:35:45 +0000

In this series of articles, I'm going to go through the what, why, and how of the migration process of our React web application 💻 to a server-side rendering solution. You'll learn what SSR is, how it differs from the "client-only" single-page applications and "regular" web apps, what are its pros and cons, and, finally, how to go about migrating an existing React app to an SSR solution (Next.js). (The concepts are the same for Vue apps (and Nuxt.js) or similar. 😉)

What SSR even is? 🤔

To fully understand what SSR is, we'll first explore the differences between how "client-only" single-page applications (SPAs) and "regular" web apps are delivered to the browser and presented to the user.

"Regular" web apps 🖥

Let's start with "regular" web apps. What I mean by this term is apps rendered on the server, usually using a language like PHP, Java ☕️, Ruby 💎, Node.js etc. and some templating language on top of HTML.

When you type in an address to this kind of an app or click a link pointing to it in your browser, the response of the app's server will contain all the HTML that you see in the browser.

You can check it yourself --- go to Wikipedia 📖 (it's built using PHP), right-click anywhere on the page and choose "View source code" 👀. You'll see the HTML response that your browser received from the server and it contains all the content that you see on the page.

"Client-only" SPAs ⚛️

On the opposite side of the spectrum 🌈, there are the "client-only" single-page apps. Those are for example applications bootstrapped with create-react-app or @vue/cli.

When you navigate to one of these pages, the response of the server (or CDN) will only contain one div element (+ maybe some meta tags or a loader). You might now be wondering -- does it mean that you will only be able to see one div on their screen? 😨 No, of course not. I didn't mention another important thing which gets fetched in the response. It is a script tag pointing to the JavaScript bundle. The moment the browser gets the response, the JavaScript engine kicks in 💥 and (using a library like React or Vue) builds the page for you (using a bunch of document.createElement(...) calls or similar).

An example of such an application is Netlify. When you visit its web app and view the source code, you'll see just a small number of div elements, script tags etc. The actual content you see on your screen is built dynamically using JavaScript (React ⚛︎ in this case).

Server-side rendered SPAs 🎶

Now that we have an understanding of what "regular" web apps and "client-only" SPAs are, we can proceed to server-side rendered SPAs. As you might have guessed, it is a mixture 🥣 of both approaches which tries to bring you the best of both of the worlds. Let's see how it works.

The TLDR that I like to use is as follows: It behaves as a "regular" web app on the first render and as a "client-only" SPA afterwards ⏩.

But what does it really mean? Well, if you visit such a website, your browser will receive a response which already contains all the HTML that is presented on that site. Just like with the "regular" web apps we talked about earlier. Then, the browser will execute the JavaScript code written in React, Vue or similar and start a process called hydration 💦. During this process, it will attach all your listeners (onClick etc in React or @click etc in Vue) on the HTML elements which were delivered to the browser. After the hydration process is completed, the page behaves like a fully interactive SPA.

An example of such a website is jobs.netflix.com (they use React with Next.js). When you go there, you don't see a spinner or a white screen but all the content appears instantly. Moreover, the whole page is fully interactive and the page transitions don't trigger a reload in the browser.

How can you make your application leverage server-side rendering? This topic will be covered in the subsequent blog post. (You can do it all in plain React/Vue and Node.js but it's waaay easier with libraries such as Next.js or Nuxt.js respectively)

Statically exported sites 🍓

The list of different ways to architecture and deliver a web application could not be complete without at least mentioning statically exported sites. They are oftentimes written using so-called JAM Stack (JavaScript + API + Markdown) and bootstrapped using tools like Next.js, Gatsby.js, or Nuxt.js.

How do they differ from all the other approaches? Well, with these sites, all the HTML is delivered to the browser during the first render, just like with "regular" web apps or "server-rendered" SPAs. What's different is that there is no server running, creating these files on every request using a templating tool and sending them to the browser. Instead, you generate all the files at the build time 🛠, put them on the CDN and have them delivered right to your users' browsers. Basically, it's autogenerating HTML files. 😊

Conclusion ✍️

I hope I managed to shed some light on what SSR is as well as describe some of the other approaches for delivering web apps to the browsers. There is no finite list of the "patterns" and there are always new ones emerging.

Of course, every application is different and there are pros and cons for each approach. You should always choose what suits 👔 your needs.

In the next article, we're going to have a look at the pros and cons of using server-side rendering.

DEV Community: Tom Dohnal

TypeScript `Satisfies` keyword—New TypeScript 4.9 feature

The problem

satisfies to the rescue

Source code

Creating Animated Gradient Texts (pure HTML and CSS!)

Creating gradient text (w/o animation)

Animating the gradient

Animating white background

Source code

TypeScript ANY vs UNKNOWN—A Deep Dive

TLDR;

Table of Contents

The any Type

The unknown Type

Type narrowing with unknown

Use Cases for any and unknown Types

Migrating to TypeScript (from JavaScript)

Functions with unknown arguments

Custom Checkbox in React (Animated and Accessible)

How NOT to create a custom checkbox?

How to create a custom checkbox?

Styling Our Custom Checkbox

Animating Checkbox using React Spring

Animating the Checkmark

React SVG Animation (with React Spring) #4

Table of Contents

How Does the Animation Work in Theory?

How to Prepare the SVG for the Animation? (optional)

How to Morph SVG Paths Using React Spring?

Animating the Emoji Mouth

Animating the Emoji Eyes

Bonus: Animating SVG Paths with a Different Number of Points

How Do Custom Interpolators Work?

Let's Dive Into the Code

React SVG Animation (with React Spring) #3

Table of Contents

How to prepare the SVG for the animation?

How we're going to build the animation?

How to animates lines in SVG?

Animating path in React Spring

How to create a re-usable animation hook?

Final touches

React SVG Animation (with React Spring) #2

Table of Contents

How to Prepare the SVG for Animation?

Why the "Naive" Approach Does NOT Work?

How Does transform-origin Work in SVG?

Final touches

Add staggered effect

Add wobbly effect

Bonus: How to do this in Framer motion and GSAP?

TwitterFOMO—Open-Source Website Showing Most Liked Tweets in WebDev

React SVG Animation (with React Spring) #1

Table of Contents

How to Find an SVG to Animate?

How to Include an SVG in React?

How to Prepare the SVG for Animation?

How to Animate the SVG Elements?

How to Make the animation look good?

Problem 1: The Trajectory Is Too Short

Problem 2: Envelopes Don't Animate in a Natural Direction

Problem 3: Envelopes don't animate individually

How to Create More Advanced Animations?

Blocking Fallback for getStaticPaths–New Next.js 10 feature

Table Of Contents

Why was fallback: 'blocking' introduced? 🤔🤔

How does fallback: 'blocking' work? 😲😲

When (not) to use fallback: 'blocking'?

SSR (Next.js) - part 2/2: IS IT EVEN WORTH IT? 💎

Migrating to SSR (Next.js) - part 2/2: IS IT EVEN WORTH IT? 💎

What are the pros of SSR? 👍🏽

Improved UX/Speed 🏎

Better for SEO (controversial 🧐)

What are the cons of SSR? 👎🏻

The need for a server 🖱

It's harder for the development (sometimes) 😵

Summary

SSR (Next.js) - part 1/2: WHAT IS SSR AND HOW IT DIFFERS FROM OTHER APPROACHES?

What SSR even is? 🤔

`satisfies` to the rescue

The `any` Type

The `unknown` Type

Type narrowing with `unknown`

Use Cases for `any` and `unknown` Types

Animating `path` in React Spring

How Does `transform-origin` Work in SVG?

Why was `fallback: 'blocking'` introduced? 🤔🤔

How does `fallback: 'blocking'` work? 😲😲

When (not) to use `fallback: 'blocking'`?