DEV Community: Nikola Đuza

A Guide to Handling Errors in Preact

Nikola Đuza — Wed, 10 May 2023 09:48:19 +0000

To err is human. It happens all the time. If we don't account for errors on our websites, then our users will get an awful browsing experience. That's why it is better to plan for errors.

In today's post, we'll go through different ways of handling errors in Preact applications.

Let's get going!

Catching Rendering Errors in Preact

Since Preact is a lightweight React alternative, similar rules to the React world also apply here. You can't use the classic try...catch method of resolving errors while rendering because it's meant to handle imperative code.

But what is a typical rendering error, you're probably asking? Imagine a component like this:

import { h } from "preact";

const CrashableComponent = (props) => {
  return <>{props.iDontExist.meNeither}</>;
};

export default CrashableComponent;

Trying to render CrashableComponent on its own will break the page, leaving the user stranded. We also get an error in the browser console like this one:

So the classic try...catch method won't do us any good here. What will do the job and ensure the page is still usable when an error like this happens? To properly handle rendering errors in Preact, you can use these two approaches:

componentDidCatch
useErrorBoundary hook

We'll go through both in the following sections.

1. Catch Rendering Errors Using `componentDidCatch`

One way to handle errors is to create a class component that implements the componentDidCatch lifecycle method. It can look something like this:

import { h, Component } from "preact";

class Catcher extends Component {
  constructor() {
    super();
    this.state = { errored: false, error: null };
  }

  componentDidCatch(error) {
    this.setState({ errored: true, error });
  }

  render(props, state) {
    if (state.errored) {
      return (
        <>
          <h1>Oh no! I am a Catcher</h1>
          <p>Listen up, something went badly wrong 😭</p>
          <p>Here's the error message: {state.error.message}</p>
        </>
      );
    }

    return props.children;
  }
}

export default Catcher;

Then, we need to wrap our problematic component (or components) with the Catcher component, like so:

<Catcher>
  <CrashableComponent />
</Catcher>

Now, when we render the page, it will work and show the fallback code we defined in the Catcher component:

Error handling using componentDidCatch will work for any error in the child components. Some folks use a global error catcher that wraps most of the application as a root or near-root component.

What is great about this approach is that you can write any logic you want in componentDidCatch. It's a good idea to push the error to an error-tracking service like AppSignal. Here's an example:

componentDidCatch(error) {
  appsignal.sendError(error)
}

Now let's see how we can handle rendering errors in Preact with the useErrorBoundary hook.

2. `useErrorBoundary` Hook to Catch Rendering Errors

Preact exports a hook you can use to catch and easily retry an error. The hook is called useErrorBoundary, and can go within a component:

const [error, resetError] = useErrorBoundary();

To better illustrate this, let's create a functional component in Preact that handles errors for us:

import { h } from "preact";
import { useErrorBoundary } from "preact/hooks";

const CatcherWithHook = (props) => {
  const [error, resetError] = useErrorBoundary();

  if (error) {
    return (
      <>
        <h1>Oh no! I am a CatcherWithHook</h1>
        <p>Something went badly wrong and useErrorBoundary was used 😭</p>
        <p>Here's the error message: {error.message}</p>

        <button onClick={resetError}>Try again</button>
      </>
    );
  }

  return props.children;
};

export default CatcherWithHook;

We get the CatcherWithHook component, which is leaner than the original Catcher with the componentDidCatch implementation. Also, using the useErrorBoundary is more convenient because it takes care of the resetError part for you. With componentDidCatch, you have to take care of and reset the state manually.

To make sure errors are caught, we need to wrap the problematic code with the new component we've made:

<CatcherWithHook>
  <CrashableComponent />
</CatcherWithHook>

Now, when we render the page, it will show a fallback message and a button to retry the rendering, like so:

The same rule applies here — any rendering error in a child component of CatcherWithHook will be caught, and a fallback UI will be shown.

An important thing to note is that you can leverage an optional callback for monitoring purposes and pass that as the first argument to useErrorBoundary. So if you want to report the error to a service like AppSignal, here's how to do it:

const [error] = useErrorBoundary((error) => appsignal.sendError(error));

Awesome - we covered all of Preact's features for handling errors! But we have to be aware that componentDidCatch and useErrorBoundary won't catch all errors. They do not catch errors for:

Event handlers
Asynchronous code (e.g., setTimeout or requestAnimationFrame callbacks)
Errors that are thrown in the error boundary itself (rather than its children)

You still need to use the try...catch statement for these cases. So let's go ahead and show how you can do that.

Preact Error Catching in Event Handlers

As mentioned before, tools like componentDidCatch and useErrorBoundary can't help us with errors in event handlers. For those scenarios, we should go back to the old-fashioned try...catch block:

import { h } from "preact";
import { useState } from "preact/hooks";

const CrashIfClicked = () => {
  const [error, setError] = useState(null);

  if (error) {
    return (
      <>
        <p>An error happened, sorry!</p>
        <button onClick={() => setError(null)}>Try again</button>
      </>
    );
  }

  return (
    <>
      <p>This is a component that will crash the app.</p>

      <button
        onClick={() => {
          try {
            throw new Error("Crash!");
          } catch (e) {
            setError(e);
          }
        }}
      >
        Crash!
      </button>
    </>
  );
};

export default CrashIfClicked;

If we try to render this crashable button and interact with it, this will happen.

A similar thing happens with errors in setTimeout calls.

Preact Error Catching in `setTimeout` Calls

Imagine a similar component, but it has a setTimeout call in the event handler. Here it is:

import { h } from "preact";
import { useState } from "preact/hooks";

const CrashAfterAWhile = () => {
  const [error, setError] = useState(null);

  if (error) {
    return (
      <>
        <p>An error happened, sorry!</p>
        <button onClick={() => setError(null)}>Try again</button>
      </>
    );
  }

  return (
    <>
      <p>
        This is a component that will crash after 1 second within clicking the
        button.
      </p>

      <button
        onClick={() => {
          setTimeout(() => {
            try {
              throw new Error("I crashed after 1 second!");
            } catch (e) {
              setError(e);
            }
          }, 1000);
        }}
      >
        Crash after 1 second!
      </button>
    </>
  );
};

export default CrashAfterAWhile;

When we interact with the button, it will throw an error after 1000 milliseconds. Then, we will catch the error and show a fallback message. Here's how it looks.

That's nice and dandy! Our app is catching errors and showing messages and retry buttons to our users instead of blank screens.

There's also one other way to handle errors — by using AppSignal's Preact integration.

Tracking Errors in Preact with AppSignal

AppSignal has a @appsignal/preact package that requires Preact 10.0.0 or higher. You can add it to your project with these commands:

yarn add @appsignal/javascript @appsignal/preact
npm install --save @appsignal/javascript @appsignal/preact

Then in the code, you can use the ErrorBoundary provided by @appsignal/preact like so:

import { h, Component } from "preact";
import Appsignal from "@appsignal/javascript";

import { ErrorBoundary } from "@appsignal/preact";

export const appsignal = new Appsignal({
  key: "YOUR FRONTEND API KEY",
});

const FallbackComponent = ({ error }) => (
  <>
    <p>Uh oh! There was an error caught by AppSignal's ErrorBoundary :(</p>
    <p>Here's the error: {error.message}</p>
  </>
);

class AppSignalCatcher extends Component {
  render(props) {
    return (
      <ErrorBoundary
        instance={appsignal}
        tags={{ tag: "value" }}
        fallback={(error) => <FallbackComponent error={error} />}
      >
        {props.children}
      </ErrorBoundary>
    );
  }
}

export default AppSignalCatcher;

To make sure errors are caught, we need to wrap the child components with the new component we've made:

<AppSignalCatcher>
  <CrashableComponent />
</AppSignalCatcher>

Then we should see the fallback errors message in our app like so:

Here's an example of how this error looks in AppSignal:

Using ErrorBoundary provided by AppSignal is great because you can:

Catch rendering errors
Show a fallback UI for users
Report any mishaps to AppSignal so they can be tracked

Wrapping Up

Thanks for reading this blog post about handling errors in Preact. Check out this GitHub repo for all the code, with examples.

In summary, Preact features like the componentDidCatch lifecycle method and useReactBoundary hook are great for catching errors in declarative code (e.g., inside their child component tree).

For other cases, you need to use a try...catch statement (e.g., async calls like setTimeout, event handlers, and errors thrown in the error boundary itself).

That's all, folks. Thanks for reading, and catch you in the next one!

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

Adding custom HTML and CSS to GitHub README

Nikola Đuza — Tue, 13 Dec 2022 00:00:00 +0000

Lucas Kapla on Unsplash

Are you tired of the same old, same old personal GitHub profile README? Or are you just looking for inspiration on what to do with your own? Great, you find a perfect post that will show how you can go above and beyond to what’s offered when styling your personal README.

GitHub Profile README

Before we start, what is a GitHub profile README at all?

As of July 2020, GitHub allows you to create a repository with the same name as your username and use its README to add some personality to your page.

You’ve probably seen a lot of these with a lot of data in them. Some of them are neat looking. Some of them are full of information. But almost all of them consist of:

Intro about the user and their career orientation
Possibly some programming languages they know or use
Then you can find a bunch of “add-ons” or “feeds” of some sorts
- You can connect your GitHub README with Spotify, your blog, or almost anything that has an RSS feed and then show it on the README
- You can show your GitHub stats - PRs merged, commits pushed, your GitHub contributions, contribution streaks etc.
- Some of them even have GIFs, images, and so on.

But today, I will show you something else.

I will show you how to add any HTML page you want and “embed” it inside the README. We’ll achieve this by adding custom HTML and CSS inside an SVG file.

Custom CSS and HTML in an SVG

GitHub supports adding HTML in Markdown, but it is pretty aggressive when removing HTML that can be potentially dangerous to users. Things like scripts, iframes, and similar will get removed or “silenced” to avoid malicious content from being served to users.

Luckily, there’s one way to sneak in some HTML (or a web page) inside the README. You can do it via SVG and foreignObject SVG element. Let’s see how to do it.

First, create SVG file in your favorite editor like hello.svg:

<svg fill="none" viewBox="0 0 600 300" width="600" height="300" xmlns="http://www.w3.org/2000/svg">
  <foreignObject width="100%" height="100%">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <style>
        .container {
          display: flex;
          width: 100%;
          height: 300px;
          background-color: black;
          color: white;
        }
      </style>

      <div class="container">
        <h1>Hi there, my name is Nikola 👋</h1>
      </div>
    </div>
  </foreignObject>
</svg>

Awesome, if you open it, it should look like this:

Pretty basic, nothing too fancy. What’s important to note here is that it’s possible to add CSS and HTML inside an SVG, and it will work nicely. Also, notice thestyle block. Right now, it only sets the background color. Come on, let’s push it further.

<svg fill="none" viewBox="0 0 600 300" width="600" height="300" xmlns="http://www.w3.org/2000/svg">
  <foreignObject width="100%" height="100%">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <style>
        @keyframes hi {
            0% { transform: rotate( 0.0deg) }
           10% { transform: rotate(14.0deg) }
           20% { transform: rotate(-8.0deg) }
           30% { transform: rotate(14.0deg) }
           40% { transform: rotate(-4.0deg) }
           50% { transform: rotate(10.0deg) }
           60% { transform: rotate( 0.0deg) }
          100% { transform: rotate( 0.0deg) }
        }

        .container {
          background-color: black;

          width: 100%;
          height: 300px;

          display: flex;
          justify-content: center;
          align-items: center;
          color: white;

          font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
        }

        .hi {
          animation: hi 1.5s linear -0.5s infinite;
          display: inline-block;
          transform-origin: 70% 70%;
        }

        @media (prefers-reduced-motion) {
          .hi {
            animation: none;
          }
        }
      </style>

      <div class="container">
        <h1>Hi there, my name is Nikola <div class="hi">👋</div></h1>
      </div>
    </div>
  </foreignObject>
</svg>

Here’s how it should look:

The new changes add a bit of style to the whole image. The text is centered and the font changed. Also, the emoji hand is waving to us. We also used the prefers-reduced-motion CSS rule to turn off animations in case users prefer it that way. So, if do not see the animations inside images, make sure your accessibility options allow motion or animations. Here’s a guide on how to toggle motion/animations on a system level.

Great, let’s make our SVG even fancier.

<svg fill="none" viewBox="0 0 600 300" width="600" height="300" xmlns="http://www.w3.org/2000/svg">
  <foreignObject width="100%" height="100%">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <style>
        @keyframes hi {
            0% { transform: rotate( 0.0deg) }
           10% { transform: rotate(14.0deg) }
           20% { transform: rotate(-8.0deg) }
           30% { transform: rotate(14.0deg) }
           40% { transform: rotate(-4.0deg) }
           50% { transform: rotate(10.0deg) }
           60% { transform: rotate( 0.0deg) }
          100% { transform: rotate( 0.0deg) }
        }

        @keyframes gradient {
          0% {
            background-position: 0% 50%;
          }
          50% {
            background-position: 100% 50%;
          }
          100% {
            background-position: 0% 50%;
          }
        }

        .container {
          background: linear-gradient(-45deg, #ee7752, #e73c7e, #23a6d5, #23d5ab);
          background-size: 400% 400%;
          animation: gradient 15s ease infinite;

          width: 100%;
          height: 300px;

          display: flex;
          justify-content: center;
          align-items: center;
          color: white;

          font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
        }

        .hi {
          animation: hi 1.5s linear -0.5s infinite;
          display: inline-block;
          transform-origin: 70% 70%;
        }

        @media (prefers-reduced-motion) {
          .container {
            animation: none;
          }

          .hi {
            animation: none;
          }
        }
      </style>

      <div class="container">
        <h1>Hi there, my name is Nikola <div class="hi">👋</div></h1>
      </div>
    </div>
  </foreignObject>
</svg>

Let’s see what we did:

Now, the image has its background animated. Almost ready to be showcased on a GitHub README. Let’s take it a step further. We are going to use the prefers-color-scheme CSS rule to support light and dark modes. This is how to do it:

<svg fill="none" viewBox="0 0 600 300" width="600" height="300" xmlns="http://www.w3.org/2000/svg">
  <foreignObject width="100%" height="100%">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <style>
        @keyframes hi {
            0% { transform: rotate( 0.0deg) }
           10% { transform: rotate(14.0deg) }
           20% { transform: rotate(-8.0deg) }
           30% { transform: rotate(14.0deg) }
           40% { transform: rotate(-4.0deg) }
           50% { transform: rotate(10.0deg) }
           60% { transform: rotate( 0.0deg) }
          100% { transform: rotate( 0.0deg) }
        }

        @keyframes gradient {
          0% {
            background-position: 0% 50%;
          }
          50% {
            background-position: 100% 50%;
          }
          100% {
            background-position: 0% 50%;
          }
        }

        .container {
          --color-main: #5452ee;
          --color-primary: #e73c7e;
          --color-secondary: #23a6d5;
          --color-tertiary: #ffff;

          background: linear-gradient(-45deg, var(--color-main), var(--color-primary), var(--color-secondary), var(--color-tertiary));
          background-size: 400% 400%;
          animation: gradient 15s ease infinite;

          width: 100%;
          height: 300px;

          display: flex;
          justify-content: center;
          align-items: center;
          color: white;

          font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
        }

        .hi {
          animation: hi 1.5s linear -0.5s infinite;
          display: inline-block;
          transform-origin: 70% 70%;
        }

        @media (prefers-color-scheme: light) {
          .container {
            --color-main: #F15BB5;
            --color-primary: #24b0ef;
            --color-secondary: #4526f6;
            --color-tertiary: #f6f645;
          }
        }

        @media (prefers-reduced-motion) {
          .container {
            animation: none;
          }

          .hi {
            animation: none;
          }
        }
      </style>

      <div class="container">
        <h1>Hi there, my name is Nikola <div class="hi">👋</div></h1>
      </div>
    </div>
  </foreignObject>
</svgg

Here’s the final version (pro tip: toggle your system’s color scheme to see the gradient change):

And here’s how it changes depending on the color scheme:

What we did is the following:

.container {
  --color-main: #ef476f;
  --color-primary: #ffd166;
  --color-secondary: #06d6a0;
  --color-tertiary: #118ab2;

  background: linear-gradient(
    -45deg,
    var(--color-main),
    var(--color-primary),
    var(--color-secondary),
    var(--color-tertiary)
  );

  //...
}

@media (prefers-color-scheme: light) {
  .container {
    --color-main: #ffc8dd;
    --color-primary: #ffafcc;
    --color-secondary: #bde0fe;
    --color-tertiary: #a2d2ff;
  }
}

Now, when a user has a light variant of a color scheme, another set of colors will get applied to the gradient.

You must be asking now - how do I render the newly created SVG? Glad you asked - let’s jump into the next section where we will learn that.

Render SVG inside GitHub README

You can use the standard Markdown syntax for rendering an image like ![Image alt text](hello-animated.svg).

To show an SVG image in full width of a README on GitHub, you can render it like so:

<div style="width: 100%;">
  <img src="animated.svg" style="width: 100%;" alt="Click to see the source">
</div>

This makes sure that the width of an SVG is 100% of the width of the Markdown file so it shows up nicely.

Render local README files before pushing to GitHub

To be sure everything is working properly before you push to GitHub, you can use a cool tool called grip. The grip is a CLI tool written in Python and it uses the GitHub API to render your Markdown files. I installed it quickly with brew install grip and you can run it by just typing grip inside the repo with .md files and then pressing enter. It will then run a server with your Markdown files.

I decided to use grip because I wanted to test these SVGs on my mobile phone on the local network. If you want to do that or you’re just interested in how to do it, I wrote a blog post on how to preview a localhost website on a mobile phone.

To be able to preview the README file on your mobile, I ran grip like so:

grip . 0.0.0.0

Now that we know how to preview README files without pushing them to GitHub, let’s see a breathing and living example in the wild.

Real-world example

I pimped out my GitHub profile in the same way we went through in the above sections. You can check it out below:

Here’s the link to my GitHub profile repo and the actual SVG file that is rendered there.

I also created another repo with all the SVGs that we built today, take a look here.

Sum up

We went through how to create a simple HTML and CSS inside SVG, to fully animate and change CSS rules based on the user’s color scheme. We also saw how to render the SVG file properly in the Markdown file on GitHub. You are now ready to pimp out your GitHub READMEs. Go crazy!

Thanks for joining and reading. I hope this helps and/or inspires you to create something.

Until the next one, cheers.

What's New in Next.js 13

Nikola Đuza — Wed, 09 Nov 2022 11:58:33 +0000

Version 13 of Next.js, a well-established React framework from the Vercel company, was released last week.

The announcement was made at the Next.js Conf and took the community by storm. Developers worldwide spread the news about the features and goodies announced live on October 25th.

Now, as the dust slowly settles, we can go through what's new in Next.js 13.

`app/` Directory in Next.js 13 (In Beta)

What better way to check out what's new than by building a simple app, right? Jump-start a new Next.js 13 project with this command:

npx create-next-app@latest --typescript

Note that --typescript is optional, you can omit it.

Alright, let's now jump into the layout features in Next.js 13.

Next.js always allowed you to simply create a file in your project and then have Next.js create a route based on it. This makes for a great developer experience. Now, Next.js 13 aims to improve routing and layouts by introducing the app directory to the root of your Next.js project.

This feature is still in beta, and it is entirely optional. You can keep your pages directory and have it coexist with the app directory - or just skip adding app dir at all.

One thing you have to do is tell Next you will use it by adding the following to next.config.js:

// next.config.js

const nextConfig = {
  // ...
  experimental: { appDir: true },
};

// ...

Then, you can create the app directory with a page.tsx file like so:

// app/page.tsx
// This file maps to the index route (/)
export default function Page() {
  return <h1>Hello, I am Page!</h1>;
}

Of course, if you have pages/index.tsx, you have to either rename or delete it. You'll have to make up your mind here, as you can't have both. When you deal with pages/index.tsx, the running Next.js server will create app/layout.tsx - how thoughtful, thanks, Next.js!

Your page app/page.tsx did not have a root layout, we created app/layout.tsx for you.

Now the app/layout.tsx has been created for us, let's look at layouts in Next.js.

Layouts in Next.js 13

Layouts in Next.js make it easier to extract shared code between multiple pages. layout.tsx accepts another layout or a page as a child. Here's how it looks:

// app/layout.tsx

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <head></head>
      <body>{children}</body>
    </html>
  );
}

Now, with app/page.tsx and app.layout.tsx in your project, you can rock and roll. To get a bit of styling, copy the boilerplate CSS from pages/globals.css to app/global.css. Then include it in app/layout.tsx like so:

import "./global.css";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <head></head>
      <body>{children}</body>
    </html>
  );
}

And then, when you run npm run dev and visit http://localhost:3000/ you should see something like this:

Of course, you can create another page like app/product/page.tsx with a layout for products - app/product/layout.tsx.

Let's see what else is new.

React Server Components

If you use Server Components in Next.js, you can reduce the amount of JavaScript sent to the client, enabling faster initial page loads.
We touched a bit on this subject when React 18 came out.

And what is great in Next.js 13 is that all components inside the app directory are React Server Components by default, including special files and colocated components (tests, styles, other components, etc.). That way, you are set up to achieve performance gains without doing any work or rewriting your components.

When a page is loaded, the Next.js and React runtime will load, which is cacheable and predictable in size. This runtime remains the same size as your application grows. Additional JavaScript will only be added as client-side interactivity is needed in your application through the use of Client Components.

You can use Client Components by specifying a "use client" directive at the top of the component meant for the client. Let's create a new file under app/counter/page.tsx:

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked the Count++ button {count} times</p>
      <button onClick={() => setCount(count + 1)}>Count++</button>
    </div>
  );
}

You should add "use client" when:

using useState or useEffect client hooks from React
you depend on certain browser APIs
you want to add certain event listeners

In other cases, when you don't need things from the client, it is best to leave components as they are and let them be rendered as Server Components by Next.js. That will help ensure the smallest amount of client-side JavaScript code.

If you decide to utilize useState or any other client hooks, Next.js will fail to render and show an error like so:

I wonder why "use client" does not happen automatically. But anyway, there you go - it is hard to make a mistake because Next.js really made the developer experience great.

On that note, there's an even greater goodie when it comes to developer experience: data fetching and showing loading states. Let's jump into it!

Streaming and Data Fetching

In Next.js 13, you can now easily stream parts of the UI to the client with React Suspense. For example, if data fetching is waiting to complete, you can show a loading state to the user. Then when the data fetching is complete, new info will be streamed to the page in place of the previously shown loading state.

The API to fetch data has been simplified, and the old APIs getServerSideProps, getStaticProps, and getInitialProps are not supported in the new app directory.

It is recommended that you fetch data inside Server Components (the ones we touched on in the above section). That way, fetching and rendering happen in the same environment, reducing the back and forth between client and server and, ultimately, the work done in the browser.

You can fetch data anywhere in the app directory, but because of the way Streaming and Suspense work in React, you should adopt a new mental model when fetching data. Namely, you should fetch data directly in the components that use it, even if you need to request the data in multiple components. Behind the scenes, React and Next.js will cache and dedupe requests to avoid the same data being fetched more than once.

Streaming and Fetching in Server Components

What's great about the new Next.js release is that you can show a loading state simply by creating a loading.tsx file. In this example, we made app/dashboard/loading.tsx like so:

export default function Loading() {
  return <p>Loading the Dashboard...</p>;
}

And in app/dashboard/page.tsx we have the following code:

async function getData() {
  // You would usually fetch data from an API here.
  // const res = await fetch("https://api.github.com/");

  // But, here we just wait for 3 seconds.
  await new Promise((res) => setTimeout(res, 3000));

  // You would usually return data from an API here.
  // return res.json();
  return "Dashboard data";
}

export default async function Page() {
  const name = await getData();

  return <p>🤩 Hello {name}!</p>;
}

If we try to load http://localhost:3000/dashboard, there will first be a loading screen and then the dashboard will show up.

You can dig deeper and use React's Suspense to further break down the UI. You can make sure the layout renders while a specific component in the layout waits for data to be fetched.

Being able to utilize async/await in Server Components is great and is part of React's RFC to add first-class support for Promises. It allows us to do what we just did in app/dashboard/page.tsx:

export default async function Page() {
  const name = await getData();

  return <p>🤩 Hello {name}!</p>;
}

But we can't use async/await in this manner in Client Components. Let's see how we can fetch data there in the next section.

Streaming and Fetching in Client Components

The example above showed how to display a loading screen while data is prepared for rendering in Server Components. But if you want to do a similar thing on the client, you have to utilize the use hook.

Let's change our example to make sure it's rendered properly as a Client Component. We will create app/dashboard-client/loading.tsx - it will be the same, but with different copy:

export default function Loading() {
  return <p>Loading the Dashboard in Client Components...</p>;
}

Then use the app/dashboard-client/page.tsx with the use hook from React like so:

"use client";

import { use } from "react";

async function getData() {
  // You would usually fetch data from an API here.
  // const res = await fetch("https://api.github.com/");

  // But, here we just wait for 3 seconds.
  await new Promise((res) => setTimeout(res, 3000));

  // You would usually return data from an API here.
  // return res.json();
  return "Dashboard data in Client Components";
}

export default function Page() {
  const name = use(getData());

  return <p>🤩 Hello {name}!</p>;
}

Notice how we call use(getData()). This is because use is a new React function that accepts a promise and is conceptually similar to await. We need use because it handles the promise returned by a function in a way compatible with components, hooks, and Suspense. The use hook is a part of the React RFC we mentioned earlier.

If we visit http://localhost:3000/dashboard-client, we should see a similar thing as before. The loading state shows briefly until the actual dashboard appears.

Caching with Fetch

The fetch() function is a Web API that gets remote resources and returns a promise. React extends fetch to provide automatic request deduping, and Next.js extends the fetch options object so each request can set its own caching and revalidating.

So React and Next.js take the fetch browser API and put some sprinkles on top. Now in Next.js 13, you can specify how you want requests to be cached (or if you don't want them to be cached at all):

// This request should be cached until manually invalidated.
// Similar to `getStaticProps` from Next.js 12.
// `force-cache` is the default and can be omitted for brevity.
// This is called static data in Next.js world
fetch(URL, { cache: "force-cache" });

// This request should be refetched on every request.
// Similar to `getServerSideProps`.
// Here we have loading of dynamic data in Next.js world.
fetch(URL, { cache: "no-store" });

// This request should be cached with a lifetime of 10 seconds.
// Similar to `getStaticProps` with the `revalidate` option.
fetch(URL, { next: { revalidate: 10 } });

And that's it as far as streaming and fetching goes. You can read more about it in Next.js' official docs here.

Now let's go into something which drew a lot of attention from the frontend world - a 700 times faster bundler, Turbopack.

Turbopack

Turbopack is branded as an "up to 700x faster Rust-based Webpack replacement". It even features a small letter to the public from the Webpack creator himself - Tobias Koppers. Tobias is leading the initiative and the project, which can only mean good news for the whole frontend community.

Right now, you can use Turbopack with Next.js 13 if you run next dev --turbo (or, if you're running it via npm in the project we generated at the beginning - npm run dev --turbo).

It supports Server Components, TypeScript, JSX, CSS, and more. As the project is in alpha state, many of the features are not yet supported. We can only hope for a stable release to speed up projects across the world.

`next/image` Improvements

The new Image component in Next.js comes with less client-side JavaScript, is easier to style and configure, and more accessible (requiring alt tags by default).

In terms of code changes, the next/image import has been renamed to next/legacy/image, and the next/future/image import renamed to next/image. There's a codemod to help you migrate quickly.

If you were not using width and height on non-static images (or images without the fill property), you will now have to set them. The same goes with the alt prop, though it is not required and can be left as an empty string.

Here's a guide on migrating to the new next/image.

`@next/font`

The new @next/font lets you use Google Fonts (or any custom font) without sending any requests from the browser. CSS and font files are downloaded at build time with the rest of the static assets.

To try it out, you need to install the package:

npm install @next/font

Then, you can use it like this:

import { Montserrat } from "@next/font/google";

const montserrat = Montserrat();

// This file maps to the index route (/)
export default function Page() {
  return (
    <article>
      <h1>Hello, I am Page!</h1>

      <p className={montserrat.className}>I am using Montserrat font</p>
    </article>
  );
}

`next/link` Improvement

You no longer have to include the <a> tag when using next/link.

import Link from 'next/link'

// Next.js 12: `<a>` has to be nested otherwise, it's excluded
<Link href="/dashboard">
  <a>Dashboard</a>
</Link>

// Next.js 13: `<Link>` always renders `<a>`
<Link href="/dashboard">
  Dashboard
</Link>

There is also a codemod to help you remove any extra <a> tags you may have in your existing project.

Generating OG Images with `@vercel/og`

A new @vercel/og library allows you to generate open graph (OG) images. It's well known that OG images can increase the engagement rate for links you share.

Vercel and Next.js have been discussing this topic for some time, providing you with docs to generate OG images via functions. But now there is a new guide that shows how you can utilize the new Edge Runtime together with the @vercel/og library.

Middleware API Changes

Next.js 13 improves the Middleware feature. Vercel's Middleware is code that executes before a request is processed on a site. There, you can modify an incoming request and add some logic before the request is processed.

Now it is easier to set headers in the middleware. Plus, you can directly return a response from the middleware, without needing to rewrite or redirect. But for this, you need to enable the experimental.allowMiddlewareResponseBody configuration option inside next.config.js.

To get started, you need to have middleware.js or middleware.ts at the root of your Next.js project. We'll use the TypeScript version and show how you can set a header to an incoming request:

// middleware.ts

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  // Clone the request headers and set a new header
  // that will be sent to the server `header-for-the-server`
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set("header-for-the-server", "hello server");

  // You can also set request headers in NextResponse.rewrite
  const response = NextResponse.next({
    request: {
      // New request headers
      headers: requestHeaders,
    },
  });

  // Set a new response header that you can inspect in the browser
  // `header-for-the-client`
  response.headers.set("header-for-the-client", "hello client");
  return response;
}

You can do the same in the project we were using from the beginning and inspect the headers of http://localhost:3000/ in the browser. There, you should see the header-for-the-client header in the Network tab.

Telemetry

I am not sure if this was there before, but when I ran npm run dev (or next dev) after upgrading, I got this message:

Attention: Next.js now collects completely anonymous telemetry regarding usage.
This information is used to shape Next.js' roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://nextjs.org/telemetry

It might be that this is just the first time I noticed it, and I can't find written proof of when Next.js started collecting anonymous usage reports.

Anyway, you can easily opt-out by running:

npx next telemetry disable

You can also quickly check if this is disabled or enabled for you:

npx next telemetry status

In any case, I feel that collecting usage data should be optional and not turned on by default.

Wrapping Up: Next.js 13 Brings Great New Features

That's all, folks! We have gone through all the updates in Next.js 13. I hope this version is exciting for you. Jump in and explore the new features!

I pushed the code examples in this post into a GitHub repo. There's also a live demo you can play with.

You can check out the official Next.js announcement, which also covers breaking changes.

Thanks for reading, and see you in the next one!

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.

How to Preview localhost Website on Mobile Phone

Nikola Đuza — Sun, 02 Oct 2022 00:00:00 +0000

Photo by Maxim Ilyahov on Unsplash

Are you looking to preview your website on your mobile (or tablet) while developing it on your computer? Or vice-versa? Maybe you want to get a “real feel” of how the website works and looks directly on the device. Then, you’re in for a treat. Today, we’ll show how you can visit the website hosted on localhost directly from your mobile or tablet.

Step 1: Connect your device to the same network

If you have multiple WiFi networks, ensure your computer and device are on the same WiFi. This step is essential.

Step 2: Find your computer’s local IP address

Your computer has a public IP and a local IP address. We need a local IP address , IPv4, to be more precise. You must be asking - “How do I find my local IP address?“. Here’s how you can do it on different operating systems:

Mac OS

Open System Preferences -> Network
Next to the Status, you should see the IP address. It should write out - “WiFi is connected to YOUR_WIFI_NAME and has the IP address YOUR_LOCAL_IP.” See how it looks in the screenshot below:

The local IP address is underlined in red.

Linux

Run in your terminal hostname -I. Or, run ifconfig | grep "inet " | grep -v 127.0.0.1

Windows

Select Start > Settings > Network & internet > Wi-Fi and then select the Wi-Fi network you’re connected to.
Under Properties, look for your IP address listed next to IPv4 address.

Great, now that we got our computer’s local IP address, we need to run our app.

Step 3. Get the port number

If you’re running a Rails app, the port is usually 3000, and you can access your app in the http://localhost:3000.

💡 In my case, I had to bind the server to 0.0.0.0. I run a Gatsby website, so for me, it was gatsby develop --host 0.0.0.0, which runs the server that listens on the 8000 port.

Whatever way you run your server, make sure to use the PORT from http://localhost:PORT - where the server listens for incoming requests.

Step 4: Open your other device’s browser

On your phone or tablet, open your browser of choice and type in http://YOUR_LOCAL_IP:PORT - which in my case was http://192.168.1.30:8000.

If you’re running a server on http://localhost:3000, and your IP is 192.168.1.10, then you need to visit http://192.168.1.10:3000 on your mobile or tablet.

That is it

You can now browse your website directly from your other device while you develop on the computer. How neat!

Now, you can test mobile and tablet views on real devices. That is if you need to do so.

Thanks for following along, and catch you in the next one.

How to Handle Errors in React

Nikola Đuza — Wed, 22 Jun 2022 11:28:28 +0000

Let's face it. Nobody wants to see a broken, empty page while surfing the web. It leaves you stranded and confused. You don't know what happened or what caused it, leaving you with a bad impression of the website.

It is often better to communicate the error and let the user continue to use the app. The user will get less of a bad impression and can continue to use its features.

In today's post, we'll go through different ways to handle errors in React applications.

The Classic 'Try and Catch' Method in React

If you've used JavaScript, you've probably had to write a 'try and catch' statement. To make sure we're on board with what it is, here's one:

try {
  somethingBadMightHappen();
} catch (error) {
  console.error("Something bad happened");
  console.error(error);
}

It is a great tool to catch misbehaving code and ensure our app doesn't blow up into smithereens. To be more realistic and close to the React world as possible, let's see an example of how you'd use this in your app:

const fetchData = async () => {
  try {
    return await fetch("https://some-url-that-might-fail.com");
  } catch (error) {
    console.error(error); // You might send an exception to your error tracker like AppSignal
    return error;
  }
};

When doing network calls in React, you'd usually use the try...catch statement. But why? Unfortunately, try...catch only works on imperative code. It does not work on declarative code like the JSX we are writing in our components. So that is why you don't see a massive try...catch wrapping our whole app. It just won't work.

So, what do we do? Glad you asked. In React 16, a new concept got introduced — React Error Boundaries. Let's dig into what they are.

React Error Boundaries

Before we get into error boundaries, let us first see why they are necessary. Imagine you had a component like this:

const CrashableComponent = (props) => {
  return <span>{props.iDontExist.prop}</span>;
};

export default CrashableComponent;

If you try to render this component somewhere, you'll get an error like this one:

Not only that, the whole page will be blank, and the user won't be able to do or see anything. But what happened? We tried to access a property iDontExist.prop, which doesn't exist (we don't pass it to the component). This is a banal example, but it shows that we cannot catch these errors with the try...catch statement.

This whole experiment brings us to error boundaries. Error boundaries are React components that catch JavaScript errors anywhere in their child component tree. Then, they log those caught errors and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them.

An error boundary is a class component that defines either (or both) of the lifecycle methods static getDerivedStateFromError() or componentDidCatch().
static getDerivedStateFromError() renders a fallback UI after an error has been thrown. componentDidCatch() can log error information to your service provider (like AppSignal) or to a browser console.

Here's an example of how information about a React error looks in AppSignal's 'issue list':

Let's see a typical error boundary component:

import { Component } from "react";

class ErrorBoundary extends Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return {
      hasError: true,
      error,
    };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service like AppSignal
    // logErrorToMyService(error, errorInfo);
  }

  render() {
    const { hasError, error } = this.state;

    if (hasError) {
      // You can render any custom fallback UI
      return (
        <div>
          <p>Something went wrong 😭</p>

          {error.message && <span>Here's the error: {error.message}</span>}
        </div>
      );
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

We can use ErrorBoundary like so:

<ErrorBoundary>
  <CrashableComponent />
</ErrorBoundary>

Now, when we open our app, we will get a working app with the following:

That is precisely what we want. We want our app to remain functional when an error occurs. But we also want to inform the user (and our error tracking service) about the error.

Beware that using an error boundary is not a silver bullet. Error boundaries do not catch errors for:

Event handlers
Asynchronous code (e.g. setTimeout or requestAnimationFrame callbacks)
Server-side rendering
Errors that are thrown in the error boundary itself (rather than its children)

You still need to use the try...catch statement for these fellas. So, let's go ahead and show how you can do that.

Error Catching in Event Handlers

As mentioned before, error boundaries can't help us when an error is thrown inside an event handler. Let's see how we can handle those. Below is a small button component that throws an error when you click it:

import { useState } from "react";

const CrashableButton = () => {
  const [error, setError] = useState(null);

  const handleClick = () => {
    try {
      throw Error("Oh no :(");
    } catch (error) {
      setError(error);
    }
  };

  if (error) {
    return <span>Caught an error.</span>;
  }

  return <button onClick={handleClick}>Click Me To Throw Error</button>;
};

export default CrashableButton;

Notice that we have a try and catch block inside handleClick that ensures our error is caught. If you render the component and try to click it, this happens:

We have to do the same in other cases, like in setTimeout calls.

Error Catching in `setTimeout` Calls

Imagine we have a similar button component, but this one calls setTimeout when clicked. Here's how it looks:

import { useState } from "react";

const SetTimeoutButton = () => {
  const [error, setError] = useState(null);

  const handleClick = () => {
    setTimeout(() => {
      try {
        throw Error("Oh no, an error :(");
      } catch (error) {
        setError(error);
      }
    }, 1000);
  };

  if (error) {
    return <span>Caught a delayed error.</span>;
  }

  return (
    <button onClick={handleClick}>Click Me To Throw a Delayed Error</button>
  );
};

export default SetTimeoutButton;

After 1,000 milliseconds, the setTimeout callback will throw an error. Luckily, we wrap that callback logic in try...catch, and setError in the component. That way, no stack trace is shown in the browser console. Also, we communicate the error to the user. Here's how it looks in the app:

That is all well and good, as we got our app's pages up and running despite errors popping all over the place in the background. But is there an easier way to handle errors without writing custom error boundaries? You bet there is, and of course, it comes in the form of a JavaScript package. Let me introduce you to the react-error-boundary.

JavaScript's `react-error-boundary` Package

You can pop that library inside your package.json faster than ever with:

npm install --save react-error-boundary

Now, you're ready to use it. Remember the ErrorBoundary component we made? You can forget about it because this package exports its own. Here's how to use it:

import { ErrorBoundary } from "react-error-boundary";
import CrashableComponent from "./CrashableComponent";

const FancyDependencyErrorHandling = () => {
  return (
    <ErrorBoundary
      FallbackComponent={ErrorFallback}
      onError={(error) => {
        // You can also log the error to an error reporting service like AppSignal
        // logErrorToMyService(error, errorInfo);
        console.error(error);
      }}
    >
      <CrashableComponent />
    </ErrorBoundary>
  );
};

const ErrorFallback = ({ error }) => (
  <div>
    <p>Something went wrong 😭</p>

    {error.message && <span>Here's the error: {error.message}</span>}
  </div>
);

export default FancyDependencyErrorHandling;

In the example above, we render the same CrashableComponent, but this time, we use the ErrorBoundary component from the react-error-boundary library. It does the same thing as our custom one, except that it receives the FallbackComponent prop plus the onError function handler. The result is the same as we had with our custom ErrorBoundary component, except you don't have to worry about maintaining it since you're using an external package.

One great thing about this package is that you can easily wrap your function components into a withErrorBoundary making it a higher-order component (HOC). Here's how that looks:

import { withErrorBoundary } from "react-error-boundary";

const CrashableComponent = (props) => {
  return <span>{props.iDontExist.prop}</span>;
};

export default withErrorBoundary(CrashableComponent, {
  FallbackComponent: () => <span>Oh no :(</span>,
});

Nice, you're good to go now to capture all those errors bugging you.

But maybe you don't want another dependency in your project. Can you achieve it yourself? Of course you can. Let's see how it can be done.

Using Your Own React Boundaries

You can achieve a similar, if not the same, effect you get from react-error-boundary. We already showed a custom ErrorBoundary component, but let's improve it.

import { Component } from "react";

export default class ErrorBoundary extends Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return {
      hasError: true,
      error,
    };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service like AppSignal
    // logErrorToMyService(error, errorInfo);
  }

  render() {
    const { hasError, error } = this.state;

    if (hasError) {
      // You can render any custom fallback UI
      return <ErrorFallback error={error} />;
    }

    return this.props.children;
  }
}

const ErrorFallback = ({ error }) => (
  <div>
    <p>Something went wrong 😭</p>

    {error.message && <span>Here's the error: {error.message}</span>}
  </div>
);

const errorBoundary = (WrappedComponent) => {
  return class extends ErrorBoundary {
    render() {
      const { hasError, error } = this.state;

      if (hasError) {
        // You can render any custom fallback UI
        return <ErrorFallback error={error} />;
      }

      return <WrappedComponent {...this.props} />;
    }
  };
};

export { errorBoundary };

Now you get the ErrorBoundary and the HOC errorBoundary that you can use across your app. Extend and play around with it as much as you want. You can make them receive custom fallback components to customize how you recover from each error. You can also make them receive an onError prop and later call it inside componentDidCatch. The possibilities are endless.

But one thing is for sure — you didn't need that dependency after all. I bet writing your own error boundary will bring a sense of achievement, and you'll get to understand it better. Also, who knows what ideas you might get when you're trying to customize it.

Summing Up: Get Started with React Error Handling

Thanks for reading this blog post about handling errors in React. I hope you had as much fun reading and trying things out as I did writing it. You can find all the code, with examples, in the GitHub repo I created.

A quick rundown of the things we went through:

React Error boundaries are great for catching errors in declarative code (e.g., inside their child component tree).
For other cases, you need to use a try...catch statement (e.g., async calls like setTimeout, event handlers, server-side rendering, and errors thrown in the error boundary itself).
A library like react-error-boundary can help you write less code.
You can also run your own error boundary and customize it as much as you want.

That is all, folks. Thanks for tuning in, and catch you in the next one!

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.

What's new with React 18

Nikola Đuza — Wed, 20 Apr 2022 11:52:34 +0000

Some exciting new improvements have been launched with React 18. When React 18 was announced a year ago, the team promised a gradual adoption strategy. Now, a year later, this is exactly what they've done and you can upgrade your app to the newest version.

React 18 comes with a few breaking changes, depending on how you use it. But all in all, it also brings out-of-the-box performance improvements including batching more by default, which removes the need to manually batch updates in application or library code.

For some, this is music to their ears, others might need more convincing. So let's dive deeper into some of the most important new changes that Facebook's team has brought us.

Breaking Changes in React 18

What would a major release be without a breaking change? Well, this version of React is a bit different, and you will see why in a second. One of the changes you can make is to alter render to createRoot like so:

// Before
import { render } from "react-dom";

const container = document.getElementById("app");
render(<App tab="home" />, container);

// After
import { createRoot } from "react-dom/client";

const container = document.getElementById("app");
const root = createRoot(container);
root.render(<App tab="home" />);

createRoot enables concurrent features from React 18. If you don't use it, your app will behave like it's on React 17, and you won't get to experience sweet out-of-the-box optimization. So for now, you will see a deprecation notice if you're still using render instead of createRoot.

This is a good chance to experiment and see if the new concurrent features improve your production performance. You can run an experiment where one variant has render and the other uses createRoot. Also, you won't break your code by switching to the new API. You can gradually switch to createRoot without the possibility of breaking your app.

To ensure you migrate your app properly, try enabling strict mode. Strict mode will let you know what is happening with components in development, and it will print out any irregularities in the console. Enabling strict mode won't affect production builds. You can do it somewhere in your app like so:

import React from "react";
import { createRoot } from "react-dom/client";

function App() {
  return (
    <div>
      <Header />
      <React.StrictMode>
        <div>
          <Content />
          <SignUpForm />
        </div>
      </React.StrictMode>
      <Footer />
    </div>
  );
}

const container = document.getElementById("app");
const root = createRoot(container);
root.render(<App />);

Also, if you're using hydrate for server-side rendering with hydration, you can upgrade to hydrateRoot:

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

// After
import { hydrateRoot } from "react-dom/client";
const container = document.getElementById("app");
const root = hydrateRoot(container, <App tab="home" />);
// Unlike with createRoot, you don't need a separate root.render() call here.

And that's it as far as high-level features are concerned. You can take a look at other breaking changes in React 18.

Let's see what new goodies React 18 brings in the next section.

Automatic Batching in React 18

React 18 brings us automatic batching. It might sound confusing — you might ask: 'what batching?'. We'll go through it, don't worry. Let's take a look at an example:

// Before: only React events were batched
setTimeout(() => {
  setSize((oldSize) => oldSize + 1);
  setOpen((oldOpen) => !oldOpen);
  // React will render twice, once for each state update (no batching)
}, 1000);

// After: updates inside of timeouts, promises,
// native event handlers or any other event are batched
setTimeout(() => {
  setSize((oldSize) => oldSize + 1);
  setOpen((oldOpen) => !oldOpen);
  // React will only re-render once at the end (that is batching)
}, 1000);

Automatic batching means that React will now batch updates you make inside your components. Batching prevents unnecessary renders of your component.

In React 17, if you change the state of the component two times, the component will re-render two times. Now, in React 18, the two updates will be batched, and the component will render only once. And that's only if you're using createRoot instead of render. Take a look at the examples below:

✅ Demo: React 18 with createRoot batches, even outside event handlers! — notice one render per click in the console!
🟡 Demo: React 18 with legacy render keeps the old behavior — notice two renders per click in the console.

If automatic batching is not something you want in your component, you can always opt-out with flushSync. Let's go through an example:

import { flushSync } from "react-dom"; // Note: we are importing from react-dom, not react

function handleSubmit() {
  flushSync(() => {
    setSize((oldSize) => oldSize + 1);
  });

  // React has updated the DOM by now
  flushSync(() => {
    setOpen((oldOpen) => !oldOpen);
  });

  // React has updated the DOM by now
}

Calls to setCounter and setFlag will immediately try to update the DOM instead of being batched together.

This new feature alone can make a difference in how your app performs. And the coolest thing about it is that you only have to change the mounting point of your app to use createRoot.

Let's see what else there is in the new version.

Transitions

React 18 brings in a new API for transitions. A transition is a new concept in React to distinguish between urgent and non-urgent updates.

Urgent updates are the ones that reflect direct interaction, like typing, clicking, pressing, and so on.
Transition updates transition the UI from one view to another in a non-urgent manner.

Let's imagine a page with search capabilities. Once you add text into an input field, you want to see that text show up there immediately. This is an urgent update. But, as you type, it is not urgent to immediately show the user search results. On the contrary, developers usually debounce or throttle a user's input before showing search results.

So typing into an input field or clicking a filter button is an urgent update. Showing search results is not an urgent update, and it is considered a transition update. Let's see that in a code example:

import { startTransition } from "react";

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

// Mark any state updates inside as transitions and mark them as non-urgent
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(newInputValue);
});

Updates wrapped in startTransition are handled as non-urgent and will be interrupted if more urgent updates like clicks or keypresses come in. Suppose a transition gets interrupted by the user (for example, by typing multiple characters in a row). In that case, React will throw out the stale rendering work that wasn't finished and render only the latest update.

You can use a hook called useTransition to get a pending flag, like so:

function App() {
  const [isPending, startTransition] = useTransition();
  const [count, setCount] = useState(0);

  function handleClick() {
    startTransition(() => {
      setCount((oldCount) => oldCount + 1);
    });
  }

  return (
    <div>
      <span>Current count: {count}</span>

      {isPending && <Spinner />}

      <button onClick={handleClick}>Increment</button>
    </div>
  );
}

There are other hooks with the new release, but first, let's see something we've waited a long time for — Suspense — being brought to our server-side rendering apps.

Suspense On the Server

Suspense is now available on the server. Previously, it was available on the client-side with code splitting using React.lazy. But now, you can have a placeholder of some sort while your components "suspend". Let's see it in code:

<Suspense fallback={<PageSkeleton />}>
  <RightColumn>
    <ProfileHeader />
  </RightColumn>
  <LeftColumn>
    <Suspense fallback={<LeftColumnSkeleton />}>
      <Comments />
      <Photos />
    </Suspense>
  </LeftColumn>
</Suspense>

Suspense will fall back to the component you give it if any of the components in the tree "suspend". But what does it mean for a component to "suspend"? It can mean many things, however, in every case, it means that the component is not ready to render — it could be missing data or code.

What does this mean for the code example above? If a component suspends, the closest Suspense component above it "catches" it, no matter how many components there are in between. In the above example, if ProfileHeader suspends, then the entire page will be replaced with PageSkeleton.

However, if either Comments or Photos suspend, they'll both be replaced with LeftColumnSkeleton. This lets you safely add and remove Suspense boundaries according to the granularity of your visual UI design, without worrying about the components that might depend on asynchronous code and data.

If you use Suspense, a slow rendering component on the server will no longer hold the entire page back. Read more about it in this detailed GitHub discussion about SSR Suspense.

A door has also been opened for third-party data-fetching libraries to come in and support Suspense. Some GraphQL or REST libraries can support suspending components until requests finish. You can run your own ad hoc solution for data fetching and Suspense, but it is not recommended at the moment.

5 New Hooks in React 18

With React 18, we have five new hooks:

1. useId

useId is a new hook for generating unique IDs on both the client and server, while avoiding hydration mismatches. For example:

function CodeOfConductField() {
  const id = useId();

  return (
    <>
      <label htmlFor={id}>Do you agree with our Code of Conduct?</label>
      <input id={id} type="checkbox" name="coc" />
    </>
  );
}

2. useTransition

We already covered this one in the previous section about transitions.

3. useDeferredValue

useDeferredValue lets you defer re-rendering a non-urgent part of the tree. It is similar to debouncing or throttling, but has a few advantages. There is no fixed time delay, so React will attempt the deferred render right after the first render is reflected on the screen. The deferred render is interruptible and doesn't block user input.

If we take a look at the example with the search, we'd need to memoize the child component that's using the deferred value. Let's see an example:

function SearchResults() {
  const query = useSearchQuery("");
  const deferredQuery = useDeferredValue(query);

  // Memoizing tells React to only re-render when deferredQuery changes,
  // not when query changes.
  const suggestionResuls = useMemo(
    () => <SearchSuggestions query={deferredQuery} />,
    [deferredQuery]
  );

  return (
    <>
      <SearchInput query={query} />
      <Suspense fallback="Loading suggestion results...">
        {suggestionResuls}
      </Suspense>
    </>
  );
}

Now, the SearchSuggestions component will re-render only when the deferredQuery is updated. And to tie everything together, while the SearchSuggestions is suspended, we'd see "Loading results..." text.

4. useSyncExternalStore

useSyncExternalStore is a hook meant for reading and subscribing from external data sources in a way that’s compatible with concurrent rendering features like selective hydration and time slicing.

This hook is intended for library authors and is not typically used in application code. If you're maintaining a library and it sounds like you might need it, you can read more in the useSyncExternalStore official docs.

5. useInsertionEffect

The signature of useInsertionEffect is identical to useEffect, but it fires synchronously before all DOM mutations. This hook is meant to inject styles into the DOM before reading layout in useLayoutEffect. It does not have access to refs and cannot schedule updates.

useInsertionEffect is meant to be limited to css-in-js library authors. You should instead use useEffect or useLayoutEffect.

If you're an author or maintainer of css-in-js library, you can find more info about useInsertionEffect in its documentation.

Other Notable React 18 Changes

Bye-bye Older Browsers!

React now depends on modern browser features, including Promise, Symbol, and Object.assign.

Consider including a global polyfill in your bundled application if you support older browsers and devices such as Internet Explorer, which do not provide modern browser features natively or have non-compliant implementations.

Components Can Now Render `undefined`

React no longer throws an error if you return undefined from a component. The allowed component returns values consistent with allowed values in the middle of a component tree. The React team suggests using a linter to prevent mistakes like forgetting a return statement before JSX.

No `setState` Warning on Unmounted Components

Previously, React warned about memory leaks when you called setState on an unmounted component. This warning was added for subscriptions, but people primarily ran into it in scenarios where the setting state was fine, and workarounds would worsen the code.

Improved Memory Usage

React now cleans up more internal fields on unmount, so the impact from unfixed memory leaks in your application code is less severe. It would be interesting to see how memory usage drops compared to the previous versions.

Wrap-up: React 18 Brings Great Improvements

A lot of new and exciting announcements have come from the React team about React 18. To sum up, here's an overview:

React.render will warn you that you should replace it with React.createRoot
ReactDOM.hydrate will tell you the same about React.hydrateRoot
Automatic batching is batching state updates and performing them together, thus reducing the re-rendering count.
Transitions let you do more critical state updates and possibly interrupt other non-urgent updates. The API is useTransition and startTransition.
Suspense allows you to SSR your components in a way that doesn't block other components.
Suspense also opens a way for data frameworks to come in and build on it. That way, data fetching with a data framework will make the components suspend out of the box.
A couple of new hooks have come in to save the day. You might not need debounce and throttle in your code if you decide to use useDeferredValue.
Old browsers will be affected, so be sure to add polyfills if you need to support them.

That's it! We've gone through all the major changes. You can read the full React 18 changelog on GitHub. What change excites you the most?

Thanks for reading, and see you in the next one.

P.S. If you liked this post, subscribe to our JavaScript Sorcery list for a monthly deep dive into more magical JavaScript tips and tricks.

P.P.S. If you need an APM for your Node.js app, go and check out the AppSignal APM for Node.js.

Add Newsletter Subscription Form to React Website

Nikola Đuza — Sun, 23 Jan 2022 00:00:00 +0000

If you are a developer and do not like the fact of embedding 3rd party code senselessly into your website, this is a perfect post for you. We will go through the process of building a custom email sign-up form for your website so you can grow your audience. We will use React, but the same principles apply to any library or framework, like Gatsby or Next.js.

If you are someone returning to my blog, you might have noticed a small form on the bottom of pretty much any page. It is a form where you can sign up for my newsletter, and I’ve changed it a bit over the years. Below is how the form looks at the time of the writing:

At first, I used some out-of-the-box solutions given by various providers. I was most happy with ConvertKit, and its form looks, so I went with it for a while. I designed the form in ConvertKit’s UI and embedded its HTML on my blog. Here’s how it looked in the early days:

I was impressed by what you can achieve with their form builder, but being a developer, I was not too fond of copying a lot of code and styles that I know little about. Of course, I could have dived in the CSS and figured it out. And I had to do exactly that whenever I wanted to tweak the form looks. But I always wished to create a custom form with my styles and behavior that suits me.

So, without further ado, let us jump in and see how you can design and put a custom form that allows users to subscribe.

Form layout

If you want to grow your newsletter, you probably need just a name and an email of the person signing up. Of course, you can go crazy and create this super duper long form, but the chances of people filling it and signing up for your newsletter are going to go down probably. But hey, who am I to stop you? Knock yourself out.

So to start, we can just build a simple HTML form with two input fields and a submit button. To remind you, I will show how this is done in the React context, but it should be pretty intuitive on how to do it in raw HTML or some other library/framework. Here’s the JSX version:

const SubscribeForm = () => {
  const [email, setEmail] = useState("")
  const [name, setName] = useState("")

  const handleSubmit = async (event: React.FormEvent) => {
    // TODO
  }

  const handleEmailChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const { value } = event.target
    setEmail(value)
  }

  const handleNameChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const { value } = event.target
    setName(value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        aria-label="Your first name"
        name="fields[first_name]"
        placeholder="Your first name"
        type="text"
        onChange={handleNameChange}
        value={name}
      />
      <input
        aria-label="Your email address"
        name="email_address"
        placeholder="Your email address"
        required
        type="email"
        onChange={handleEmailChange}
        value={email}
      />
      <button>SUBSCRIBE</button>
    </form>
  )
}

Congrats, you just saw a classic HTML form in React’s implementation. A form tag, tied together by two inputs and one button. But, let’s not just jump over it. There’s important info that will later help us when we submit data to ConvertKit. Please go back a look at two input fields and their names. The fields[first_name] and email_address will prove valuable in a second.

Sending the data

OK, so we got the form rendering, but if you ship this form as is, no user will be able to subscribe and show up in the ConvertKit. To allow users to subscribe, we need to send data to ConvertKit by ourselves. Here’s how we can do it in our handleSubmit function:

const SubscribeForm = () => {
  ...
  const FORM_URL = `your form URL, we will describe it in a sec`

  const handleSubmit = async (event: React.FormEvent) => {
    event.preventDefault()

    const data = new FormData(event.target as HTMLFormElement)

    try {
      const response = await fetch(FORM_URL, {
        method: "post",
        body: data,
        headers: {
          accept: "application/json",
        },
      })
      const json = await response.json()

      if (json.status === "success") {
        return
      }
    } catch (err) {
      console.log(err)
    }
  }

  ...
}

Cool, we added the logic that makes a POST request to a FORM_URL with the form data, and we account for any errors that happen along the way. One thing we are missing here to be a full solution is a proper value for the FORM_URL. You can create your own by creating a form on ConvertKit.

Once you have the form created, copy the form ID from ConvertKit’s form editor URL. For example, the URL where you edit your form can be something like this https://app.convertkit.com/forms/designers/123456/edit. The 123456 is your form ID. Then, you can tape together the FORM_URL to be https://app.convertkit.com/forms/123456/subscriptions.

You can also get it from ConvertKit when you try to embed your form. Go to the HTML option to embed, and there you will find something like this:

<form action="https://app.convertkit.com/forms/123456/subscriptions" ...>
  ...
</form>

The action value is what you need to snatch and use in the custom form.

Now, do you remember those input name attributes we mentioned before? I’ll remind you - we added the fields[first_name] and email_address to our input fields. These names will build a proper FormData object that ConvertKit expects. So we just mimicked what the embedded ConvertKit form does for us. Now, when the user clicks the “SUBSCRIBE” button, they will actually show up in ConvertKit as a subscriber. How neat.

We can now upgrade the user experience in the next section. Read on.

Personal touches

Why would we build a custom form that does the same thing as the 3rd part one? Well, yes, we can better define its styles, and we have more control over what is shown to the user. But my reason to do all this was to add a bit more functionality to the form. For example, when you subscribe to my newsletter, you get a sweet transition that says thank you and mentions your name. It is definitely not necessary, but I find it charming and consider it a good user experience.

You can do it yourself as well, let us try it out in the example below:

const SubscribeForm = () => {
  const [status, setStatus] = useState<string | null>(null)
  const [email, setEmail] = useState("")
  const [name, setName] = useState("")

  const FORM_URL = `the URL you created in the previous section`

  const handleSubmit = async (event: React.FormEvent) => {
    event.preventDefault()

    const data = new FormData(event.target as HTMLFormElement)

    try {
      const response = await fetch(FORM_URL, {
        method: "post",
        body: data,
        headers: {
          accept: "application/json",
        },
      })

      setEmail("")
      const json = await response.json()

      if (json.status === "success") {
        setStatus("SUCCESS")
        return
      }
    } catch (err) {
      setStatus("ERROR")
      console.log(err)
    }
  }

  const handleEmailChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const { value } = event.target
    setEmail(value)
  }

  const handleNameChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const { value } = event.target
    setName(value)
  }

  return (
    <div>
      {status === "SUCCESS" && (
          <p>
            Welcome aboard{name ? `, ${name}` : ""}{" "}
            <span role="img" aria-label="Ship">
              🚢
            </span>
          </p>
          <p>Please check your inbox to confirm the subscription!</p>
      )}
      {status === "ERROR" && (
          <p>Oops, something went wrong...</p>
          <p>
            Please,{" "}
            <button onClick={() => setStatus(null)}>try again.</button>
          </p>
      )}
      {status === null && (
          <form onSubmit={handleSubmit}>
            <input
              aria-label="Your first name"
              name="fields[first_name]"
              placeholder="Your first name"
              type="text"
              onChange={handleNameChange}
              value={name}
            />
            <input
              aria-label="Your email address"
              name="email_address"
              placeholder="Your email address"
              required
              type="email"
              onChange={handleEmailChange}
              value={email}
            />
            <button>SUBSCRIBE</button>
          </form>
      )}
    </div>
  )
}

We are doing a similar thing as before, except we added a STATUS of the form. It can be either null, SUCCESS, or ERROR. We render a different output for the user based on those three values. Here’s how I did it on my blog when a user is subscribed:

And here is how it’s done when something bad happens:

But don’t trust the GIFs I posted. Try it out yourself and sign up for my newsletter at the bottom of this blog post and let me know what you think of the signing up experience.

Summing up

Having control and a final ask on what you put on your website is great. It can help you customize how it shows and behaves, which is not something that is not often available. In this blog post, we showed how to set up your own form for a newsletter so users can sign up with a few extra touches.

My blog is open-source, and you can find this form (but with styling) on the blog repo here. Pull requests, stars, and suggestions are welcome and encouraged.

If you liked it, I dare you to do it on your website but add a little bit of flair, maybe some animations if you’re into that. If you’re interested in seeing more `content like this, consider subscribing to the newsletter we mentioned a couple of times.

I want to do a similar blog post, creating a custom showing of tweets. Usually, you copy the code from Twitter and paste it on your site to embed tweets. I plan to build something to show tweets myself, so I don’t load a lot of Twitter code. Stay tuned for that.

All in all, thanks for tuning in and following this blog post. Share it with your friends and coworkers on Twitter if you find it useful:

Nikola Đuza

@nikolalsvk

New post on how you can build a custom email sign up form for your React website 👇

pragmaticpineapple.com/add-newsletter…

09:42 AM - 09 Feb 2022

Until the next one, cheers.

Smoothly Reverting CSS Animations

Nikola Đuza — Mon, 20 Dec 2021 00:00:00 +0000

Photo by Drew Beamer on Unsplash

Hey there, you probably tried to animate some HTML elements in your time using transitions, transforms, and animations in the CSS. I tried the same, but one problem occurred when I animated something on hover.

For example, you can look at the theme switch button on this blog (it’s in the menu at the top if you’re on mobile):

When I first added the button and the animation to it, I made a mistake. You can see the mistake below:

Not hovering suddenly ends the animation.

The mistake I made can be easily overlooked. If you look closely, you can see when I start to hover over it, the animation starts, but as soon as I move the mouse away, it abruptly resets to its starting point. It might be a small detail, and most folks can miss this, but it annoyed me from the start. Imagine the code for the theme switch to be something like this:

.theme-switch:hover {
  transition: transform 2s ease-in-out;
  transform: rotate(360deg);
}

It was all fine, and it made the sun spin using CSS rotate, but the rotation would suddenly reset once I moved the mouse away from the sun icon. Thankfully, there’s a simple solution for it. We need to put the transition rule to the general .theme-switch rule, not just the :hover rule.

.theme-switch {
  transition: transform 2s ease-in-out;
}

.theme-switch:hover {
  transform: rotate(360deg);
}

Let’s see what we get when we moved the transition rule:

Now it is silky smooth!

If we try to hover and move our mouse away, it will revert smoothly using our transition rule. No more annoying abrupt reset of the animation, yay!

OK, this was fun and easy if you use CSS transitions, but what if you decide to go with the keyframe animations? Read on to find out.

Smoothly Reverting Keyframe Animation

First off, if you are looking into reverting a keyframe animation, did you try to reconsider the approach you are taking? If you did and you realized that there’s no chance in the world you could use a transition animation, then read on. But if you can achieve what you need with a simple transition, scroll back to the first part of this blog post.

OK, so you are stuck with some keyframes, and you want to revert them, let’s say, on hover. How do you achieve that? First off, the solution is pretty hard to do with just CSS and HTML, but there is a way.

For example, let’s say you have a sun icon that is constantly spinning like so:

Spin, spin, spin

The code for it would look something like this:

.sun-icon {
  animation: in 4s linear 0s infinite normal;
}

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

Here we use @keyframes, the CSS at-rule that defines intermediate steps in a CSS animation. It differs from using transition by giving you more control over what happens at certain points in the animation. We want the element affected by the animation to go from 0 degrees to 360 degrees, and we use the from to syntax of keyframes. We could’ve also put 0% 100% instead of from to. They are synonyms, pretty much.

And, finally, at the .sun-icon rule, we use the shorthand animation rule where we define the following:

in - the name of the animation
4s - the duration of the animation
linear - the animation timing function
0s - the animation delay (meaning our animation starts immediately since the delay is 0 seconds)
infinite - the iteration count of our animation (how many times the animation will play out)
normal - the direction of the animation (can also be reverse, which we will see later) Phew, that is a lot of occurrences of the animation word.

Now that we have that, we should be able to revert the animation somehow. How can we do it? You might think we can leverage the animation-direction and put it into reverse instead of normal. Well, if we do that, we have a jumping animation like so:

Too much flickering

We added this bit of code to achieve the above mentioned:

.sun-icon:hover {
  animation-direction: reverse;
}

But that is obviously unwanted behavior. How else can we revert the animation?

We can add a little trick. We can wrap the sun icon into a container that will spin in reverse while hovering on it. It will look like this:

Smooth, again

This will be the HTML part:

<div class='sun-container'>
  <img class="sun-icon" src="sun.png"></img>
</div>

And this the CSS part:

.sun-container {
  width: 128px;
  height: 128px;

  animation: in 2s linear 0s infinite reverse;
  animation-play-state: paused;
}

.sun-icon {
  animation: in 4s linear 0s infinite normal;
}

.sun-container:hover {
  animation-play-state: running;
}

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

The container animation will run for 2 seconds (twice as fast as the sun icon animation, which runs for 4 seconds). Also, the container animation will start as paused, but it will run when we hover over the sun container element.

Other Ways To Revert Keyframe Animations

There are other ways to do it, but it will never be as smooth as the trick I showed you with both parent and child element spinning. There is a way to do it with JavaScript and playing around with keyframes in the CSS Tricks article.

The main problem with keyframe animations is that there is no way to track their progress. Once the animation starts, there is no browser API to let you figure out if the animation is at 46% of completion, for example. You can, potentially, setInterval and make it fire on every 10% of animation and mess with it there, but it is an unreliable solution.

Let me explain why the solution with setInterval (like the one in the CSS Tricks article I shared above) is unreliable. Imagine if the setInterval fires a bit late, and you presume you are at 10%, but you’re actually at 12% of the progress. If you change the animation, assuming you are still at 10%, you will get a slight jumping of the animation if you try to edit it. This brings us back to the similar problem we are trying to solve in the first place.

As we saw, we can’t utilize the animation-direction rule and just change it from normal to reverse and vice-versa. The animation resets every time you change that.

There is potentially one solution that might work, and that is with multiple animations. We can split one keyframe animation into multiple small ones and listen for animationend event. If you’re interested in this solution, consider subscribing to the newsletter and follow me on Twitter, where I will post more about this.

Think Before You Animate

We’ve gone through a couple of solutions to revert an animation, but we never went through the most important point - consider what you are trying to animate and how you are doing it. It probably doesn’t make sense to use keyframes to rotate an element in our examples. We can quickly achieve that with CSS transitions. I ended up using that approach on my blog in the end.

What I am trying to say is that maybe there is a more straightforward solution for you out there. You might avoid developing complex solutions and breaking your head trying to solve something. If you need to take the more complicated route, go ahead, nothing is stopping you. I showed a couple of ways here to choose and follow through.

But I hope this blog post is helpful to those with this kind of problem. It was fun to go through and figure out how to solve the keyframes part. I am sad that there isn’t a proper solution for this in the CSS spec, but I hope it is coming in the future.

If you like what you read and you think others will benefit from it, consider sharing it on Twitter blow:

Nikola Đuza

@nikolalsvk

Had troubles with reverting a CSS animation? Don't worry, I got you

pragmaticpineapple.com/smoothly-rever…

19:11 PM - 20 Dec 2021

Also, I made my blog code open source, you can check it out on GitHub here.

Thanks for tuning it. Catch you in the next one. Cheers.

General Ruby on Rails Problems and Takeaways

Nikola Đuza — Tue, 17 Aug 2021 12:58:12 +0000

Welcome to the last part of my Ruby on Rails Patterns and Anti-Patterns series. It's been quite a ride writing and researching all of these topics. In this blog post, we'll go over the most common problems I've encountered when building and shipping Ruby on Rails applications through the years.

The ideas I'll go through here apply to almost anywhere in the code. So consider them as general ideas, not something related to the Model-View-Controller pattern. If you are interested in patterns and anti-patterns related to the Rails MVC, you can check out the Model, View, and Controller blog posts.

So let's jump into general problems and takeaways.

Selfish Objects and the Law of Demeter

The Law of Demeter is a heuristic that got its name when a group of people worked on the Demeter Project. The idea is that your objects are fine as long as they call one method at a time and don't chain multiple method calls. What this means in practice is the following:

# Bad
song.label.address

# Good
song.label_address

So now, the song object no longer needs to know where the address comes from — the address is the responsibility of the label object. You are encouraged to chain only one method call and make your objects 'selfish' so that they don't share their full information directly but through helper methods.

Luckily, in Rails, you don't have to write a helper method per se — you can use the delegate helper:

def Song < ApplicationModel
  belongs_to :label

  delegate :address, to: :label
end

You can go ahead and play around with the options that delegate accepts in delegete's docs. But the idea and execution are pretty simple. By applying the Law of Demeter, you reduce structural coupling. Together with the powerful delegate, you do it in fewer lines and with great options included.

Another idea that's very similar to the Law of Demeter is the Single-responsibility Principle (or SRP for short). It states that a module, class, or function should be responsible for a single part of a system. Or, presented in another way:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

Folks can often have a different understanding of SRP, but the idea is to keep your building blocks responsible for a single thing. It might be challenging to achieve SRP as your Rails app expands, but be aware of it when refactoring.

When adding features and increasing the LOC, I've found that folks often reach out for a quick solution. So let's go through grabbing the quick fix.

I Know a Guy (Do You Need That Ruby Gem?)

Back in the day when Rails was a hot topic, there was a boom in open-source collaboration, with new Ruby gems popping up on every corner (like it is nowadays with all the emerging JavaScript libraries, but on a much smaller scale):

👆 Information from Module Counts.

Anyway, a common approach was to find an existing gem to solve your problem.

There's nothing wrong with that, but I'd like to share some bits of advice before you decide to install a gem.

First, ask yourself these questions:

What portion of the gem's features are you going to use?
Is there a similar gem out there that is 'simpler' or more up-to-date?
Can you implement the feature you need easily and with confidence?

Evaluate whether it's worth doing the implementation if you don't plan to use the whole array of gem features. Or, if the gem's implementation is too complex and you believe you can do it more simply, opt for a custom solution.

Another factor that I consider is how active the gem's repository is — are there any active maintainers? When was the last time a release happened?

You should also watch out for the gem's dependencies. You don't want to get locked into a specific version of a dependency, so always check the Gemfile.spec file. Consult the RubyGems way of specifying gem versions.

While we're on the topic of gems, there is a related idea that I've encountered: the 'Not Invented Here' (or NIH) phenomenon that applies to the Rails/Ruby world. Let's see what it's about in the next section.

Not Invented Here (Maybe You Need That Ruby Gem after All?)

In a couple of occurrences in my career, I had a chance to experience people (me included) fall for 'Not Invented Here' syndrome. The idea is similar to 'reinventing the wheel'. Sometimes, teams and organizations do not trust libraries (gems) that they can't control. Lack of trust might be a trigger for them to reinvent a gem that is already out there.

Sometimes, experiencing NIH can be a good thing. Making an in-house solution can be great, especially if you improve it over the other solutions out there. If you decide to open-source the solution, that can be even better (take a look at Ruby on Rails or React). But if you want to reinvent the wheel for the sake of it, don't do it. The wheel itself is pretty great already.

This topic is quite tricky, and if you ever get caught in such a situation, ask yourself these questions:

Are we confident that we can make a better solution than existing ones?
If the existing open-source solution differs from what we need, can we make an open-source contribution and improve it?
Furthermore, can we become the maintainers of the open-source solution and possibly improve lots of developers' lives?

But sometimes, you just have to go your own way and create a library yourself. Maybe your organization doesn't like licensing an open-source library, so you are forced to build your own. But whatever you do, I'd say avoid reinventing the wheel.

Lifeguard on Duty (Over-rescuing Exceptions)

People tend to rescue more exceptions than they originally aimed for.

This topic is a bit more related to the code than the previous ones. It might be common sense to some, but it can be seen in the code from time to time. For example:

begin
  song.upload_lyrics
rescue
  puts 'Lyrics upload failed'
end

If we don't specify the exception we want to rescue, we will catch some exceptions that we didn't plan to.

In this case, the problem might be that the song object is nil. When that exception gets reported to the error tracker, you might think that something is off with the upload process, whereas actually, you might be experiencing something totally different.

So, to be safe, when rescuing exceptions, make sure you get a list of all the exceptions that might occur. If you can't obtain every exception for some reason, it's better to under-rescue than to over-rescue. Rescue the exceptions that you know and handle the others at a later stage.

You Ask Too Much (Too Many SQL Queries)

In this section, we are going to go through another web development, relation-database problem.

You bomb the webserver with too many SQL queries in one request. How does that problem arise? Well, it can happen if you try to fetch multiple records from multiple tables in one request. But what most often happens is the infamous N+1 query problem.

Imagine the following models:

class Song < ApplicationRecord
  belongs_to :artist
end

class Artist < ApplicationRecord
  has_many :songs
end

If we want to show a couple of songs in a genre and their artists:

songs = Song.where(genre: genre).limit(10)

songs.each do |song|
  puts "#{song.title} by #{song.artist.name}"
end

This piece of code will trigger one SQL query to get ten songs. After that, one extra SQL query will be performed to fetch the artist for each song. That's eleven (11) queries total.

Imagine the scenario if we load more songs — we'll put the database under a heavier load trying to get all the artists.

Alternatively, use includes from Rails:

songs = Song.includes(:artists).where(genre: genre).limit(10)

songs.each do |song|
  puts "#{song.title} by #{song.artist.name}"
end

After the includes, we now only get two SQL queries, no matter how many songs we decide to show. How neat.

One way you can diagnose too many SQL queries is in development. If you see a group of similar SQL queries fetching data from the same table, then something fishy is going on there. That's why I strongly encourage you to turn on SQL logging for your development environment. Also, Rails supports verbose query logs that show where a query is called from in the code.

If looking at logs is not your thing, or you want something more serious, try out AppSignal's performance measuring and N+1 query detection. There, you will get an excellent indicator of whether your issue comes from an N+1 query. Here's how it looks below:

Sum Up

Thanks for reading this blog post series. I'm glad you joined me for this interesting ride, where we went from introducing patterns and anti-patterns in Rails to exploring what they are inside the Rails MVC pattern, before this final blog post on general problems.

I hope you learned a lot, or at least revised and established what you already know. Do not stress about memorizing all of it. You can always consult the series if you are having trouble in any area.

You will surely encounter both patterns and anti-patterns because this world (and software engineering especially) is not ideal. That shouldn't worry you either.

Mastering patterns and anti-patterns will make you a great software engineer. But what makes you even better is knowing when to break those patterns and molds, because there is no perfect solution.

Thanks again for joining and reading. See you in the next one — and cheers!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Nikola helps developers improve their productivity by sharing pragmatic advice & applicable knowledge on JavaScript and Ruby.

Gentle Guide to Get Started With tmux

Nikola Đuza — Mon, 16 Aug 2021 00:00:00 +0000

You ended up here probably because you are looking to level up your command line skills. And that’s fine, it is the exact same reason I am writing this blog post. Since I began learning how to program, I’ve been a terminal dweller, and it’s been great. I always feel at home when I log into my shell. Today, our terminal experience will feel even better. We will level up our knowledge and our toolbelt with a great tool called tmux.

Photo by David Iskander on Unsplash

What is tmux?

tmux is a terminal multiplexer, meaning it is a window manager within your terminal. It allows you to open multiple windows (sessions) within one terminal window (session). So it enables other programs to run from it, allowing you to manipulate them easily. Most of the folks find that one of the features to use tmux on a daily basis.

But, besides being a window manager, tmux can also do the following: Protect running programs on a remote server from connection drops by running them inside tmux. We’ve all been there - you connect to a server, you go to get your coffee/lunch, you come back, and the session is frozen or unresponsive. Allow a user to access programs running on a remote server from multiple different local computers.

Today, we are going to focus on the window manager aspect of tmux. In a future blog post, we will cover some advanced usages of tmux and how it can benefit you.

Installing

You can install tmux using package managers on all major platforms, but let’s cover some of the most famous ones. On Debian or Ubuntu, you can do the following:

apt install tmux

On Mac OS, you can use brew:

brew install tmux

To check whether you succeeded in the installation, let’s try to read man pages for tmux with:

man tmux

If you get something like this:

tmux Manual

You’re good to go.

Starting tmux

We can start tmux by using the tmux command in our terminal to see what its all about. After that, you can see that everything stayed the same, except the green line at the bottom. What happened here is that we connected to a tmux server as a client. tmux runs a server on a specific PID in the background, and when we type tmux we run the server automatically.

So we are connected to the tmux server from a session named 0, as you can see in the [0] portion of the screen. So tmux acts as sort of a layover of the standard terminal session. Let’s have a look at what you get when you enter a tmux session:

start of a tmux session

At the bottom left, you see the [0], which represents the session. Right next to it is the 0:zsh showing which window is open and what program is running there. We just started this session, so we only have one window open, and zsh is running there.

You can go on and use the terminal as you usually use it, but that would be just plain boring, right? Let’s learn a thing or two we can do as beginners in tmux. I’d like us to go through the process of creating and moving through panes in tmux.

Pane Management

If you’ve used iTerm2 and utilized pane splitting there, you will like this feature a lot. It is pretty much the same in tmux, with the only difference being the shortcuts you use to create new panes. In iTerm2, you can do cmd + d and cmd + shift + d to split panes vertically and horizontally.

Creating Panes

In tmux, you can do it with Ctrl-b % for a vertical split and Ctrl-b " for a horizontal one. You will see that all shortcuts start with Ctrl-b or C-b for short. To make C-b shortcuts work, you need to press the control key and b key at the same time, then you can press the following character or a symbol like " to split horizontally. for example. C-b signals tmux that you are about to send a shortcut its way. Let’s try out this feature together below:

How to split panes in tmux

If you’re not a fan of shortcuts for some reason, you can type tmux split-window -h to do a horizontal split and tmux split-window -v to do a vertical split.

Moving Around the Panes

We might’ve pushed it too much in the GIF above, but you get the idea. Now, for the most important part - how to move around? Don’t worry, it’s easier by default than in iTerm2. You use C-b and arrows left, right, up, and down. So C-b Arrow-Left C-b Arrow-Right and so on.

Closing Panes

If you finish with one pane, just press Ctrl-d, and it will get closed.

Now let’s try to create a new window.

Window Management

A window in tmux is similar to a tab in iTerm2, pretty much. It’s a new canvas for you to split it into panes and run commands. You must be asking - how do I create one?

Creating Windows

Just do C-b c, and a new window will form. You can try it out a couple of times. I did a similar thing, except I opened a program in each window to see the difference together. Let’s have a look below:

Windows in tmux

You can see the following text at the tmux status line:

0:zsh 1:vim* 2:ed- 3:ruby

The 0:zsh presents the first window where just the zsh is running. The 1:vim* lets us not that in the second window, we have Vim running, and the asterisk * shows us it’s the active window. The 2:ed- does the same, except the dash - shows us it’s the last window. Another question imposes on itself right now - how do we change windows?

Navigating Through Windows

No worries, I got you. You can change windows in multiple ways, but I find this one most effective. You can use the combination of C-b and index of a window, e.g. C-b 1 to go to the window marked as 1 in the tmux status line. So C-b 0 in our case will open the window with zsh open since it shows like 0:zsh in the tmux status line at the bottom of the screen.

You can also use C-b p for a previous window, C-b n for the next window, and C-b l for the last window (this is where that dash - comes to play from the section above).

tmux Sessions

tmux wouldn’t be great with its flexible session. You can attach and detach from a session anytime you want. Most of the folks praise tmux for its session management. Imagine sessions as different areas of work you do. For example, one session can relate to your private web project where you run frontend, backend, editor, tests, and so on. Another session can be an SSH session on some server where you are messing around with infrastructure.

Attaching and Detaching From Sessions

To feel the power of sessions, you can start tmux in another terminal window or a tab (assuming you have one session running from the examples above). If you now press C-b d you should see the following:

$ tmux
[detached (from session 1)]

Cool, we detached from the session we just created. Now in that same terminal window, type tmux ls:

$ tmux ls
0: 4 windows (created Thu Aug 12 20:08:22 2021) (attached)
1: 1 windows (created Thu Aug 12 20:15:03 2021)

The first session marked with 0 shows that we have four windows open, and we are attached to it. But the second session marked with 1 (one) is not attached. With the C-b d, we detached from the session marked with 1, and we used tmux ls to list all the available sessions. How neat, now we can organize our work even better.

If you don’t like the default naming of sessions with numbers like 0 and 1, you can always give your session a name by using tmux new -s heythere. Now the created session will get heythere name. We can see that by detaching (C-b d) and running tmux ls again:

$ tmux ls
0: 4 windows (created Thu Aug 12 20:08:22 2021) (attached)
1: 1 windows (created Thu Aug 12 20:15:03 2021)
heythere: 1 windows (created Thu Aug 12 20:21:09 2021)

We can then attach to the heythere session easily with:

tmux attach -t heythere

And we’re back in the heythere session. Pretty cool, right? I think that’s enough for one. We got a lot to process and use in our terminal. I decide we gather back and try to use this for a couple of days or weeks.

Final Thoughts

And that should be it for getting started with tmux. I want to mention one thing that might help you and me out until the next blog post. If you ever get lost or forget about shortcuts, there’s C-b ? shortcut that shows a list of commands you can use. Here’s how it looks:

tmux help screen

Also, another great thing to check out if you’re using iTerm2 is its integration with tmux. More to read in iTerm2 docs.

I plan to write a follow-up blog post with some advanced usages of tmux. If you liked this one and want to see another blog post, consider joining the newsletter, it will get you notified when it’s out.

As always, don’t forget to share it with your friends or coworkers. Here’s a tweet you can message, like, retweet, ignore, or whatever you please:

Thanks for joining, and I’m looking forward to seeing you in the next one.

Cheers.

5 Essential Tips for Testing JavaScript UIs

Nikola Đuza — Wed, 30 Jun 2021 00:00:00 +0000

When it comes to writing tests for (JavaScript) UIs, you either like it or not. But, if you’re inside a company that demands a certain test coverage threshold, or you want to have logic covered, you will have to do it eventually. Whatever your case is, I believe the following five tips will help you write better tests.

Photo by Annie Spratt on Unsplash

I struggled a lot with writing tests when starting. The concept was pretty straightforward — you write code that validates other code you wrote. But, something was off back then, and I was not too fond of it at first. Fast forward a couple of years later, and I am now okayish with writing tests. I got my head around it. These are the tips I find most useful on day to day basis of writing UI tests.

1. Test Behavior, Not Implementation**

For some, it might come naturally to follow the principle of testing UI behavior rather than implementation. But trust me, sometimes, in the depths of the test code, you might lose this idea and try to hack your way out of the test.

If you are familiar with Test Driven Development (TDD), there is also Behavior Driven Development (BDD). The idea is to create a script using a DSL (Domain-Specific Language) that almost everyone on the project can understand. For a long time, the primary tool to make it with was Cucumber (the library, not the vegetable). It would allow you to form a test script like so:

Feature: Put items in the cart Scenario: Breaker joins a game Given the user has visited the awesome shopping page When the user adds an item to the cart Then the user should see the item in the cart

The idea is simple, and the implementation uses the Gherkin syntax with “Given”, “When”, and “Then” format. Scripts like these are there to have stakeholders read them and understand the features and scenarios, but I rarely see them reading them in practice.

Anyways, if you are not a fan of such tools, you can skip using it (duh), but keep in mind that you should test behavior.

2. Test One Thing At a Time

One great tip I’d give to myself a couple of years ago was to focus on testing one thing in one test. I used to test lots of different things in one test. One good thing that Cypress framework does is that they advise only to test the login functionality once and log in programmatically in all other tests.

So let’s say you are testing the adding an item to the shopping cart. Ideally, it would be best if you focused on that piece of UI functionality in the test. All of the other things like:

logging in,
seeding the items to be added to the card,
publishing the store where the user will purchase the items

should all be part of the setup. You shouldn’t do all of these things directly in the test, but instead, just focus on the actions user takes to add an item to the cart.

3. Structure Tests Properly

Another thing that will set you up for success in testing is to follow the AAA patterns. AAA stands for the following:

1st A — Arrange : Put and perform everything needed to set up the test for the functionality that is about to get tested. Seed the data, log in the user, stub calls, etc.
2nd A — Act : Execute the actions like adding an item to the cart.
3rd A — Assert : Ensure that the received value satisfies the expectation. Make sure the test validates the expected behavior.

Go ahead, and try it out in your next test.

4. Use Helpers to Generate Test Data

Often, you face the same problem — the creation of particular data objects in tests. Whether that’s a product, user, random item, you have to create the object somehow in the test setup. One software design pattern that can help you out here is the Factory pattern.

One library that can help us with generating objects is the Fishery library. If you’re using TypeScript, these two can fit in perfectly. Let’s say we want to generate a user in our test. One way to do it is like this:

// factories/user.ts

import { Factory } from "fishery"
import { User } from "../my-types"
import postFactory from "./post"

export const userFactory = Factory.define<User>(({ sequence }) => ({
  id: sequence,
  name: "Rosa",
  address: { city: "Austin", state: "TX", country: "USA" },
  posts: postFactory.buildList(2),
}))

Then, we can create the user without too much fuss like so:

const user = userFactory.build({ name: "Sandra" })

You should now have more precise tests because you can generate objects without specifying all the attributes, only the ones relevant to the current test you are writing. Also, the user factory definition is in one place, and you can easily edit it from there, no need to go through all your tests when some attributes change.

5. Avoid Sleeping (In Tests)

We’ve all been there, setting some timeout to handle an async test case or to force the next tick. With the new tools, you don’t have to do this. If you’re testing some async code, you can use Jest to test it:

test("the data is peanut butter", async () => {
  const data = await fetchData()
  expect(data).toBe("peanut butter")
})

With the simple async / await syntax, no more of the setTimeout is needed. Or, better yet, if you’re using Cypress, they have an integrated waiting mechanism that will give a certain amount of time for each command to perform. Also, in the testing-library, you can do waitFor like described in its docs.

Anyways, whatever you do, think twice before you call setTimeout or any other time-related methods because it will make your tests less readable and possibly flaky.

Sum Up

Thanks for reading these five tips. I hope that you gained some insight after them. Also, I hope these help you write better UI tests for your JavaScript apps.

If you’re interested in more blog posts like these, consider subscribing to the newsletter. Also, if you find this blog post useful, you can share it with your friends and colleagues on Twitter below:

Nikola Đuza

@nikolalsvk

I shared some of the tips for JS tests I came across throughout the years 👇

What is your number one tip for writing tests?

medium.com/@nikolalsvk/5-…

14:52 PM - 30 Jun 2021

Catch you in the next one, cheers.

4 Useful fzf Tricks for Your Terminal

Nikola Đuza — Mon, 21 Jun 2021 00:00:00 +0000

Welcome, you are probably interested in using one of the best tools for command-line - fzf. Fzf is a command-line tool for fuzzy searching. Well, at first, it might sound not attractive. But, bear with me, it is very sexy, and it will make your life easier leaping through your shell.

I prepared four tricks that you can keep up your sleeve whenever you are inside the terminal. But first, let’s go over how we can set up fzf.

Photo by Devon Janse van Rensburg on Unsplash

Getting started

If you haven’t already, you can install fzf using Git:

git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
~/.fzf/install

Or, if you are on macOS and want to skip all the fuss, you can use the following command:

brew install fzf

# To install useful key bindings and fuzzy completion:
$(brew --prefix)/opt/fzf/install

If you’re still having trouble, try out the fzf docs about installing.

Mic Check

After installing, let’s go and try the basic fzf functionality. You can try to run fzf inside your terminal. You should see something like this:

The fuzzy finder launches across your terminal window, and you can search for whatever file you want. The cool thing is that fzf if indexing files as you type. If your directory doesn’t have much complexity regarding files and dirs, you won’t notice the indexings at the bottom.

1. Fuzzyily Change Directories

The first trick today is using fzf to quickly cd into a directory. You can press ALT + c (OPTION + c on macOS), and you will get an interactive prompt. Take a look below:

It starts indexing the contents of all the directories that are inside the one you are in right now. You can start typing for the wanted directory, select the one you need with arrow keys, and press the enter key to get into it. Convenient, right?

2. Swoosh Through History

The second trick and one of my favorites, to be honest, is the ability to search through the command history with fzf. To get started, press CTRL + r in your terminal. Then, search for a command you typed previously. You should see something like this:

You can quickly jump to the command you typed some time ago. I find it super useful on a day-to-day basis.

3. Autocomplete Anything

You can utilize fzf almost anywhere in your terminal. One of the default features is to allow you to find the process to kill quickly. You can try it out by typing kill -9 and pressing TAB. If that doesn’t work, type kill -9 ** and TAB. You can now search for the process or multiple processes you want to end.

You can also quickly search through hostnames to SSH. To do this, type ssh ** and press TAB. You will get the interactive search to find the wanted hostname.

To sum up, here are some of the options you can use by default:

kill -9 **<TAB>

ssh **<TAB>
telnet **<TAB>

unset **<TAB>
export **<TAB>
unalias **<TAB>

If you get tired of typing **, you can change the fzf trigger by setting FZF_COMPLETION_TRIGGER variable. For example:

# Use ~~ as the trigger sequence instead of the default **
export FZF_COMPLETION_TRIGGER='~~'

If you want to take this to the next step, try out the fzf-tab plugin. I am using zsh and oh-my-zsh, so it was pretty straightforward to set up. The plugin basically “plugs in” fzf into your default tab completion. I suggest you try it out.

4. Preview Files Before Selecting Them

Another cool thing to try out is the preview feature of the fzf. It allows you to preview files before you open them. To access it, you need to pass --preview- to fzf. Let’s see it in action:

The command I call is:

fzf --preview 'bat --style=numbers --color=always --line-range :500 {}'

But you can customize this all you want. My command uses the bat, the cat clone you can find on GitHub. You can also go with the simple cat command like so:

fzf --preview 'cat {}'

Or, if you want to push this a bit more, you can set the default preview options when completing specific commands. You can show the tree view of the directories and files like so:

You can achieve the similar using the power of the tree. I had to install it on macOS with brew install tree. Then, I added the _fzf_comprun function to load on shell initialization (you can add it in .bashrc or .zshrc). Here is how it looks:

_fzf_comprun() {
  local command=$1
  shift

  case "$command" in
    cd) fzf "$@" --preview 'tree -C {} | head -200' ;;
    *) fzf "$@" ;;
  esac
}

You can add more cases with more commands if you’d like because you might want the different commands to show the preview in other cases. For example, cat and bat will work well for files but not for previewing directories and hostnames to SSH into.

5. BONUS: Integrate with Vim

If you’re already using Vim (or you’re planning), I must tell you that fzf fits with Vim perfectly. The fuzzy search, preview windows, and customization options are so lovely you’d going to wish to have it in every other situation.

If you’re interested in setting up Vim and fzf, check out my blog post about improving Vim workflow with fzf.

Sum Up

fzf is a great tool to have in your toolbelt, especially if you’re dwelling inside the terminal. I hope this blog post taught you something new or inspired you to try some of these tricks.

If you liked what you read, consider subscribing to my newsletter to get updated when a new post comes up. Also, you can comment, like, or share this with your friends on Twitter below:

Catch you in the next one, cheers.

DEV Community: Nikola Đuza

A Guide to Handling Errors in Preact

Catching Rendering Errors in Preact

1. Catch Rendering Errors Using componentDidCatch

2. useErrorBoundary Hook to Catch Rendering Errors

Preact Error Catching in Event Handlers

Preact Error Catching in setTimeout Calls

Tracking Errors in Preact with AppSignal

Wrapping Up

Adding custom HTML and CSS to GitHub README

GitHub Profile README

Custom CSS and HTML in an SVG

Render SVG inside GitHub README

Render local README files before pushing to GitHub

Real-world example

Sum up

What's New in Next.js 13

app/ Directory in Next.js 13 (In Beta)

Layouts in Next.js 13

React Server Components

Streaming and Data Fetching

Streaming and Fetching in Server Components

Streaming and Fetching in Client Components

Caching with Fetch

Turbopack

next/image Improvements

@next/font

next/link Improvement

Generating OG Images with @vercel/og

Middleware API Changes

Telemetry

Wrapping Up: Next.js 13 Brings Great New Features

How to Preview localhost Website on Mobile Phone

Step 1: Connect your device to the same network

Step 2: Find your computer’s local IP address

Mac OS

Linux

Windows

Step 3. Get the port number

Step 4: Open your other device’s browser

That is it

How to Handle Errors in React

The Classic 'Try and Catch' Method in React

React Error Boundaries

Error Catching in Event Handlers

Error Catching in setTimeout Calls

JavaScript's react-error-boundary Package

Using Your Own React Boundaries

Summing Up: Get Started with React Error Handling

What's new with React 18

Breaking Changes in React 18

Automatic Batching in React 18

Transitions

Suspense On the Server

5 New Hooks in React 18

1. useId

2. useTransition

3. useDeferredValue

4. useSyncExternalStore

5. useInsertionEffect

Other Notable React 18 Changes

Bye-bye Older Browsers!

Components Can Now Render undefined

No setState Warning on Unmounted Components

Improved Memory Usage

Wrap-up: React 18 Brings Great Improvements

Add Newsletter Subscription Form to React Website

Form layout

Sending the data

Personal touches

Summing up

Smoothly Reverting CSS Animations

Smoothly Reverting Keyframe Animation

Other Ways To Revert Keyframe Animations

Think Before You Animate

General Ruby on Rails Problems and Takeaways

Selfish Objects and the Law of Demeter

I Know a Guy (Do You Need That Ruby Gem?)

Not Invented Here (Maybe You Need That Ruby Gem after All?)

Lifeguard on Duty (Over-rescuing Exceptions)

1. Catch Rendering Errors Using `componentDidCatch`

2. `useErrorBoundary` Hook to Catch Rendering Errors

Preact Error Catching in `setTimeout` Calls

`app/` Directory in Next.js 13 (In Beta)

`next/image` Improvements

`@next/font`

`next/link` Improvement

Generating OG Images with `@vercel/og`

Error Catching in `setTimeout` Calls

JavaScript's `react-error-boundary` Package

Components Can Now Render `undefined`

No `setState` Warning on Unmounted Components