DEV Community: Matthew Claffey

5 reasons why data handling is easier with Redux Toolkit & RTK Query

Matthew Claffey — Fri, 08 Dec 2023 13:31:46 +0000

Have you ever come onto a project and you notice there are multiple ways to call apis and you just get confused to which to use? Some ways might be overly complicated for what you need to do, you don't know which one to use and then when you get to a code review you get told to use the other way?

I wanted to find a way we could have a standardised way of calling apis so that the UI was kept simple and had information to use for the UI to display different states without having all that logic built in every time you needed to call an api. You normally get something like this…

import { useState } from 'react';

const Component = () => {
  const [isLoading, setIsLoading] = useState(false);
  const [data, setData] = useState();
  const [isSuccess, setIsSuccess] = useState(false);
  const [isError, setIsError] = useState(false);

  useEffect(() => {
    const fetch = async () => {
      try {
        setIsLoading(true);
        const response = await fetch('/api/users');

        if (response.status === 200) {
          const data = await response.json();
          setIsSuccess(true);
          setData(data);
          setIsLoading(false);
        } else {
          setIsError(true);
        }
      } catch(e) {
        setIsError(true);
      }
    }
  }, []);

  isLoading && return <p>IsLoading</p>;
  isError && return <p>Error</p>;
  return <p>{data ? JSON.stringify(data) : 'Empty'}</p>
}

Overtime, this looks a bit mental. Nothing caters for caching here, it fetches every time the component mounts and it is not reusable in another component.

In the project I was working on we was using redux anyway so I thought how could we use RTK query to make our lives easier.

🤔 What is RTK Query?

RTK Query is a tool you integrate with redux toolkit that makes handling data in your web apps a whole lot easier. It helps you fetch data from a server, manage it in your app, and keeps it up to date without all the usual headaches.

01. 📦 Creating apis

RTK query only takes minutes to setup before you can start setting up API endpoints.

📝 Example: This is our example of use setting up a basic set of APIS which get the user which share an authorisation token.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ 
    baseUrl: '/api',
    prepareHeaders: (headers) => {
      // Example if you need to apply a header on all apis
      headers.set('Authorization', 'Bearer TOKEN');

      return headers;
    },
  }),
  endpoints: (builder) => ({
    getUsers: builder.query({
      query: () => 'users' // /api/users
    }),
    getUser: builder.query({
      query: (id) => `users/${id}`
    }),
    updateUser: builder.mutation({
      query: (id, body) => `users/${id}`,
      method: 'PATCH',
      body,
    }),
    deleteUser: builder.mutation({
      query: (id) => `users/${id}`,
      method: 'DELETE',
    })
  })
});

👍 Good for: Having a standardised way for setting up endpoints and sharing headers between them.

02.🪝 React Hooks

No more creating your own custom hooks for apis! RTK creates react hooks for you when you add a new endpoint.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (builder) => ({
    getUsers: builder.query({
      query: () => 'users' // /api/users
    }),
  })
});

export const {
  useGetUsersQuery,
} = api;

How awesome is that? That would have been about a solid day or two creating a fancy react hook that tries to solve all purposes that is now resolved as soon as you make a new endpoint.

Queries

As soon as the component mounts we fetch off to the api to get the data we need.

📝 Example: Fetching all users showing different visual states.

import { useGetUsersQuery } from '../apis';

const Component = () => {
  const { 
    data, // the response from the api
    isError, // has an error
    isLoading, // first mount loading
    isFetching, // is Fetching again after the first mount
    isSuccess, // is 200
    error // Error message
  } = useGetUserQuery();

  // Purely for demo purposes
  return <p>{JSON.stringify(data)}</p>
}

👍 Good for: Shared pattern across the app making it easier to understand.

Mutations

Mutations allow you to make a change to an endpoint based on an action that has been fired in the app.

📝 Example: Deleting a user when clicking a button.

import { useState } from 'react';
import { useDeleteUserMutation } from '../apis';

const Component = () => {
  const [
    deleteUserPromise, 
    { isSuccess, isError, data }
  ] = useDeleteUserMutation();

  const handleClick = async () => {
    await deleteUserPromise('userOne');
  }

  return (
    <button type="button" onClick={handleClick}>
      Delete user
    </button>
  );
}

👍 Good for: Shared pattern across the app making it easier to understand.

Lazy Queries

Lazy queries behave like mutations but are used more for get requests that you need to do after an action is called.

📝 Example: Getting a user by id when you click a button.

import { useState } from 'react';
import { useLazyGetUserQuery } from '../apis';

const Component = () => {
  const [user, setUser] = useState();
  const [
    getUserPromise, 
    {} // Same data as a query
  ] = useLazyGetUserQuery();

  const handleClick = async () => {
    const { data } = await getUserPromise('userOne');

    if (data) {
      setUser(data);
    }
  }

  return (
    <>
      <button type="button" onClick={handleClick}>
        Get user
      </button>
      {user && <p>{user.userName}</p>}
    </>
  );
}

👍 Good for: When you need get data from an action instead of on mount of a component.

👀 Watch out …

Queries/Lazy Queries are cached endpoints by default so when you change some code with a mutation you might get a cached response from the queries ….

03. ⚙️ Let's fix that

Default cache times

The default cache time for a query is 60 seconds.
When multiple components use the same hook, it will prevent the same api from being called multiple times which reduces overhead on your server 💰. When the first one is resolved, it is resolved for everywhere that calls it.

📝 Example: Setting getUser to have 0 second cache.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (builder) => ({
    getUser: builder.query({
      query: (id) => `users/${id}`,
      keepUnusedDataFor: 0,
    }),
  })
});

🕵️Tip: keepUnusedDataFor is good for apis that you need to get fresh data from every time. This also can be inherited when set at the top level api.

Invalidating caches with Tags

Sometimes you just need to update the cache when you call a mutation. This is where RTK query provides you with Tags.

📝 Example: Using tagTypes to define what tags I want to define. When deleteUser gets called it will invalidate anything with provideTags: ["Users"].

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  tagTypes: ['Users'],
  endpoints: (builder) => ({
    getUsers: builder.query({
      query: () => 'users',
      provideTags: ['Users']
    }),
    deleteUser: builder.mutation({
      query: (id) => `users/${id}`,
      method: 'DELETE',
      invalidatesTags: ['Users']
    })
  })
});

Refetching

Now we have tags in place, we can use a method that returns back from the query called "refetch" which will get us the latest set of users when the deleteUser method has completed.

📝 Example: When deleteUser is fired, it will invalidate the getUsers cache and then "refetch" will get a new set of users.

import { useEffect } from 'react';
import { useGetUsersQuery, useDeleteUserMutation } from '../apis';

const Component = () => {
  const { data, refetch } = useGetUserQuery(user);
  const [deleteUser, { isSuccess }] = useDeleteUserMutation();

  const handleClick = async () => {
    await deleteUser('userTwo');
  }

  useEffect(() => {
    if (isSuccess) {
      // even though the tag is invalidated, there
      // is nothing telling useGetUser to refetch the
      // the new cache
      refetch();
    }
  }, [isSuccess]);

  return (
    <button type="button" onClick={handleClick}>
      Update user
    </button>
  );
}

04. 🔄 Other Features

Polling

RTK Query can take secondary params to change how often to re-fetch the data.

📝 Example: Polling for changes to our get all users.

import { useGetUsersQuery } from '../apis';

const Component = () => {
  const { data } = useGetUserQuery(undefined, { polling: 3000 });

  // Purely for demo purposes
  return <p>{JSON.stringify(data)}</p>
}

🟠Be careful: Use this pragmatically as it could become costly on the server side.

Automatic Refetching

When a query takes params to fetch specific data, it will cache that specific request for 60 seconds. By making the query dynamic with query parameters, the data is passed into the hook updates the state returned as it calls a new endpoint path.

📝 Example: Updating the user id when pressing the button which fetches the other user.

import { useState } from 'react';
import { useGetUsersQuery } from '../apis';

const Component = () => {
  const [user, setUser] = useState('userOne');
  const { data } = useGetUserQuery(user);

  const handleClick = () => {
    setUser('userTwo');
  }

  return (
    <button type="button" onClick={handleClick}>
      Update user
    </button>
  );
}

05. ⛓️ Dependency Management

RTK Query can take secondary parameter called skip which will tell RTK to not call this api until the id is defined.

📝 Example: Using skip parameter to prevent the query from being called.

import { useGetUsersQuery } from '../apis';

const Component = () => {
  const [user, setUser] = useState(undefined);
  const { data } = useGetUserQuery(user, { skip: user === undefined });

  const handleClick = () => {
    setUser('userTwo');
  }

  return (
    <button type="button" onClick={handleClick}>
      Update user
    </button>
  );
}

💣 What doesn't do well?

If you are like me who is a NextJS fanboy then you will have noticed that in version 13 there is a big buzz around server components and moving all JS code back to the server so we render more on the sever which makes the client faster. RTK is a client-side library so this does not work with server components.

🏁 Conclusion

In summary, the main reason why I like using this tool is purely around DevEx. I like how multiple teams can easily adopt this library and then when you move around teams you can easily understand how these apis work as there is a standardised pattern of implementing endpoints across the app.
Not only that the DevEx is good, it also makes my unit tests a lot nicer as I am mocking the variables that come from the react hooks which makes my confidence in my tests a lot higher as I can test more of the UI.

This is not saying use RTK for everything, as there are many libraries that do this however if you are using toolkit on your project maybe have a look at this?

What are your experiences using it?

Integrating Sentry.io with GatbsyJS

Matthew Claffey — Sun, 31 Jan 2021 15:41:17 +0000

When a web application has a lot of incoming traffic we want to have some form of logging to monitor errors across the domain so our application is performing at its best. In this article I am going to show you how to implement Sentry with GatsbyJS.

Getting started

If you wish to follow along with the tutorial here is what I used to get setup.

Gatsby setup

npm i gatsby -g

npm init gatsby

Sentry setup

Register for a free account with Sentry
install @sentry/gatsby --save-dev - link
install @sentry/react --save
in gatsby-config.js write the following code:

plugins: [
  {
    resolve: "gatsby-plugin-sentry",
    options: {
      dsn: "YOUR_SENTRY_DSN_URL",
    }
  }

];

If you wish to look at some code you can run gatsby new my-app https://github.com/code-mattclaffey/sentry-gatsby-example

Providing a better user experience when something goes wrong

The customer would normally get a "white screen of death" when an error happens and that completely stops the journey for a customer. This leads to a very high chance of the customer not purchasing your product and it can really leave a bad review if the error is not handled appropriately.

In React, there's a pattern called an error boundary which contains the error within the scope to where sits in the tree for example; if we place the error boundary at the App level, it will handle all errors that happen within the App component. In Gatsby we want to apply this error boundary at the root of the Gatsby application. The api we are going to use is called wrapPageElement.

Creating the error boundary

The first thing we want to do is to create a React component that handles when an error happens on the site. Since we are using Sentry for our logging we want to see if there's anything on npm already so we do not have to write any bespoke integration with Sentry. Luckily! Sentry does has an npm package called @sentry/react which provides an error boundary component for us already use. Here is an example of some UI component we have made which is passed into the Sentry's ErrorBoundary component.

import React from "react"

import { ErrorBoundary } from "@sentry/react"

import { Link } from "gatsby"



const Fallback = ({ error, resetError }) => (

  <div role="alert">

    <p>Something went wrong</p>

    <pre>{error.message}</pre>

    <Link to="/" onClick={resetError}><a>Try again</a></Link>

  </div>

)



const ErrorBoundaryContainer = ({ children }) => <ErrorBoundary fallback={FallBack}>{children}</ErrorBoundary>



export default ErrorBoundaryContainer

Once we have our component we need to add it to the page root in gatsby-browser.js.

import React from "react"

import ErrorBoundary from "`./src/components/error-boundary"

export const wrapPageElement = ({ element }) => (

  <ErrorBoundary>

    {element}

  </ErrorBoundary>

)

Testing that it works

If you wanna test this working simple throw an Error in your react application like this:

import React from "react"

const Component = () => {

  const [toggleError, setToggleError] = useState(false)

  if (toggleError) {

    throw Error('Component Error')

  }

  return <button type="button" onClick={() => setToggleError(true)}>Toggle error</button>

}

Visualising the errors in Sentry.io

Sentry has a really simple UI that displays when an error has happened on the site. Once that error gets captured it then gets displayed in the issues section.

When we click into the error it gives us a lot of information about the error such as the browser, operating system and error details that happened. I found this section really nice to work with and understand.

Setting up alerts that notify when an error has happened

The next thing we want to do is to alert someone when we get an error. Sentry has the ability to setup alerting that emails a member of the group.

In the example I made an error with the message of "I crashed!" and I wanted to send myself an email so when the error fires within a 5 minute rate limit I will be notified about it.

Conclusion

In summary, adding logging/error handling in your react application is really easy to do. Sentry handles a lot the heavy shifting for us and Gatsby provides us with an api to stick our error boundary at the root of the component. With very little effort and very high value I believe this is such a good tool to use when building customer facing websites.

Resources

Responsive fonts using css clamp()

Matthew Claffey — Mon, 30 Nov 2020 14:46:39 +0000

If you have wrote CSS for fonts before you have probably experienced having to introduce a lot of media queries for different breakpoints.

A designer will provide designs for mobile/desktop and then the developer ends up asking “what about tablet?”, sound familiar? The output of those decisions could end up like this:

:root {
  --heading-font-size: 3em;
  --heading-font-size-tablet: 6em;
  --heading-font-size-desktop: 9em;
}

body {
  font-size: 16px;
}

h1,
.h1 {
  font-size: var(--heading-font-size);
}

@media screen and (min-width: 48em) {
  h1,
  .h2 {
    font-size: var(--heading-font-size-tablet);
  }
}

@media screen and (min-width: 64em) {
  h1,
  .h2 {
    font-size: var(--heading-font-size-desktop);
  }
}

With technology changing so fast and new devices being released everyday our websites have to try and cater for those new screen sizes. Media queries solve only half the problem by setting fixed breakpoints at certain screen sizes. What if we could just make our fonts scale with no media queries and it’s implemented in one line of css? This is where CSS clamp() comes into the mix.

CSS clamp()

CSS clamp is a function that sets responsive unit sizes without any media queries. The function takes 3 parameters in this order:

min — Where to start scaling from
viewport width —The range determines how fast the min scales to the max based on the screen getting larger
max —when to stop scaling

clamp(min, viewport-width-unit, max);

Applying clamp() to our font example

When using clamp with fonts I tend to make the range to be the maximum container width so when the browser is wider than that container, the font is at its maximum size. In the diagram below it shows how this works. In my example, my container is 80em (1280px) and my maximum font for my heading is 9em (144px).

When the browser width is greater than 80em the maximum font size will be 9em. When the browser width is less than 80em my font slowly starts to get smaller and smaller until it has reached 3em. Once 3em is reached, the browser stops shrinking the font size. This is how it looks in code:

:root {
  --global-h1-size: clamp(
    3em, 
    calc(9 / 80 * 100vw), 
    9em
  );
}

h1,
.h1 {
  font-size: var(--global-h1-size);
}

Browser support

On CanIUse CSS clamp is supported in around 86.8% of browsers so it looks quite promising to use now in production code.

A fallback suggestion could be to use css supports to put back in the media queries or set another font-size property before so when the browser does not recognise the clamp function it falls back to a default font-size. It depends on your target audience and how much conversion those browser bring to your website.

// IE11 is 9/10 a large screen so fallback to large size feels like a good solution
font-size: 9em;
font-size: clamp(3em, 11.5vw, 9em);

Conclusion

And thats it! Using clamp makes your house styles for fonts a lot easier to manage across multiple screen sizes. I feel like this approach caters for a wider audience of device users where as the media query approach is quite fixed.

When I discovered this I was in the middle of making some house styles for my website and I literally was baffled from how little code you have to write to make it work. This gif described the moment…

Shia Labeouf Reaction GIF

Heres a link to my CodePen which shows clamp in action.

https://codepen.io/code-mattclaffey/pen/dypoyzq

Resources

https://vw.joealden.com/ — really handy calculator tool that calculates the breakpoint width based on the font size.

How to mock api calls in Storybook

Matthew Claffey — Mon, 21 Sep 2020 16:26:15 +0000

The other day I was building a storybook page component and I was having issues where the page had a useEffect hook that hit an api from the dev environment to populate the state. There was a few issues with this because the data I was getting back needed an Id so it could a lookup in the database to find the record relating to the Id.

This to me gave me a few red alerts because I couldn’t make my story look the way it would on the website. This blog post is about how you can work around that to enrich your stories and make them more effective when your components work with API’s.

Why shouldn’t you just use the dev API for storybook?

Maintaining page states

Very hard to maintain multiple page states as you have no control of the data that is coming back. So if you wanted to display an error from that api, you can’t do that with ease because the backend api controls what comes back.

Dependency on the database

The record could get deleted which will break your story. If you have visual regression tests it will be picked up but if not you could have a broke story for a while depending on how often the story gets worked on.

Needs real data for the backend to consume

Backend API’s have special requirements with what data you send in the body but all we care about is the different types of responses our page handles and thats hard to do when we have no control over it.

Storybook middleware

Storybook has a feature where you can setup API calls which can be used in your stories. Under the hood the middleware is an expressJS server so the syntax is really simple, for example:

.storybook/middleware.js

const express = require('express');
const bodyParser = require('body-parser');


const expressMiddleWare = router => {
    router.use(bodyParser.urlencoded({ extended: false }));
    router.use(bodyParser.json());

    router.get(/api/get-orders/:orderId, (request, response) => {
      if (request.params.orderId === 'error') {
        response.status(500).send('Something broke!')
      }

      res.send({ data: { text: 'hello world' } })

    })
};


module.exports = expressMiddleWare;

And thats it you have an api setup in storybook. If you hit that relative path on localhost:9001/api/get-orders/123 it will respond with a success and if you send localhost:9001/api/get-orders/error you have forced an error state in your api so you can create two stories for your page component. Here is an example to how it would look in your story.

export const withSuccessfulOrder = () => <Comp orderId="123" />
export const withErrorOrder = () => <Comp orderId="error" />

Handling environments

Some websites tend to have multiple api environments such as dev/staging/prod and they normally have an environment variable to define the api domain. So locally the frontend could be hitting the dev environment and then when that code goes into prod the api url is now the prod domain. It normally looks like this in your code..

fetch(`${API_URL}/get-orders/${orderId}`).then((res) => res.json())so on...

In storybook when we build our stories together the default env would need to be changed to api or whatever url you have setup in the middleware so the code replaces API_URL with our /api. Easy way to do this is by setting the env when you run the storybook build/serve command.

API\_URL=/api storybook build

Then the code that references that env var will be /api and the example about will be /api/get-orders/${orderId} .

Conclusion

That is pretty much it! We can now start writing more efficient stories that are a lot more dynamic and help us extend our development before switching over to testing it in the website. The benefits to mocking the apis in storybook are:

The state is in our control so we can make our stories more accurate by sending the data we expect to come back from the api.
It won’t change, the mock api won’t fall over or change behaviour like it could in a backend api.
Once an api contract is in place with the developer building it, you both can work at the same time with no dependency on each other.
Visual regression tests are more accurate.

Keeping your medium content fresh in your 11ty website using Github Actions and Netlify

Matthew Claffey — Sun, 26 Jul 2020 13:37:50 +0000

On my personal website I use Medium as my content platform so I can channel my content via multiple channels. This is great because it allows me to take advantage of medium’s rich text editor and the implementation is really easy to do in 11ty.

Tech Stack

Website

The website is built by a popular framework called 11ty which is just a simple static site generator that helps you build Jamstack websites. It gets the medium data at the build time so it can build the blog pages before deploying them to Netlify.

Problem

The problem with this approach is that my content has a dependency on Medium to trigger a webhook that will trigger my Netlify build but it doesn’t have anything like that unless you upgrade your account.

Solution

The requirement I gave myself was to have the ability to keep my content fresh on the site. I post blog posts every couple of weeks so for me having a build at the end of the day is more than enough for what I wanted it to do.

I needed to figure out a way to trigger a Netlify build everyday just to keep the blog content fresh on my website. Netlify has a feature called build hooks which allows you to hit a Netlify endpoint that will then trigger a Netlify build.

You can access the build hooks in by going to Netlify — Settings > Build & deploy > Continuous deployment > Build hooks.

Credit to Netlify website — https://docs.netlify.com/configure-builds/build-hooks/

Once the build hook is setup the next thing to do is to setup a Github action to hit this build hook endpoint every day or so. For example:

.github/workflows/main.yml

name: "Netlify Trigger - Get updates from Medium"

on:

schedule:

- cron: '0 0 \* \* \*'

jobs:

curl:

runs-on: ubuntu-latest

steps:

- name: curl

uses: wei/curl@v1

with:

args: -X POST -d {} https://api.netlify.com/build\_hooks/${{ secrets.NETLIFY\_BUILD\_HOOK }}

This takes around 20s…

Note — make sure the build hook id is stored in your Github secrets so no one can spam your Netlify builds.

Conclusion

The nicer approach to this would have been having a webhook that listens to an event from Medium to see when a new blog post has been added but to get you up and running a cron job daily seem to do the trick.

Resources

Build hooks with Netlify https://docs.netlify.com/configure-builds/build-hooks/
Run your Github Actions workflow on a schedule https://jasonet.co/posts/scheduled-actions/

Demystifying React Context

Matthew Claffey — Sun, 26 Jul 2020 11:33:16 +0000

Yesterday I spent some time learning about how to use the context and when I read the docs I thought, “this sounds extremely complex for something that does a simple thing”. I definitely felt like this at first:

After playing around with the code and learning more about the different ways of using it. I thought it would be good to share it with people who may feel the same as I did.

What is React Context?

Before this feature came out we had to pass our props down into each component and then repeat the same process again and again into our components. This becomes quite nasty over time and it can potentially end up with issues with the props being so deeply nested in our components.
React Context is built to solve all of our problems because it removes the need for us to pass props down into our components. Instead, the components will inherit the props when nested within a context provider.

Less talking, more coding!

Now let’s actually get some code up and running so we can see what the context is doing.

Step 1 — creating our context object

The first thing we have to do is we need to create our context.

As you can see in the code there is a method that is on the React module called createContext . Now this is in place we can either carry on and make our provider or we can set a defaultValue as a parameter in the createContext method.

The default value will only apply those values when a provider is not wrapped around the consumers. I will go into more detail on this in the defaultValue section.

Step 2 — Apply the provider

The createContext method gives the ability to use two components which are bound to the method which are Provider & Consumer . A provider is a component that gives the ability to set data which can be accessed by consumer components without passing any props.

The component only takes one prop which is called value.

Step 3 — Setup the consumers

The Consumer component is used to get data from the Provider which will then pass data into the components that live nested in theConsumer. There are 3 ways to implement a Consumer.

Method one — using the Consumer component

We now have added a Paragraph component which has the DataContext.Consumer inside. This returns a function that gives us access to the properties set in the Provider. This way is useful to do with components that do not need any logic. So how can we do this with a component that has logic?

Method number 2 — using this.context & contextType

In components that use classes there is another way you can get access to the contexts data. As you can see, when we create our class we have underneath it the Paragraph.contextType = DataContext; and what this will do is it will give the class a property call context which is how we get access to our values that our provider are passing down.

Method 3 — using hooks

Both solutions above do work and thats fine but we have to do two different methods to make it work for each component. useContext method is used to get the props from the context the same way as the two above but it is a lot simpler to look at. It looks very similar to the way you get props from this.props but the syntax differs a little because you’re calling useContext instead.

Wait Matt, what about defaultValue ?

As mentioned about I spoke briefly about how we can set defaultValues to our context and what this will do is if we do not have a provider wrapped around our components then our consumers will use the defaultValue that is set in createContext as a fallback.

We have removed the Provider from our paragraph and set the values that used to be in the value prop inside our createContext function. This took me so long to figure out.

Conclusion

I hope this made it a lot more clearer for everyone! Like I said I learnt this a few days ago so there is probably a lot more to the Context method. I hope this has cleared up some confusion over the topic as it definitely did confuse me at first.

Loading Fonts The FOUT Way

Matthew Claffey — Sun, 26 Jul 2020 11:21:53 +0000

How a font works in the browser?

Fonts have the potential to be extremely slow. The more you include the more it can impact multiple metrics such as page weight, page load, first paint and first contentful paint.

What performance issues can occur?

Chain requests

A chain request is when a resource that is required by another file instead of the document. When you add font-face inside a css file it will have a dependency on the css file to load before it can load the font in the browser. This can be a problem especially on slow connections because the HTML could take a second to load, then a second for your CSS and then an extra 1–2 seconds for the fonts to load. That is a total of 4 seconds where the user has not seen any text.
When the fonts are slow you can tell all of a sudden seeing no text and then a “blink” and they all appear in the browser. Which is known as FOIT (flash of invisible text).

What is FOIT

Flash of invisible text is when the text on a website is invisible and then when the fonts have loaded they appear on the page. The text is rendered on the page ready but the browser does not know what font to use until they have loaded. When loaded, the the browser will “re-paint” the screen and show the new font, see how FOIT works (does contain flashing images).
We want to remove this “blink” effect and try to have some form of content there so the user can get a feel for what message the website is trying to send quicker than having to wait for the font to load. This is called FOUT (Flash of un-styled text).

What is FOUT

Flash of un-styled text is a popular concept where the user will see the fallback font before seeing the main font that we load in. When implemented we no longer see the invisible font. See how this would work here (does contain flashing images).

Implementing FOUT on your website

So the easiest and quickest way on implementing FOUT is by using a css property called font-display. Font display is added to the font-face and it tells the browser what to do with the font when it is loading. You have a few values that you can have on this property but the main ones we want to do are:

swap — forces the browser to swap the font families out

Now let’s see what that would look like in our code...

Extra bonus points!

That is amazing we now get fonts in a little faster but if you are like me and want to make it blazingly fast lets dive deeper into what we can do. The way the fonts load is still the same. As mentioned above we have a chain request where the fonts are dependant on the css loading before it can load itself. Lets sort that out…

Embedding CSS

First thing we can do is embed our font-face css in the html document. Downside to this is not being able to cache the embed code but if your fonts are about 10–30 lines of css then it is not a massive problem.

For example:

Now what will happen is that the font will load regardless of the css. When the css has loaded, if the font has loaded by then it will swap the font font out faster.

Resource hints

The next thing we can do is use a resource hint called “preload”. Preloading a font will tell the network that this font wants to be loaded before anything else. The network will then treat the font as a critical resource and prioritise it when loading assets. Preloading is your friend, but preloading everything has the opposite effect and can make the site load normal again so make sure you prioritise which fonts you want to load. A good starting point is headings and body copy.

For example:

Preload is awesome to use on more than just fonts, the browser support is pretty good it is just ie 11 and Firefox that do not support the feature. Firefox does have this feature if you enable the feature under a flag in dev tools see more on CanIUse.

Hidden gems

Local property

This is a gamer changer! Especially if you are using fonts such as Helvetica on your website. On apple devices Helvetica is installed locally so when the user comes to your website you can tell your css to pick the local font over the one on your server. How neat right?

For example:

Note: make sure you add local first because the order is important on the src property.

Conclusion

So we have learnt about fixing critical requests in the browser, how to implement FOUT and how to add extra hidden gems to make your fonts load blazingly fast!

Lazy Loading Images 2020

Matthew Claffey — Sun, 26 Jul 2020 11:14:13 +0000

Lazy loading is a concept where you only load the images within the viewport of the device the user is in. As the user navigates around the site, images will load in on demand. This makes a massive improvement on the page weight, which then has a domino effect on the load time due to less requests coming in on initial load of the page.

Let’s go through how implementing the current way of lazy loading.

Implementing lazy loading

My go-to plugin is called LazySizes because it is really easy to setup, has multiple add-ons, features that extend the current functionality and it is lightweight. It has a mixture of ways of how to implement the script but in this example I am just loading it from git CDN.

Before implementing lazy loading we have two images, a plain img tag and a responsive image:

When implementing lazy loading for a standalone image it is pretty straight forward. All we need to do is add the lazyload class name to the image and then change the src attribute to data-src and that’s it! With picture elements it is a little different because you need to apply data-srcset to the source elements. Without it, they will load the image in regardless of the src on the image tag.

What do we do to make this SEO friendly?

Google crawls pages and get all of the images on the page to then put them in Google image search. It looks for the src attribute on the image but we have changed that to the data-src attribute for our lazy loading so they no longer able to put the images on image search.
Under the hood, LazySizes does some magic to make this work but as a safety net it is always good practice to provide a no JavaScript fallback.

If no JavaScript is enabled on a browser the user will not be able to see the images as there is a dependency on the images loading via our JavaScript library. So we need to add a fallback to make those images are visible. This is done with a mix of css/html/js, in the example below we:

add the no-js class to the html
add the css in the page to hide lazyload elements
add the JavaScript in which will remove the no-js class
finally, provide a noscript tag of the image in its previous lazy loading state

And that that is pretty much it, but we are in 2020 now and surely there is other ways of doing this right? My friend, let me introduce you to the native lazy load…

The future of lazy loading plugins?

Lazy loading has a new kid on the block which is called native lazy loading. Native lazy loading is a feature first released by Google Chrome which allows you to set lazy loading on your image. It is also now supported in the last two versions of Edge which leads to around 63% global coverage across all browsers.

It is really easy to implement, all you have to do is add an attribute on the img called loading and define one of the following as its value:

auto — default lazy loading behaviour of the browser which is the same as not including the attribute
lazy — defer loading of the resource until it is reached in the viewport
eager — load the resource as soon as behaviour regardless of where it sits on the page

Is it time to stop using lazy loading plugins?

I don’t think so, loading attribute only works for images and iframes but does not support background images. It also has a less aggressive threshold for loading images as it loads images in quite far down the page whereas lazysizes has a control to change the threshold for when you want the images to load in.

Can we use both? Absolutely!

We can check for native lazyload support in JavaScript which will then change all the data-src attributes to src attributes if the feature is supported.

If you need lazy loading for background images then it is okay to leave the lazysizes script in the page as if but if you only use it for images then it might be worth loading the script in when the feature is not supported.

Conclusion

In conclusion we still need to be using lazy loading plugins but the new native feature can work along side with these plugins which makes the transition over to native a lot more smoothly.

Resources

Addy Osmani— Native Lazyloading for the web — https://addyosmani.com/blog/lazy-loading/
Lazy Sizes — https://github.com/aFarkas/lazysizes
How to apply no js fallback — https://stackoverflow.com/questions/22203063/how-to-write-css-fallbacks-for-when-javascript-is-disabled
Responsive images — https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

How to reduce you html output in 11ty

Matthew Claffey — Sat, 25 Apr 2020 15:07:02 +0000

Minifying html is a really useful feature that can improve TTFB on the page and with 11ty it is very simple to do. In the eleventy.js config file we need to add a transform to the config which will check if the output is a .html file and if it is we will use an npm plugin called html-minifier to compress our html code.

Extra’s!

If you use CSS modules in a react project then this concept will be straight forward but for those who haven’t done this there is a way to shorten our css selectors and then that will get reflected in the html too.

Using a plugin posthtml-minify-css-classnames we can get our selectors shortened into small identifiers which will make our html output even smaller. This can be used with html, css and javascript inside the html document.

Before Vs After

In eleventy.js we need to apply the css class names change before we apply the minify on top.

Results (Fast 3G test)

In my example I managed to reduce my html output by around 11%.

Before I implemented this I had un-minified html and my css was in a seperate file.

Pro’s:

caching

Con’s

critical chain request
takes longer to load
unable to do it on a file basis it all needs to live in the html document.

After the implementation we managed to reduce the load of the html and css from 1.21s to 0.592s which is nearly a 50% reduction in time it took.

Resources

11ty How to minify your html output — https://www.11ty.dev/docs/config/#transforms-example-minify-html-output
html-minfier — https://www.npmjs.com/package/html-minifier
posthtml-minify-css-classnames — https://github.com/posthtml/posthtml-minify-classnames

My favourite talks at DotCSS Paris

Matthew Claffey — Mon, 23 Dec 2019 14:19:06 +0000

Day one was focused around CSS and each talk was truly inspiring. Here are a couple of talks that really stood out for me.

Conference main room (https://www.dotjs.io/)

Sarah Dayan — Utility based design systems

The first talk was about Utility based design systems. Sara explained how to build design systems/style guides more efficiently using the utility based classes. The talk went over how using utility based classes can not only improve performance on the CSS bundle but it can also provide a better html output via Gzip.

What I liked about this talk was the fact that Sara made the idea of using utility based classes very reasonable because it has performance benefits from a css/html prospective and to me thats a big win! Like any other developer, I hate repeating myself so if I can write those styles once and then use those class names wherever on the site it is a big win.

In Defense of Utility-First CSS by Sarah Dayan

Aurélien Levy- The double faces of CSS

This is the type of talk that everyone loves! Straight to the point with lots of juicy tips to take back and implement with ease. Aurélien Levy’s talk purely focused around what common a11y bugs he finds on websites he audits on a day to day.

The hidden gem I found in this talk was not to add display: contents; to any elements. Aurélien showed everyone what happens if you add that to your elements and it just completely changed the way the screen reader read out the content that lived within the element. What that property will do is that it will remove all the semantics from that element and just read out plain text. So for screen reader users, they will not know what they are currently on because it will just read out plain text. So definitely one to remember!

Emily Plummer — CSS & Developer Experience

This was by far my favourite talk of the day because of how relevant it is to what I am doing at the minute on my side project. Emily talked about how Github has managed to find a good balance between developer experience & customer experience and explains why it is good to have both. The talk was mainly focused around how Github implemented a design system and how it brought a fine balance between writing code the right way & delivering a product faster to our users. The main benefits that she went over were:

Delivery — developers had less things to worry about because the code was made up of small components which where plug in and play
Testing — each component was individually unit tested which would allow more frequent releases
Accessibility — bringing components into one single source of truth where the markup is only in one place really helped with keeping things accessible
Design consistency — similar to the above, with the css class names in one place meant that it was easier to keep aligned with the designs
Autonomy — a lot of the component logic was hidden within each component and had its own documentation

DOTCSS.pdf

Jason Pamental — Variable fonts and dynamic typography with CSS

Frontend developers face quite a few problems when it comes to implementing fonts. We have to consider:

Performance
Design Consistency
Accessibility

Finding the right balance between the fonts loading fast & them meeting design requirements can be a difficult problem to solve.

Modern browser now have a feature called variable fonts that can provide a better solution that ticks all the boxes for developers, designers but more importantly, the end users.

Jason’s talk is about how variable fonts can provide a better solution which meets the requirements mentioned above.

What is a variable font?

For people who are new to variable fonts it can be tricky to get a grasp around them. I definitely did!

A variable font is a collection of font styles all bundled into one font. For a website to have multiple font styles we would have to include a font for each style whereas a variable font you may only need to include the one that caters for all. Then after that we just need to add the css in and we are good to go with them!

Browser support for variable fonts seems to be at a decent 87.98% coverage too so it’s definitely something to play around with and try out.

What I liked as well about this is that Jason mentioned about how we can actually start using variable fonts now in the browser as the font safely falls back to using the normal fonts in browsers that do not support it.

Variable Fonts: opening the door to whole new typography

Dynamic Typographic Systems with Variable Fonts by Jason Pamental

Lightning Talks

Fabien Zibi — CSS tests

Now this I thought was a game changer, I have never thought you could write tests on sass functions and mixins but it turns out that you can quite simply with snapshots using Jest! Who knew!

Conclusion

Overall it was a top day and I would definitely recommend attending this conference as it had great speakers, great facilities, great food and also it had a couple of foosball tables! What more can you want from a conference? :)

Storing an array of elements using the useRef hook

Matthew Claffey — Sat, 10 Aug 2019 15:59:51 +0000

Storing an array of elements using the useRef hook
React refs are useful for when we have to set focus to an element after the user has interacted with it. In my case, I needed to use refs for setting focus to the correct accordion item when I selected/used arrow keys.

The problems I faced while doing this was a mixture of having issues with passing down refs into my components but also having one ref that represented an array of items just as you would in a none react app using document.querySelectorAll().

The problem

When there is only one ref we tend to simply assign our ref value with the variable that creates the useRef function.

const item = useRef(null)

<div ref={item}/>

In my use case I could not simply assign my ref to the element because the ref was being assigned within a map during the render. This would mean that the very last item in the array would be the element assigned to item.current.

The solution

The ref prop gives us the element as a parameter which allows us to assign the element however we want. In the example, we push that element into the itemsEls.current array so it can be used further down the line.

const itemEls = useRef(new Array())

{items.map(item => (
 <p key={item} ref={(element) => itemEls.current.push(element)}>{item}</p>
))

Note: The same approach applies for an object with ids as a key.

const itemEls = useRef({})

{items.map((item, index)) => (
 <p key={item} ref={(element) => itemEls.current[index] = element}>{item}</p>
))

And thats it! We can now store an array of refs in one variable to use when the use case crops up.

Note: this example of assigning a ref to a p tag is purely for simplicity of the code. A good use case for this is when building things that need focus applying to them when the user interacts with the component like an Accordion/Tabs/Modal.

import React, { useRef, useEffect } from 'react'
export const Component = ({ items }) => {
  const itemsEls = useRef(new Array())

  return (
    {items.map((item) => {
      const getRef = (element) => (itemsEls.current.push(element))
      return <p key={getRef}>{item}</p>
    })}
  )
}

Thank you for reading.

The PWA game

Matthew Claffey — Sun, 21 Jul 2019 18:52:40 +0000

Offline is becoming a standard thing to do in web applications because they allow your website to feel like an app. In the modern web most…

Continue reading on Medium »