DEV Community: Caleb!

[Boost]

Caleb! — Wed, 04 Jun 2025 14:50:19 +0000

Joshua Olajide

Jun 4 '25

When AI steals the joy of creating

#ai #contentwriting

Comments 23

5 min read

Automating npm package releases with GitHub Actions

Caleb! — Thu, 01 Feb 2024 04:09:24 +0000

I should have written this last year, after my talk at DevFest Ibadan 2023. But, I just couldn't get the GitHub workflow to run successfully. It was terrible.

So, recently, I finally figured it out by getting it to work in metadata

Getting started

To cut through the chase, the first thing you need to do is install the semantic-release package with your preferred JavaScript package manager.

yarn add semantic-release

Semantic-release combs through all your commit messages, analyzes them with the angular commit convention, and bumps your package version number with semantic-versioning in mind.

Creating a workflow

The snippet below is the basic setup of what you'd need to automate the releases of your npm package.

name: release

on:
  push:
    branches:
      - master

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout current branch
        uses: actions/checkout@v2

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: yarn

      - name: Build package
        run: yarn build

      - name: Semantic Release
        run: npx semantic-release
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
permissions:
  contents: write
  pages: write
  id-token: write

In your project directory, create a directory and name it .github, move into it, and create another one called workflows, then create a <workflow.yml> file.

In this case, releases.yml. You can call it anything you want. But I'd recommend that you give it a name that encapsulates what it is meant to accomplish.

You may not exactly need to specify any permissions since the GitHub Personal Access Token you'll generate has the repo_scope, so all these permissions could be enabled by default.

on:
  push:
    branches:
      - master

In the snippet above. This step of the workflow controls when and where the workflow runs. In this case, it only runs when a push event in the master branch occurs in your repository.

Make sure to change your branch name if it isn't master.

Creating environment variables

The important part of getting this to work is creating environment variables. This part stressed me so much.

For semantic-release to work it requires two environment variables, GH_TOKEN, short for GitHub Token, and NPM_TOKEN. Although, NPM_TOKEN can be optional, if you don't want it to publish your package to npm for you.

You can omit it if you want to take charge of doing npm publish by yourself. But, note that the workflow run would still fail on GitHub because the CI environment expects that token.

To bypass this, you can modify the Semantic Release step in the workflow to run in dry mode like so:

      - name: Semantic Release
        run: npx semantic-release --dry-run

The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, addChannel, success and fail. In addition to this it prints the next version and release notes to the console.

To get your GH_TOKEN go to your account settings and generate a Personal Acess Token. When you're done with that, go to the repository housing your package, click on the settings tab, in the sidebar, click on the "Secrets and variables" dropdown, then click on "Actions"

You should be on this screen by now.

When you're here, click on the green button to create a new repository secret and paste the PAT (Personal Access Token) you generated previously into the textaraea.

Make sure the name matches what you've set in the workflow file and vice versa.

To create an NPM_TOKEN log in to your npm account, if you have one, or create one by visiting npmjs.com/signup.

Click on "Access Token" from your avatar dropdown

You should be here by now. Click on "Generate New Token", it should open a dropdown menu with two options.

For the new security features npm released, it is recommended that you select the "Granular Access Token"

Provide the required details in the next screen. For more info about what to fill in or stuff about NPM access tokens, see this

Testing

When you're done with creating your tokens, make sure you add them as environment secrets in the settings tab of your repository.

Now that you're done with these processes, try creating a pull request or pushing directly to your default branch, you'll find out that a new tag has been generated in the repo.

You can click on the tags element.

It'll take you to this UI.

Click on your most recent tag. It'll take you to a new screen where you can "generate a release note" from the tag.

This is what a typical release note would look like when it is generated. I made some tweaks though.

Wrapping up.

Automating repeated processes can be fun, but no one tells you about the stress you'd have to go through to get them working sometimes.

It is a good investment if you get it right and worth the stress.

To see another example of automating workflows, you can take a look at how I moved a Husky pre-commit hook into GitHub Actions which in turn saved a lot of time while working in dev mode, it also covers a bit on how to deploy on Vercel with GitHub Actions.

All the metatags you might need for SEO in one React component.

Caleb! — Tue, 23 Jan 2024 12:07:26 +0000

Here's a React component that puts almost all the necessary meta tags you'd need for SEO in one place.

Why?

I can NOT entirely say that there's a motivation behind building this, to be honest. I was just tired of having to copy the same meta tags that I've been using for my blog whenever I share an article on the internet — mostly on social platforms.

What are the "perks" of using it?

Well... for one, you won't have to copy meta tags from one component to the other.

And if you're that person that goes: "I can just build this myself". Well, you're in luck. Because you don't have to do that.

<Metadata /> accepts a children prop, so you can still add other HTML tags that go into the <head> element.

<Metadata>
  <link href="style.css" />
</Metadata>

Usage

You can use the component by installing it from the NPM registry.

yarn add metadatah

Import the component into any of your pages, or wherever it is needed like so:

import { MetaData } from "metadatah";

export default function pageComponent() {
  return (
    <>
      <MetaData
        pageTitle="Homepage"
        url="your-website.com"
        description="description of the page"
        previewImage="path-to-image or a remote link to where it is located."
      />
      // rest of the page content falls below
    </>
  );
}

pageTitle, url, previewImage and description are required props.

contentType helps you describe the type of content you share. Is it a blog post, pictures, videos, or whatever you want really. By default, the value is "website", since it is assumed that you're using this component on the web.

There's a list that covers all the available values here

Optional props

contentType: accepts either "article" or "website" as values
contentLanguage: can be used to change the language of your content. Defaults to "en_US" if none is specified.
children: include additional meta tags if you like.

Drawbacks.

The component doesn't work quite well in Next.js projects. There's an issue open to track this. If you want to contribute, feel free to do so.

Building an npm package in 2023

Caleb! — Wed, 14 Jun 2023 09:14:51 +0000

Building an npm package requires a lot of decisions that need to be considered. From choosing a default bundler to selecting an appropriate transpiler to understanding the use case of the tool or package, or I dare say, a library — you're creating.

A whole lot of thinking goes into this process than the actual process of writing the code. Yes, sometimes, this whole "deep thinking" charade may not even be necessary. But, it is important that you have it at the back of your mind.

Webpack, the oldie

Years back, one approach towards building these packages was completely dependent on the use of webpack as the go-to bundler, which also comes with a lot of plugins that can be used to bundle your JavaScript code.

But, Webpack has a lot of complexities attached to it. When I tried using it a few times, I'd always get frustrated at the number of things that flew around in the config file, I even wrote an article about my travails.

Note: My aim here isn't to rant about webpack, but to provide a more subtle approach towards building these packages, and publishing them.

A lot of folks may come for my opinions here, and bring up that famous quote "Webpack is for building apps, the others are for building libraries".

But, I think what a lot of folks are missing out here, is the good DX — Developer Experience — that the "other" bundling tools have when compared to webpack.

Yes, webpack gives you a lot of functionalities. Okay, good. But at the detriment of my sanity?

As I mentioned before, the purpose of this article somehow revolves around the mistakes I made and how I bypassed them.

For some days now, I've been working on a React Tab component that preserves the state of each Tab (or nav items) when it is clicked upon and when you navigate away from and back to where this component is mounted.

Working on it affirmed a question that I've always pondered on, for a very long time. "Can we keep component state in the browser URL?"

You should try using the package and let me know what you think.

I wrote a short piece on why you might not need a state-management library, as it establishes the proof-of-concept for this component. Take a look in your spare time.

Now, onto the matter at hand, npm packages.

From the things I've done in the past, I think I can conclude that you should use the typescript compiler — tsc — as your bundler when you decide to build an npm package that isn't in any way similar to a component library or package that depends on some sort of styling with CSS.

An example is this helper function — that extracts the heading texts from any markdown file — I worked on a while back. You can take a look at the configuration of the compiler here

Let me walk you through the essence of this config. It is the same as the one from the repo.

{
 "include": ["src"],
 "exclude": ["node_modules", "dist"],
 "compilerOptions": {
 "lib": ["ESNext"],
 "module": "ESNext",
 "sourceMap": true,
 "importHelpers": true,
 "declaration": true,
 "rootDir": "./src",
 "outDir": "./dist/esm",
 "strict": true,
 "noImplicitReturns": true,
 "noUnusedLocals": true,
 "noUnusedParameters": true,
 "moduleResolution": "node",
 "jsx": "react",
 "esModuleInterop": true,
 "skipLibCheck": true,
 "forceConsistentCasingInFileNames": true
 }
}

include specifies the files or directories that should be included when compiling the TypeScript code. In this case, for that helper function, it includes the src directory. Yours could be different.

exclude specifies the files or directories that should be excluded from the compilation process. Here, it excludes the node_modules and dist directories.

In the compilerOptions section, there's the lib property that ensures the specific libraries that should be included in the compilation process.

Here, it includes the "ESNext" library, which provides the latest ECMAScript features.

The module property determines the module system to use. In this case, it's set to "ESNext", which enables the use of modern JavaScript modules.

sourceMap enables the generation of source maps, which are useful for debugging TypeScript code in the browser or in development tools.

The importHelpers enables the import of TypeScript helper functions to assist with certain features like decorators and async/await.

declaration generates corresponding .d.ts declaration files alongside the compiled JavaScript files, allowing for type checking and code completion in other TypeScript projects that consume this code.

rootDir specifies the root directory for TypeScript source files. Here, it's set to the src directory. Again, yours can be completely different.

In the recent package, I worked on. I set mine to packages because the library will have many use cases for different components, supposedly.

outDir determines the output directory for compiled JavaScript files. In this case, it's set to the dist/esm directory.

strict enables strict type checking and stricter compiler options.

noImplicitReturns reports an error when a function has a missing return statement.

noUnusedLocals This reports an error when a local variable is declared but not used.

noUnusedParameters This reports an error when a function parameter is declared but not used.

moduleResolution specifies how TypeScript resolves module imports. Here, it's set to "node", which uses Node.js module resolution.

This part tends to be very frustrating at times.

jsx determines the syntax used for JSX. In this case, it's set to "react" to support React JSX syntax.

esModuleInterop enables interoperability between CommonJS and ES modules, allowing for easier importing of CommonJS modules in TypeScript.

skipLibCheck skips type checking of declaration files (*.d.ts) from dependencies, which can improve compilation speed.

forceConsistentCasingInFileNames enforces consistent casing of filenames, which can help prevent issues when working on different operating systems.

You do not have to use this config strictly if you don't want to. You are free to set up whichever one works for you.

Enter, Rollup.js

Rollup is a bundler for JavaScript applications and it is by far the most recommended tool to use if you want to build a component library or any npm package, because of its intuitive and straightforward process of onboarding devs when compared to webpack.

The good thing here is that you can use Typescript and Rollup together when you want to build an npm package. especially one that depends on styling.

All you'd need to do is find the right plugins. When I set out to build the react-tab package, I started with Typescript's compiler, tsc as my bundler.

But, it brought a lot of limitations, because, it couldn't extract and handle CSS outputs correctly. Since Rollup has an ecosystem of plugins that I could use, doing research and finding the appropriate ones were not too strenuous.

Remember how I also talked about the "thinking" that goes into creating an ideal package?

If the npm package you set out to build is in one way or another other dependent on using CSS, you may want to consider choosing an approach that you'll take.

Some people like going with CSS modules, some with scss or Sass, and some with plain 'Ol CSS. I used styled-components for react-tab

"Why would you even do that? There are so many limitations with styled-components"

I'll get to that later. My point here revolves around those little edge cases. For example now, if you decided to use CSS modules for a package whose major end user(s) are likely to use it in a Next.js project, you'll have some issues to deal with.

Going with styled-components was a wise decision for me, since the Tab components are meant to be intuitive and completely customizable for developers. I needed to expose some certain style props.

And it is no new thing that you can extend the props of a component when using styled-components.

// component.styled.ts
import styled from "styled-components"

type themeProps = {
 theme: string
}

export const Container = styled.div<themeProps>`
 background: ${({theme}) => theme ? theme : "brown"}
`

Container then becomes something similar to the snippet below. This is just the tip of the iceberg of what can be achieved with this CSS component-library

<Container theme="purple">
 // children
</Container>

But, the limitations still persist. Because, and as I mentioned previously, typescript's compiler cannot properly handle the outputs of styles that'll be bundled together onto the component, Rollup swoops in to save the day.

The source of truth — rollup.config.js

It is a common practice for most bundlers to have a config file that sorta controls how the application is chunked, crunched, compiled, and any other action that goes on behind the scenes.

An example of a config file can be seen below. This one exports the entry point — input — of the application and the output directory.

export default {
 input: "packages/index.ts",
 output: {
   file: "dist/index.js",
   format: "cjs"
 }
}

Since, react-tab uses an external dependency, next/router to be precise, an "unresolved dependencies" warning will be logged when I try to build the package with the rollup -c command.

Rollup treats dependencies differently based on their import paths. When it encounters an import that starts with . or /, it assumes it's a local file and resolves it accordingly.

However, when the import starts with a module name, such as next/router, it treats it as an external dependency that should be resolved by whoever uses the package.

To bypass this warning, I had to specify that next/router is an external dependency in my rollup config.

This same approach applies to you, once you've identified the external packages that your application/library depends on.

export default {
 input: "packages/index.ts",
 output: {
   file: "dist/index.js",
   format: "cjs",
 },
 external: ["react", "react-dom", "next/router"],
}

Recall when I mentioned something related to the limitations of styled-components? Here's the issue with it.

When using styled-components in a shared component or library, you should keep three things in mind to ensure that the styles are applied correctly when the package is consumed by other projects.

listing it as a peer dependency : I had to make sure that styled-components is listed as a peer dependency in my package.json file.

This informs consumers that they need to have styled-components installed in their own project to properly utilize your component.

If you do not have it that way in your package.json file, you can do so by modifying the peerDependencies property with the generatePackageJSON plugin like so:

generatePackageJSON({
 outputFolder: "dist",
 baseContents: (pkg) => ({
   name: pkg.name,
   main: "/dist/index.js",
   peerDependencies: {
     react: "^18.2.0",
     "styled-components": "^6.0.0-rc.3",
   },
  }),
})

CSS extraction: By default, styled-components applies styles by injecting them into the DOM at runtime.

However, when building a shared component library or package, it's best to extract the styles during the build process, so they can be bundled and used by the consuming project.

To achieve this, I had to use a tool like babel-plugin-styled-components along with the Babel plugin in my rollup config

babel({
 extensions: [".ts", ".tsx"],
 exclude: "node_modules/**",
 presets: ["@babel/preset-react", "@babel/preset-typescript"],
 plugins: ["styled-components"],
}),

CSS output: there's a rollup plugin — rollup-plugin-styles — that should be included in your config file, so long as you're writing anything that is transpiled down to CSS.

The plugin ensures that the styles you'll be writing are properly extracted.

export default {
 input: "packages/index.ts",
 output: {
   file: "dist/index.js",
   format: "cjs",
 },
 external: ["react", "react-dom", "next/router"],
 styles(),
}

In the peerDependencies property, the exact version of the dependencies was hard coded. But, there is a way to ensure that the peer dependencies are automatically updated to the latest compatible versions without hardcoding them manually.

You can use the latest tag in the version range of the peer dependencies.

peerDependencies: {
 react: "latest",
 "styled-components": "latest",
},

By using the latest tag, it will automatically fetch the latest version of the peer dependency that satisfies the specified version range.

This way, you don't need to manually update the versions every time there's a newer compatible version.

When users install your package or when they run npm install or yarn install, the package manager will fetch the latest compatible versions of the peer dependencies based on the version range specified in your package.json.

But — there's always a but — keep in mind that using the latest tag can also introduce potential breaking changes if a new major version of the peer dependency is released and it includes breaking changes.

To mitigate this, it's a good practice to thoroughly test your package with the latest versions of the peer dependencies before releasing a new version.

Here's what the complete rollup config looks like:

import babel from "rollup-plugin-babel";
import commonjs from "rollup-plugin-commonjs";
import generatePackageJSON from "rollup-plugin-generate-package-json";
import { nodeResolve } from "@rollup/plugin-node-resolve";
import styles from "rollup-plugin-styles";
import { terser } from "rollup-plugin-terser";

const dev = process.env.NODE_ENV !== "production";

export default {
  input: "packages/index.ts",
  output: {
    file: "dist/index.js",
    format: "cjs",
  },
  external: ["react", "react-dom"],
  plugins: [
    nodeResolve({
      extensions: [".ts", ".tsx"],
    }),
    babel({
      extensions: [".ts", ".tsx"],
      exclude: "node_modules/**",
      presets: ["@babel/preset-react", "@babel/preset-typescript"],
    }),
    generatePackageJSON({
      outputFolder: "dist",
      baseContents: (pkg) => ({
        name: pkg.name,
        main: "/dist/index.js",
        peerDependencies: {
          react: "^18.2.0",
          "styled-components": "^6.0.0-rc.3",
        },
      }),
    }),
    terser({
      ecma: 2015,
      mangle: { toplevel: true },
      compress: {
        toplevel: true,
        drop_console: !dev,
        drop_debugger: !dev,
      },
      output: { quote_style: 1 },
    }),
    commonjs(),
    styles(),
  ],
};

And here's what the important part of the package.json file entails. It specifies the build configuration and script for the react-tab package.

You can adopt it to suit your use case.

{
 "main": "./dist/cjs/index.js",
 "module": "./dist/esm/index.js",
 "types": "./dist/esm/index.d.ts",
 "scripts": {
   "build:esm": "tsc",
   "build": "yarn build:esm && yarn build:cjs",
   "build:cjs": "rollup -c"
 },
}

Here's a breakdown of the snippet;

"main": "./dist/cjs/index.js" specifies the entry point for CommonJS (CJS) modules. When someone imports your package using require() or import in a CommonJS environment, this is the file that will be loaded.

"module": "./dist/esm/index.js" specifies the entry point for ECMAScript Modules (ESM). When someone imports your package using import in an ESM-supported environment, this is the file that will be loaded.

"types": "./dist/esm/index.d.ts" specifies the location of the TypeScript declaration file (.d.ts).

This file provides type information for your package, allowing TypeScript users to get type-checking and autocompletion when using your package.

"build:esm": "tsc" runs the TypeScript compiler — tsc — to build the ESM version of your package. It compiles the TypeScript code into JavaScript and outputs the files in the ./dist/esm directory.

"build": "yarn build:esm && yarn build:cjs" runs the build:esm script first, and then executes the build:cjs script.

It ensures that both the ESM and CJS versions of your package are built.

"build:cjs": "rollup -c" runs the Rollup bundler — rollup — with the configuration file (-c).

Rollup reads the configuration file to bundle your code, applying any specified transformations or optimizations. The output is generated in the ./dist/cjs directory.

testing locally before publishing.

This part is somewhat tricky as it may somehow affect the versioning process of your tool.

Instead of running npm publish anytime you make a significant change, you should instead link the package with npm link

If you're on any Linux distro OS, you'll have to append sudo to npm link to grant permissions. This ensures that a symlink is created for the package.

Then you can proceed to link the package in another project where you want to use it like so.

npm link package-name

wrapping up.

Inasmuch as the intent of this article isn't entirely to walk you through the process of building a component library by following some steps, below are some resources that may help you accomplish your aim.

How to Publish to NPM the Right Way

How to build a component library with React and TypeScript

Component library setup with React, TypeScript and Rollup

Easily build and publish a React / Typescript component library package to Npm using Storybook and Rollup.

How to add a "load more" button to your blog

Caleb! — Mon, 06 Mar 2023 10:26:20 +0000

Last week, I added some features to my blog. From the preloader that utilized Next.js' router API, to the search and Table of Content component.

Recently, I've just added a minor feature that allows me to conditionally render a certain amount of articles on my blog. Instead of having all the articles I've written all at once on the page.

This feature is a bit common on some developer blogging platforms., and building it was a bit straightforward since I knew what needs to be done.

The idea behind it is for us to have an initial amount of articles listed whenever anyone navigates to the blog route. So, a variable like the one below should suffice

const initialPostList = 6

And whenever a visitor clicks on the "load more" button, a callback function is triggered to increment the number of articles/posts on the blog.

It'll be ideal to also have another variable that holds the increment value. A variable like the one below should work fine.

const incrementInitialPostList = 4

Watching the state

The snippets in the previous section are of great importance to this feature. initialPostList holds the amount of articles we want on initial render of the blog page, while incrementInitialPostList holds the value with which the articles list would be incremented.

With that said, some of the snippets here may look unfamiliar or intricate. If you happen to feel this way, when you're reading this, I'd implore you to check out this article that walks you through how to build a Next.js blog

I'm assuming you already have an idea of some Next.js data-fetching patterns, If not, please, take a look at the link I shared in the paragraph above.

I needed a way to keep these values — initialPostList and incrementInitialPostList — in the blog component's state, so that I can tap into its lifecycle methods .

The snippet below shows what the Blog component looks like.

import Article from './Article'; // Replace with your own Article component

const initialPostList = 6; // Number of articles to display initially
const incrementInitialPostList = 4; // Number of articles to add each time the "load more" button is clicked

export default function Blog() {
  const [displayPosts, setDisplayPosts] = React.useState(initialPostList);
  const [articles, setArticles] = React.useState(/* Your array of articles goes here */);

  const loadMore = () => {
    setDisplayPosts(displayPosts + incrementInitialPostList)
  }

  return (
    <div>
      {articles.slice(0, displayPosts).map(article => (
        <Article key={article.id} article={article} />
      ))}
      {displayPosts < articles.length ? ( 
          <button onClick={handleLoadMore}>Load More</button>
      ) : null}
    </div>
  );
}

Rendering more posts

In the snippet from the previous section, I'm using initialPostList variable to render the first 6 articles and adding the incrementInitialPostList variable to represent the number of articles to render each time the "load more" button is clicked.

The loadMore function simply updates the displayPosts state variable with the new value.

The articles array can come from any data source you like (e.g. an API endpoint, a static file, etc.), and you can customize the Article component to match the structure of your data.

But, in this case, it is coming from a markdown source, and I can get the list of articles with getStaticProps, a data-fetching method of Next.js

The blog component is modified like so;

export default function Blog({ posts }) {
  const [displayPosts, setDisplayPosts] = React.useState(initialPostList);
  const [articles, setArticles] = React.useState(posts);

  const loadMore = () => {
    setDisplayPosts(displayPosts + incrementInitialPostList)
  }

  return (
    <div>
      {articles.slice(0, displayPosts).map(article => (
        <Article key={article.id} article={article} />
      ))}
      {displayPosts < articles.length ? ( 
          <button onClick={loadMore}>Load More</button>
      ) : null}
    </div>
  );
}

export async function getStaticProps() {
  let articles = await getAllArticles()

  const sortedArticles = articles.map((article) => article)

  sortedArticles.sort((a, b) => {
    return new Date(b.publishedAt) - new Date(a.publishedAt)
  })

  return {
    props: {
      posts: sortedArticles,
    },
  }
}

The slice function is used to only display the first item in the posts array through the value of the displayPosts value — which is 6 — from the articles array.

The displayPosts < articles.length condition is used to check if there are more articles to display and show the "load more" button accordingly.

From @nlxdodge's comment below, I found an approach that helps you preserve the state when you navigate to, and away from the page.

Take a look at it here

Improving image performance on the web.

Caleb! — Wed, 22 Feb 2023 10:08:29 +0000

I’ve been benchmarking the performance of my blog for a while now, and there's no doubt that the cover images I'm using are going to keep having a negative impact on the overall interactivity of the blog. I want to change that.

Although, I've already tried — and I'm still using — an image CDN like Cloudinary to automate the process of optimizing these images on the fly.

I still want to retain the quality, and also convert these images to modern image formats like WebP and AVIF which are acceptable on web browsers that support these said formats. I ended up having a URL like the one below;

https://res.cloudinary.com/meje/image/upload/f_auto,q_70/v1668161028/image.jpg

Cloudinary provided a way for me to convert the images to modern image formats with the f_auto flag, and the q_auto flag to set the quality of the image without having to manually compress the image by myself. In the link above, you'll notice that I appended a value — 70 — to the q flag, to reduce the quality.

The tradeoff of this approach is that, as you're "optimizing" for faster page loads, and a very good TTI — Time To Interactive — score, the more you reduce the quality of these images, you're going to get less "enormous network payload" errors.

What I am saying here, in essence, is, when you reduce the quality of an image, You somehow reduce the size, this is probably a result of the compression algorithm that is being used here.

There are Lossless image compression algorithms that you can use out there too, without trading the quality of your images for lesser network payloads.

I'd say that a proper OR recommended approach towards optimizing images for the web is to manually compress them with compression tools like TinyJPG or Squoosh before uploading them to your favorite image CDN. Why? you'd ask me.

This is because after you've compressed your images with a tool that doesn't use a Lossy image compression algorithm, you'd still retain the quality of your images and a substantial reduction in the size of your image without losing the important components of that image's data.

It is a win-win situation for everyone.

Serving images locally.

Another approach would be to have all the images you want in the same codebase/repository so you can access them without making unnecessary fetch calls to a remote server.

But, the important thing to note when using this approach would be the manual optimization of these images before you use them. So, the method of doing this would be similar to how we normally reference images in plain 'Ol HTML with the image element.

<img src="public/image-name.png|jpg|webp|avif" alt="image description" />

Since this approach of serving images locally can help eradicate the complexities of preconnect-ing to the domain of the Content Delivery Network (CDN) of an image service provider like Cloudinary and its other counterparts: ImageMin, Akamai, etc.

It provides a better way to avoid unnecessary large network payloads and reduces the time taken for these requests to be processed by the browser, hence, delivering an optimal experience to the users of your website.

When you don't use the "preconnect" value of the rel attribute in the <link /> element, the browser isn't completely aware of the appropriate magnitude of importance to give to these images when fetching them.

<link rel="preconnect" href="res.cloudinary.com" />

Prioritizing the requests of image assets.

There's an update in the latest web standards that allows us to add a fetch priority to images.

This idea was also implemented in the native fetch API of the browser, the idea behind this was to be able to manipulate or re-order the way various browsers parse and fetch the resources of a web page.

And, as images are a vital part of any website that uses them, they have to be given utmost importance.

An example of this use-case is with the LCP — Largest Contentful Paint — element of a website, which happens to be an image element most of the time.

<img src="public/image-name.png" alt="image description" priority="high" />

In Frontend frameworks like Next.js the next/image component accepts a boolean fetchPriority prop, Take a look at it below;

import React from 'react'
import Image from 'next/image'
import imageSource from 'path/to/image'

export default function ExampleComponent() {
  return <Image src={imageSource} height={100} width={100} priority={true} />
}

The priority hint feature ensures that browsers fetch resources that are important for the usability of software — web apps & websites — on the web, and these priority hints can be used when we're carrying out native fetch operations to speed up the process of getting the image resources.

Aside from the fact that we're already preconnect-ing to the image service provider's CDN. The priority object can receive any of these values: high, low, and an empty string.

The absence of a priority property in the fetch options resolves to the default method of fetching the images.

An example of this in action can be seen in the snippet below, where I'm utilizing the API routes in Next.js to generate a blurred version of the images on my blog as placeholders.

You'll notice how I assigned the "high" string to the priority property.

export const imageDataURL = async (url) => {
  const data = await fetch(url, { priority: 'high' })
  const blob = await data.blob()

  return new Promise((resolve) => {
    const reader = new FileReader()
    reader.readAsDataURL(blob)

    reader.onloadend = () => {
      const blurData = reader.result
       resolve(blurData)
      }
    })
  }
}

Rendering responsive images

To further reduce the performance implications caused by images on a website, you'd need to start considering an approach that allows you to build for everyone.

Everyone in the sense that you'd need to factor the devices of the users of your app into your process, as you do not want to ship an image that does not correspond with the DPR — Device Pixel Ratio — of your users in production.

Say an image has a dimension of 350px by 768px, and you're sending this image as is, to the user on a mobile device with a viewport dimension of 260px by 550px.

This means that the mobile browser of the user's device would still have to download that image with an aspect ratio that does not correspond with its viewport dimensions, and if I'm not wrong, the dimensions of an image have an effect on the image's size.

When you ship images that are not responsive — responsive in this sense doesn't have to do with the layout of such images.

It refers to how the dimensions of an image are appropriately returned while considering the DPR of your end users — your website has a sudden, and unfavorable impact on the mobile data plans that they're currently on because they'd have to download the image that is not pruned down to their current device width.

The conventional way of accomplishing this feat would be to have multiple images, for various viewport breakpoints, with different dimensions, and in turn pass them in the srcset attribute of the native <img /> element, like it is in the snippet below.

But, for this to work appropriately, you'd need to add the sizes attribute in the image element too.

<img
  src="image.jpg"
  alt="image description"
  sizes="(max-width: 768px) 100vw, (max-width: 1200px), 50vw, 33vw"
  srcset="
  image,w_200.jpg 200w,
  image,w_591.jpg 591w,
  image,w_882.jpg 882w,
  image,w_1056.jpg 1056w,
  image,w_1259.jpg 1259w,
  image,w_1344.jpg 1344w,
  image,w_1400.jpg 1400w"
/>

The sizes attribute in the snippet above can be used for layouts that have a list of cards with images in them in a 3-by-3 pattern. A vivid example can be seen on my blog, you can also take a look at the image below;

At a max-width of 768px, the image spans the full width of its parent container, and on desktop screens, or larger screens, it takes half the width of the viewport, with respect to the parent container.

You're probably wondering: "So, I am expected to manually create different images for different viewports? All this stress just for the benefit of an end user?" Well, YES, all this stress for the benefit of an end user, and NO, you don't really have to manually create these images.

Cloudinary has a responsive image breakpoints generator that you can use for this sole purpose.

All you have to do is upload the image of your choice, and set the appropriate breakpoints in the UI, and it'll generate the markup that you can add in the srcset attribute.

Compatibility with Frontend frameworks

I'm pretty sure the process of creating images that corresponds properly with the Device Pixel Ratio (DPR) of mobile devices is somewhat similar to how it would be done with the native HTML <img /> element.

But, the case is different when creating these images in a typical Next.js app.

Although there's an approach that can be followed through from their docs, it requires you to edit the next.config.js file with an array of deviceSizes and imageSizes properties like the one below;

module.exports = {
  images: {
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
  },
}

The snippet above is the default configuration, if you don't specify them explicitly in your config file, Next.js falls back to that config.

But, the catch here is, even when I didn't specify these properties in my config file, one would think everything would work fine, right? Well, I was wrong, when I checked my blog's page speed insight, I kept getting this error below, despite the fact that I've also added my array of images via the srcSet attribute.

I found out from a discussion that I started in the Next.js GitHub repo that the srcSet propType was omitted because Next.js automatically optimizes your images for you.

Still, their optimization approach did not suit my use case, since I have already optimized my images with Cloudinary, I needed a way to ship images with their appropriate sizes on various device widths.

The snippet below is an excerpt of how the srcSet attribute is ignored in the Next.js image component.

if (unoptimized) {
  return { src, srcSet: undefined, sizes: undefined }
}

const { widths, kind } = getWidths(config, width, sizes)
  const last = widths.length - 1

  return {
    sizes: !sizes && kind === 'w' ? '100vw' : sizes,
    srcSet: widths
      .map(
         (w, i) =>
          `${loader({ config, src, quality, width: w })} ${
               kind === 'w' ? w : i + 1
           }${kind}`
          )
         .join(', '),
   }
}

And a way to fix this would require you to set the boolean propType, unoptimized to true, in the Next.js image component, like so:

export default function Card({ data: { title, cover_image, imageSet } }) {
  return (
    <Wrapper>
      <div className="cover-image">
         <Image
           alt={title}
           src={cover_image}
           height={65}
           width={100}
           layout="responsive"
           placeholder="blur"
           blurDataURL={blurHash}
           priority={true}
           srcSet={imageSet}
           sizes="(max-width: 768px) 100vw, (max-width: 1200px), 50vw, 33vw"
           unoptimized={true}
         />
      </div>
    </Wrapper>
  )
}

PS: This approach of serving responsive images may have changed since the release of Next.js 13, and there’s been a vital improvement to the Image component. Do check it out first, before you try using this approach.

Improving Cumulative Layout Shifts

One more way to add a tiny improvement to the performance of your images would be to consider greatly, the CLS — Cumulative Layout Shift — that these images themselves, cause, on initial render.

This performance metric is among the many metrics that reduce your lighthouse score and somehow affect your page speed insights too.

An approach to fixing this image performance issue would be to use the aspect-ratio CSS property on the img element.

The property determines the ratio between the image’s height and width property — a bit related to the Device Pixel Ratio you saw in the previous section — instead of explicitly setting the exact dimensions of the image.

img {
 aspect-ratio: 1/1;
 width: 100%;
}

You can read more about the values the property receives here

The good thing about this approach is that, before the image resource(s) is fetched from the remote server, the browser gives a ratio of the space the image is expected to occupy.

So if you have an image element in a div with texts above and below it. The image’s space is reserved as is, until it is completely fetched by the browser.

Since the goal to design and build for everyone should be our priority as Engineers, one way to sort of provide a good user experience for people would be to add a perception for the person visiting your site that a particular image is still loading.

Rather than having a large space in the component, you can set a background for the image, so that people are aware that an element will be there in no time.

The image below illustrates what it looks like on my blog.

With the Next.js image component, you may not need to specify an aspect ratio when you’re styling the component, all you may just need to do, is add a background to the element.

Final Thoughts

Optimizing your images before using any image CDN can help reduce those enormous network payloads, and by doing so, it reduces the time taken for your page to be interactive.

I sometimes, refer to this process as having multiple layers of optimization and or compression of these images to modern web image formats.

A great tool I’ll recommend is Squoosh because it provides a lot of customization for you when you want to optimize your images with its lossless image compression algorithm.

My fair share of rehydration in React.

Caleb! — Sat, 22 Oct 2022 12:32:32 +0000

I've always been fascinated by the kind of work that people like Kent C. Dodds and Josh W. Comeau put out there in the field of Developer Education. This article encompasses how my curiosity almost landed me in a very deep and recursive process of debugging to no avail for almost two days, but, that's sort of what we do right? — getting stuck over and over until we find a possible fix to a problem. LOL!

Okay, enough with the story, "My fair share of rehydration in React" you'd have probably muttered to yourself. Well, all these started when I took a look at Kent's Blog, and I loved how simple the UI of the featured-article card appeared, but that was not the only thing. I figured out that when I refreshed the page, the featured article changed, immediately, I made the "wow this looks sooo cool" face.

I thought to myself, I can recreate this on my blog too, little did I know that it will appear a little bit more complex than how I first perceived it to be, then. Nonetheless, I embarked on this arduous journey.

Thinking in React

I read the first module — Thinking in React — on the beta version of React's documentation website by Dan Abramov. The whole idea behind — or at least, what I perceive it to be — this, is for us to be able to understand and develop a mental model for problem-solving, that way, we can always attempt to proffer solutions to similar problems without having so many blockers, rather than just jumping into the process of writing the code.

Establishing the mental model, or pattern of implementing this feature took almost three pages in my notebook, as simple as the solution is, yes. I see my mental model as a decision tree, though. The first thing I knew that I had to do was to create an entirely new UI that would take in the featured-article data which I'm pulling with Next.js' server-side data-fetching method, getStaticProps().

Creating the layout of that component wasn't the issue, and neither was the process of returning the latest article by selecting the first index in the array of blog posts. I recalled that the moment I refreshed Kent's blog, the featured article is a new one, completely different from what was there during the initial page load.

I became awestruck, again! How do I implement this exactly? I figured out that the best solution I can use for the implementation of this feature was to rely on JavaScript's Math.random() method. I'll pull data from the posts prop via getStaticProps(), assign it to a variable, and multiply it by the length of the array.

export default function BlogPage({ posts }) {
  const randomFeatured = Math.floor(Math.random() * posts.length)
  let featuredPost = posts[randomFeatured]

  return (
    <React.Fragment>
      <FeaturedCard data={featuredPost}>
    </React.Fragment>
  )
}

The randomFeatured variable returns a number between 0 and the length of the array. Say, for example, I have a total of ten blog posts, and I'll be getting a number between 0 and 9. Next thing was to access that random number with the posts array, like so;

let featuredPost = posts[randomFeatured]

"Whew! that was easy" was the phrase I muttered to myself until I got stuck. But, let's not go there yet. I decided to make my whole idea behind the implementation of this feature to be around this: I want people to come to my blog and read the articles there without having to keep scrolling until they find what they want. Fine, the idea of a featured article brings gets the attention of people, but I also want that <FeaturedPost /> component to be dynamic.

That's the whole essence of the randomly generated featured posts. With that step out of the way, I thought of another feature to add to the overall process of rendering the rest of the articles, I wanted a way to render the remaining articles without the featured article in this list.

Wow! It felt really simple — at least, that was what I thought. I was wrong, again! My original approach towards accomplishing this goal spiraled — aimlessly — around the usage of so many unnecessary array methods like .indexOf() — to get the current of the featured article, Array.prototype.splice() — to mutate the content of the original posts array by checking if the properties of the featuredPost object were present in it. I ended up having something similar to the snippet below.

let featuredPost = posts[randomFeatured]

const indexOfFeaturedPost = posts.indexOf(featuredPost)

if (indexOfFeaturedPost > -1) {
  return posts.splice(indexOfFeaturedPost, 1)
}

Ideally the .splice() method returns 1 when the condition in the if() block, above, evaluates to true, and -1 when it is falsy. But, this approach was wonderfully flawed, YES, it was. Why? you might ask me. Although this seemed to work at first, whenever the components are re-mounted in DOM, the .splice() method repeats the same process and keeps removing any featured article from the list. I was furious and frustrated, and I think I screamed too!!!

After several attempts toward losing it all. I tried using the Array.prototype.filter() method, — one I should have utilized from the get-go. This method provided everything I needed for the success of this feature.

const updatedPosts = posts.filter((object) => object.id !== featuredPost.id)

Initially, the frontmatter of the articles on my blog do not have id property in them, so, for me to be able to implement this without any blockers, I had to make sure that these ids were consistent throughout all the articles frontmatter. In the snippet above, you'll notice that I'm comparing the id of the featured article with the rest of the array content in the posts variable, and proceeding to return a new array — updatedPosts

With that sorted out, I moved on to use React's useEffect() hook and the setTimeout() function to update the featured article, after thirty seconds. Although the featured article gets updated when you navigate to another route on my website, and back to the /blog route, since the variable is in an effect lifecycle method, which gets called whenever a component is mounted on the DOM.

React.useEffect(() => {
  setTimeout(() => {
    featuredPost
  }, 30000),
    updatedPosts
}, [])

I went ahead to add the updatedPosts variable in the lifecycle method too. Everything seemed fine, I was super pumped that I had been able to accomplish something meaningful — If only I had known that the next set of outcomes would be disastrous.

My travails with rehydration

As I said previously, little did I know that the constant update of the featured article would result in a rehydration error, take a look at it in the image below. I had zero knowledge about the consequences that my approach would yield, and this error spanned out of the Server-side Rendering approach that I'm using to get my articles with Next.js' server-side data-fetching methods: getStaticProps and getStaticProps.

I needed to understand why this kept happening because I can remember clearly that wasn't the first time it's happened to me. I knew beforehand that Next.js uses a SSR: Server-side Rendering technique to optimize the experiences we ship to people around the world, when they use the software we've created, on the web.

Before the advent of Frameworks like Next.js and Gatsby, the rendering process of React applications occurs on the client-side — in the browser. Meaning that, when you load or visit a React application, the browser gets an initial HTML document which is due to the inner workings of something similar to this snippet below, in a React app, bootstrapped with CRA: create-react-app

import ReactDOM from 'reacct-dom'
import App from './App'

ReactDOM.render(<App />, document.querySelector('#root'))

On initial load, the page is empty until some of the scripts that provide functionality have been fetched and parsed by the browser. While this — the parsing process of scripts — is going on, React is creating a representation of how the page would look like, when the render-blocking scripts have been parsed successfully.

But, this process — between the browser and React — takes time, which in turn leads to a poor user experience for people, because while this is going on, the user gets to see a blank screen alone.

With server-side rendering(SSR), the user, or whoever visits your site or app, gets a full HTML document from the server, instead of the empty one with a bunch of scripts that needs to be parsed by the browser. With the server-side rendering approach, the user is presented with a HTML — sometimes with the styles too — document that they can look at, while the browser and React does their thing.

Back to the problem on ground now, shall we? The error message in the image above says "The text content does not match the server-rendered HTML", and this is a result of the random featured article cards I'm rendering, which in turn causes a mismatch between the server-rendered HTML and this new version of the page, every thirty seconds and every time the user navigates away, and back to the /blog route.

A proposed solution

So, how do I fix this? was the question I asked myself. Knowing that the problem was related to hydration was the first step towards my liberation, I started making my research, and I found this article written by Jason Lengstorf.

It had the exact error message as the title of the article, I felt so happy at that moment, not until I read through it and figured out that, his approach did not suit my use-case. His approach involved using Next.js Advanced Middleware on Netlify and writing Netlify edge functions to transform a page on the fly, at the edge.

But, I stumbled upon an article — The perils of rehydration by Josh W. Comeau where he buttressed on the idea of rehydration does not equate to be another render, the idea behind Server-side Rendering and some other things I can't remember. You can take a look at the article here.

The solution looks similar to the snippet below, where a state variable is initialized — in the component that will be rendered — and is set to be false by changing the value of the variable in the useEffect() hook to be true, we trigger a re-render with the content of the component.

const ComponentToBeRendered = () => {
  const [isComponentMounted, setIsComponentMounted] = React.useState(false)

  React.useEffect(() => {
    setIsComponentMounted(true)
  }, [])

  if (!isComponentMounted) {
    return null
  }

  return (
    <ContentOfComponent>
  )
}

Improving user experience

In the solution that Josh proposed, I figured out that it caused a layout shift on my blog whenever the featured article is yet to be mounted. The GIF below illustrates that and this is due to the null value that was returned in the if().

Instead of returning null, I decided to create a skeleton loader that will give the user or the readers an idea of what to expect concerning the layout of my blog.

if (!isComponentMounted) {
  return <LoadingFeatured />
}

With this solution, I was able to bypass the rehydration error in React and provided a good UX by returning a loading skeleton.

I reduced an npm package size by 50% with minification

Caleb! — Tue, 27 Sep 2022 17:16:36 +0000

Web performance is something that a lot of people do not consider when they set out to build software that works on the web.

Everyone should strive to meet or at least work to ensure that the projects they build on the web are performant. You do not need to be an expert at this, anyone can start by making the web less cluttered than the way we met it.

The amount of unused code that we ship sometimes contains the bulk of problems related to performance that a lot of people experience. From sites that are lagging to the ones that take so much time to be interactive, you name them.

One step towards this practice is minification.

I've been working on this opensource project for a while now and the unpacked size of the first stable version was around 53.2kB, Take a look at the image below.

fifty-three kilo-byte was a little bit large, and since the bundler I'm using for this package is rollup.js, all I needed to do was install the terser — a JavaScript compressor toolkit for ES6 — plugin for rollup.

I went on to edit the config file of my package to accommodate the plugin by adding it to the list of plugins in the rollup config.

// rollup.config.js
import babel from "rollup-plugin-babel";
import { terser } from "rollup-plugin-terser";

const dev = process.env.NODE_ENV !== "production";

export default {
  input: "src/index.js",
  output: {
    file: "dist/index.js",
    format: "cjs",
  },
  plugins: [
    terser({
      ecma: 2015,
      mangle: { toplevel: true },
      compress: {
        toplevel: true,
        drop_console: !dev,
        drop_debugger: !dev,
      },
      output: { quote_style: 1 },
    }),
  ],
};

With the config above, the package size went from 53.2kB to 29.2kB. That's around 50% of the package size gone.

Final thoughts

There's a popular phrase on the internet about web performance. Some folks say "fixing web performance is as easy as drawing a horse".

I can agree with that, as it is a gradual process. You can start by running your app through Lighthouse on chrome DevTools to see how you can improve the performance.

With the 50% of the npm package gone, you've reduced a very small amount of the chunk of code you're sending to your users. Do that for a lot of other packages, routes, or components and see the result. That's how you start.

Thank you for reading, and I hope this article has been helpful.

How to implement protected routes in Next.js

Caleb! — Sat, 05 Mar 2022 15:35:00 +0000

One of the features that is neccessary in a single page application as it pertains to the authentication or its security is the ability to conditionally show some UI to the users based on their authentication state.

In this article, you’re going to learn how to implement this feature in a Next.js application, as you do not want an unauthorized user getting access to private user inerfaces like the dashboard unless they’re currently authenticated.

DISCLAIMER: I recently published a guide on how to perform authentication in Next.js with getServerSideProps and cookies. It also touches how to implement protected routes on the server without the flash of protected resources. If you end up following this guide, you might want to check this one that walks you through the process of persiting authentication state and choosing the right cookie wrappers.

But, before you read this article any further, you should have an idea of the following:

Conditional rendering in React
localStorage and its basic methods
The basics of the React Context API

Setting up a Next.js App

We’ll be focusing on using Next.js in this article. So Let us creating a Next.js app by typing command below into our terminal

npx create-next-app [name-of-your-app]

Let us have a look at the file structure of the app below. We’ll focus on the important files that we need in this app, so it’ll be concise.

     |--pages
     |   |-- api
     |   |-- _app.js
     |   |-- index.js (dashboard page)
     |--src
     |   |-- context
     |   |     |-- auth-context.js
     |   |__
     |__

The pages directory is where all the routing of the app takes place. This is an out-of-the-box feature of Nextjs. It saves you the stress of hard-coding your independent routes.

pages/_app.js: is where all our components get attached to the DOM. If you take a look at the component structure, you’ll see that all the components are passed as pageProps to the Component props too.

npm run dev

Setting up the authContext

In the previous section, we saw the basic structure of a Next.js app and the function of the files that
we’ll be interacting with, in this article.

Let’s start by moving into the context folder where we have the auth-context.js file. This file, with the help of React’s Context API, helps us store the authentication state of our application. You can read more about the context API here if it is new to you.

// src/context/auth-context.js
import React from "react";
import { useRouter } from "next/router";

const AuthContext = React.createContext();
const { Provider } = AuthContext;

const AuthProvider = ({ children }) => {
  const [authState, setAuthState] = React.useState({
   token: "",
  });

  const setUserAuthInfo = ({ data }) => {
   const token = localStorage.setItem("token", data.data);

   setAuthState({
    token,
   });
 };

 // checks if the user is authenticated or not
 const isUserAuthenticated = () => {
  if (!authState.token) {
    return false;
  }
 };

 return (
   <Provider
     value={{
      authState,
      setAuthState: (userAuthInfo) => setUserAuthInfo(userAuthInfo),
      isUserAuthenticated,
    }}
   >
    {children}
   </Provider>
 );
};

export { AuthContext, AuthProvider };

The snippet above contains all that we need to have a preserved auth-state in our application. But, let us break it down into smaller chunks and understand what it does.

You’d notice that we’re making use of the useState hook in React to define the initial value of our authentication state authState and the data type that we assigned to it as an object.

const [authState, setAuthState] = React.useState({
 token: "",
});

Why? You’d ask. Well, it is so that we can factor multiple states in our application. Say, for example, we have other states that needs to be preserved, asides the user’s auth-state, all we’d do is add another property to the authState object.

Now, we need a way to properly store the unique JWT (JSON Web Token) that is assigned to any user when they originally signed up on our app. This is where we employ the use of the browser’s localStorage API

const setUserAuthInfo = ({ data }) => {
 const token = localStorage.setItem("token", data.data);

 setAuthState({
  token,
 });
};

What we did in the snippet above was to store the user token in localStorage and also look for a way to make the value of the token to be available in the app state, by using the setAuthState setter function that we declared in the useState hook.

All we have done up until this moment is store the user info (i.e the token). The next step is to check if there’s any JWToken in the browser’s localStorage when the page is first mounted.

const isUserAuthenticated = () => {
 if (!authState.token) {
  return false;
 }
};

The snippet above doesn't seem appropriate, because the isUserAuthenticated function will not return true as I am already negating the condition in the if block.

Casey Choiniere suggested the changes below — and in the useEffect hook that redirects the user back to the home page if they're not authenticated.

const isUserAuthenticated = () => !!authState.token;

The snippet above checks for the token. If the token is not in localStorage, it returns false. If it is, it returns true.

These functions are, in turn, passed as values to the value prop in the Provider

<Provider
 value={{
  authState,
  setAuthState: (userAuthInfo) => 
  setUserAuthInfo(userAuthInfo),
  isUserAuthenticated,
 }}
/>

Using authContext in the dashboard page

The authContext from the previous section can now be imported into the dashboard page, and we can make use of the isUserAuthenticated prop in the authContext Provider to check if the user is already authenticated.

// pages/dashboard
export default function Dashboard() {
  const router = useRouter();
  const authContext = React.useContext(AuthContext);

React.useEffect(() => {
  // checks if the user is authenticated
  authContext.isUserAuthenticated()
  ? router.push("/dashboard")
  : router.push("/");
}, []);

  return (
   <React.Fragment>
    <Head>
     <title>Dashboard</title>
    </Head>
    <div>
     <h2>Dashboard</h2>
    </div>
   </React.Fragment>
 );
}

For this to work, the conditional statement has to be in the useEffect hook of React.js. Since the hook runs on every new render of the component (which is our dashboard page).

So anytime a user manually goes to the dashboard route, without logging in first, they get sent back to the home page or the login page.

React.useEffect(() => {
  // checks if the user is authenticated
  authContext.isUserAuthenticated()
  ? router.push("/")
  : router.push("/dashboard");
}, []);

In the snippet above you’ll see that we made use of Next.js’ useRouter module to get access to the app’s route. Remember how the isUserAuthenticated function will always return false in the authContext.

So now, in this scenario, if the token isn’t in localStorage the user will always get sent to the login route or at least the homepage.

Conclusion

If you have a lot of routes in your application that you don't want to be accessible to users that are not authenticated, all you have to do is repeat the process in these individual routes.

Thank you for reading this article, I hope it has helped you understand how to implement protected routes in Next.js.

Break into web3 by joining this hackathon

Caleb! — Wed, 10 Nov 2021 06:42:52 +0000

There's been a trend that has been quite popular in the tech community for a while now. Everywhere you turn, on the internet, almost every tweet on Twitter contains the term "web3".

Now, you might have asked (or you're currently asking) yourself What exactly is "web3".

If we look at it from the perspective of the ethereum blockchain. Web3 is the representation of decentralized applications that run on the web. Since these types of applications (DApps) are decentralized there's no need to worry about your personal data being monetized.

In general terms, web3 is a "verifiable" and "permissionless" internet.

The applications on web3 are deployed on decentralized blockchains, instead of using the traditional method that requires developers to deploy their apps onto a particular server.

Well, that's a little bit of an intro about web3, let's get to the reason why you're here. If you want to learn more about web3, you can check out this ethereum doc and this article on freecodecamp.

What is the PlatON Network

The PlatON Network is an AI privacy-preserving network that allows you to perform "verifiable computations, zero-knowledge proof, homomorphic encryption, secure multi-party computations and other cryptographic algorithms on the blockchain".

The paragraph above basically refers to the Network (PlatON) as an internet (web3) protocol that has its foundations rooted in the properties of a typical blockchain system.

On the Network, LAT is a token that is used as a means of exchange (payments) for services rendered. Still on this network, the demography of people can be further categorized into:

Users: this category of people are basically you and I. They manage their assets (the tokens) most of the times for exchanges, and sometimes for the use of DApps (Decentralized Applications)
Validators: these categories of people usually stake their tokens so that they can become validators of the Network. Sometimes they participate in the governance of the network and receive rewards for doing so.
Volunteers: these categories mostly include developers who contribute to the network by ensuring that it thrives.

The LAT token is a cryptocurrency, and yes. You may have been wondering how to get a monetary value for this token.

Fortunately, there's quite a small number of exchange platforms that have the LAT token listed on their platform. One of them is the Huobi platform. You can create an account with them and trade the LAT token with some popular cryptocurrency tokens.

Introducing the PlatON Hackathon Plus

The PlatON Network previously organized a hackathon that was funded with about $150,000 for people to build cool products on the network.

The previous hackathon had a lot of developers participating from Europe, Oceania, Asia, and Africa.

The top three positions were tied by some of the participating teams (more like a draw, between all of them). You can take a look at the top projects that were built during the hackathon below.

Itheum: A privacy-preserving data trade platform

ShowMe: A Web3.0 NFT social subscription platform

Dante: A privacy-preserving storage platform

Privacy RecSys: A Study of Recommender System Based on Privacy-preserving Computation

PlatON Studio Integrated Development Environment

S-world Metaverse Game: A Web3.0 simulation & growth game platform

Pumo Finance: A synthetic asset issuance protocol and trading platform based on the Alaya blockchain

LionSwap: A liquidity verification platform onAlaya

You can take a look at the details of all the participating teams here.

As a result of the positive feedback gotten from the previous hackathon, the PlatON Network is organizing another hackathon.

But, this time around, the incentives for the hackathon is up to $1,000,000 (million dollars) for the first batch of 31 teams that'll submit their project idea.

The Network is inviting developers from all over the world to come and participate in this event. If you are enthusiastic about this new ecosystem of the internet and you'd love to get your hands dirty, you should check out this hackathon.

To learn more about the hackathon and submit a project title, you can click here

You'll notice that, while you're about filling your project information, you're requested to put in your LAT token wallet address, to obtain that, you'll need to download the ATON wallet either on the Google play store (if you're on android) or the app store (if you make use of an iPhone).

Here are some other resources that you can dig deeper into if you want to participate effectively in this hackathon.

How to create a Preloader in Next.js

Caleb! — Sun, 24 Oct 2021 22:22:40 +0000

Before you read this article, I want you to know that it is a bit flawed, and I apologize for the mistakes I made previously, while authoring this article.

I am super thankful for the people who shared their opinions in the comment, and I learned from all of them, a great deal! You can find a new article that shows how you can add a preloader to a Next.js site, the right way, here

There's always a need to have all the content of a webpage ready before it is displayed to whoever is visiting your web app/website.

In situations where the contents of the webpage aren't ready, people would have to wait for it to be displayed, and this causes a very high decline rate of people who visit your website.

In this article, we'll have a look at how we can build a loading screen component that is displayed whenever the contents of the page is about to be mounted onto the DOM.

Before you read this article any further, you should be familiar with:

React, a declarative JavaScript library for building user interfaces
Next.js, a framework of React, used for building production-ready applications
Conditional rendering in React
Animations in CSS

Getting started

In this article, we’ll be using NextJS to set up our app, you can use create-react-app if you are not familiar with NextJS.

Let us start by installing the dependencies that we need in this project. We’d start by creating a nextjs app. The command below gets the dependencies that we need in a Nextjs app.

npx create-next-app [name-of-your-app]

We’ll make use of the "styled-component" library to style the loading screen component. Let’s get the dependency above by typing the command below into our terminal.

npm install --save styled-components

The components in our Nextjs app

In this section, we are going to see the different files that make up the architecture of this project, and their respective functions below.

The pages directory is where all the routing of the app takes place. This is an out-of-the-box feature of Nextjs. It saves you the stress of hard hard-coding your independent routes.

pages/api: the api directory enables you to have a backend for your nextjs app, inside the same codebase, instead of the common way of creating separate repositories for your REST or GraphQL APIs and deploying them on backend hosting platforms like Heroku, and so on.
pages/_app.js: is where all our components get attached to the DOM. If you take a look at the component structure, you’ll see that all the components are passed as pageProps to the Component props too.

function MyApp({ Component, pageProps }) {
  return (
    <React.Fragment>
      <Component {...pageProps} />
    </React.Fragment>
  );
}

export default MyApp;

It is like the index.js file in Create-React-App. The only difference here is that you are not hooking your app to the DOM node called “root”.

 React.render(document.getElementById("root"), <App />)

index.js is the default route in the pages folder. When you run the command below, it starts up a development server and the contents of index.js are rendered on the web page.

npm run dev

Building the loading screen component

The previous sections walked you through the process of installing the dependencies that are needed for building the loading screen component and the functions of each file in a typical Nextjs app.

In this section, we'll go through the step-by-step process of building the component itself.

First, we'll be taking a look at the style of the loader. We are using the styled component library for this purpose.

The Screen styled-component serves as the parent container that wraps the loading animation. It uses a fade keyframe to ensure the transition of the screen is properly utilized.

// loadingScreen.js
import styled from "styled-components";

const Screen = styled.div`
  position: relative;
  height: 100vh;
  width: 100%;
  opacity: 0;
  animation: fade 0.4s ease-in forwards;
  background: black;

  @keyframes fade {
    0% {
      opacity: 0.4;
    }
    50% {
      opacity: 0.8;
    }
    100% {
      opacity: 1;
    }
  }
`;

The snippet below shows the Balls styled component. It serves as a container for the child elements in it. The corresponding divs in the container are the balls that we'll be animating.

You'll notice that there are unique classNames assigned to each div element in the container. This is for us to be able to set an animation-delay property on each ball so that the oscillating effect can be seen properly.

import styled from "styled-components";

const Balls = styled.div`
  display: flex;
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);

  .ball {
    height: 20px;
    width: 20px;
    border-radius: 50%;
    background: #1b5299;
    margin: 0 6px 0 0;
    animation: oscillate 0.7s ease-in forwards infinite;
  }

  .one {
    animation-delay: 0.5s;
  }
  .two {
    animation-delay: 1s;
  }
  .three {
    animation-delay: 2s;
  }

  @keyframes oscillate {
    0% {
      transform: translateY(0);
    }
    50% {
      transform: translateY(20px);
    }
    100% {
      transform: translateY(0);
    }
  }
`;

If you're new to animations in CSS. You can check this guide that explains the fundamentals.

Now that you have seen the styles of the components above. We'll go ahead to reference the styles in the LoadingScreeen component below.

import React from "react"
import styled from "styled-components"

const Screen = styled.div``

const Balls = styled.div``

const LoadingScreen = () => {
  return (
    <Screen>
      <Balls>
        <div className="ball one"></div>
        <div className="ball two"></div>
        <div className="ball three"></div>
      </Balls>
    </Screen>
  );
};

export default LoadingScreen;

Implementing the preloader functionality

We've seen the function of the loading screen styles and how the animation works behind the scene.

In this section, we'll be importing the component into _app.js. Take a look at it below.

import LoadingScreen from "../src/components/LoadingScreen";

function MyApp({ Component, pageProps }) {
  const [loading, setLoading] = React.useState(false);

  React.useEffect(() => {
    setLoading(true);
  }, []);

  return (
    <>
      {!loading ? (
        <React.Fragment>
          <Component {...pageProps} />
        </React.Fragment>
      ) : (
        <LoadingScreen />
      )}
    </>
  );
}

export default MyApp

The snippet above shows how we've used conditional rendering to check the state of the loading component. We had to create a local state variable that holds the current state with the useState React hook.

const [loading, setLoading] = React.useState(false)

The initial state of the loader is set to a boolean value, false.

The useEffect hook is a lifecycle method in React that is fired whenever there's a change in the DOM. It combines all the lifecycle methods that a typical class-based component will have.

  React.useEffect(() => {
    setLoading(true);
  }, []);

By setting the initial "falsy" state of the loader to be true in the useEffect hook. We're telling the browser to display the loader.

Conclusion

Formerly, I made use of the setTimeout() function to display the loader for a significant amount of time before showing the content of the UI.

React.useEffect(() =>{
 setTimeout(() => setLoading(true), 6000);
})

Little did I know that it was a bad practice. This practice has a lot of performance issues which in turn would result in providing a poor UX (user experience) for users visiting the web-app, as the content on the webpage could have been ready before the time that was stated in the setTimeout function.

Thankfully, Martin Vandersteen and Stephen Scaff did well by explaining to me. You can take a look at this thread to understand their ideas.

Below is a GIF that shows what we've been building all along.

Although, this is an approach that helps us to have the content on a webpage/site available. If you are dealing with dynamic data, say from an API endpoint, the approach will be a little bit different.

You can decide to make use of this react-spinners package if you don't want to spend time creating a custom loading component all by yourself.

Thank you for reading this article. Kindly leave your thoughts in the comments section, and share this article with your peers, Thanks.

Building a client database of people in React

Caleb! — Mon, 11 Oct 2021 22:47:34 +0000

Ever wondered how to get access to a whole lot of information about people on the internet? Like, any information about anyone?

as you proceed reading this article, you'll come across a section that talks about protecting your API key on the server. If you want to learn more about how you can do that to your API endpoints, you should take a look at this piece

In this article, we’ll be building a client-side application with ReactJS on the web that’ll integrate Kelvin Data API at the frontend. The Kelvin Data is an API platform that allows you to access the profile of people on the web.

You can search for a specific person, either with their email address, LinkedIn profile (here, you’ll have to provide the person’s LinkedIn URL. i.e. https://linkedin.com/in/example-person ), or their phone numbers.

Now, let’s see how we can create an app that we’ll consume this API with. But, before you read this article any further, you should have a basic knowledge of:

React,
Data fetching with Hooks in React,
Conditional rendering in React,
String/template Literals in JavaScript,
React components and props

The KelvinData dashboard.

When you signup on to the platform, you’ll have access to a personalized dashboard that you can use to watch your subscriptions, manage your API keys, and do a lot more.

A search playground is also on the dashboard where you can test the features of the API.

You can decide to search for anyone, either with their names, email addresses, LinkedIn profiles, or phone numbers. This article is going to cover how you can search for people with their full name alone.

Getting Started

For the scope of this article, we’ll be using NextJS to bootstrap our app. This does not mean that the create-react-app library wouldn’t work. You can make use of anyone that you find convenient. We’re using nextjs because of its simplicity. You can read more about NextJS here

Let us start by installing the dependencies that we need in this project. We’d start by creating a nextjs app. The command below does that for us.

npx create-next-app [name-of-your-app]

We’ll make use of the "styled-components" library for styling our app, and the "axios" library to fetch data from the API. We wouldn’t be covering much of the styling aspect in this article. You can find the full app styles here.

Let’s get the dependencies above by typing the command below into our terminal.

npm install axios styled-components react-icons

Let us have a look at the file structure of the app below. We’ll focus on the important files that we need in this app, so it’ll be concise.

|--pages
|   |-- api
|   |   |-- users.js  
|   |-- _app.js
|   |-- index.js
|--src
|   |-- components
|   |     |-- Card.js
|__ .env.local

Overview of the components in our Next.js app

In this section, we are going to see the different files that make up the architecture of this project, and their respective functions below.

The pages directory is where all the routing of the app takes place. This is an out-of-the-box feature of Nextjs. It saves you the stress of hard hard-coding your independent routes.

pages/api: the api directory enables you to have a backend for your nextjs app, inside the same codebase, instead of the common way of creating separate repositories for your REST or GraphQL APIs and deploying them on backend hosting platforms like Heroku, and so on.

With the api directory, every file is treated as an API endpoint. If you look at the api folder, you'll notice that we have a file called user.js in it.

That file becomes an endpoint, which means an API call can be performed using the path to the file as the base URL.

const getData = async() => {
  axios.get("/api/users")
   .then(response => response())
   .then(response => console.log(response.data))
   .catch(err => console.log(err)
}

pages/_app.js: is where all our components get attached to the DOM. If you take a look at the component structure, you’ll see that all the components are passed as pageProps to the Component props too.

It is like the index.js file when using Create-React-App. The only difference here is that you are not hooking your app to the DOM node called “root”

React.render(document.getElementById("root), <App />)

index.js is the default route in the pages folder. That is where we'll be doing most of the work on this project. When you run the command below, it starts up a development server and the contents of index.js are rendered on the web page.

npm run dev

Card.js: is the component that holds displays the data we get from the API on the webpage
.env.local: is where we’re storing the API key that’ll enable us to consume this API.

Writing the server-side API call.

In the previous section, we saw the files that we'll be interacting with and their specific functions. In this section, we would have a look at how we can consume the API.

The reason why we're writing the API call at the server-side is for securing our API key, and Nextjs already makes it an easy task for us.

With the API routes in Nextjs, we can perform our API calls without the fear of our API keys being revealed on the client-side.

You may have been wondering what the essence of the environment variable in the .env file is, in this scenario.

The environment variable (which is our API key) can only be available in development mode. That is why we can do something like process.env.api_key, and get access to the environment variable.

But, the moment you deploy your app to platforms like netlify or vercel, the mode changes to production, which makes the nodejs process object unavailable on the client-side.

Now that you have seen the reason why need to write a server-side API call. Let's get to it right away.

// users.js
import axios from "axios"

export default async function users(req, res) {
    const {
      query: { firstName, lastName },
    } = req;

    const baseUrl = `https://api.kelvindata.com/rest/v1/search-v2?    lastName=${lastName}&firstName=${firstName}&apiKey=${process.env.KEY}`;
    const response = await axios.get(baseUrl);
    res.status(200).json({
    data: response.data,
  });
}

In the snippet above, we created an asynchronous function called, users. It takes in two arguments, req which stands for “request” in full, and res which is “response” in full.

The req argument has some properties, (or “middlewares” as the Nextjs docs calls it) that can be accessed when we’re consuming our API, one of them is req.query.

You’ll notice that we destructured the query property in the snippet above, so we would be able to pass those variables as values to the query properties of the API endpoint. Take a look at it below.

You can read more about the in-built middlewares that comes with the req argument here.

const {
  query: { firstName, lastName },
} = req;

The base URL takes the destructured query properties as values and the apiKey is gotten from the .env file via the nodejs process object.

The destructured query properties are taken as requests that will be sent from the input values of the form component (which we’ll be creating in the next section) to the API, once it is received, we get a response that corresponds with the request we made.

const baseUrl = `https://api.kelvindata.com/rest/v1/searchv2?  lastName=${lastName}&firstName=${firstName}&apiKey=${process.env.KEY}`;

The next process the function has to complete is the response from the asynchronous API call. The snippet below assigns the API call which we are perfoming with the axios library to a variable, response.

On the next line, the res argument uses the status method which is used to send a JSON response to us, then we can assign the response variable as a property of data

You can read more about the various HTTP status codes here

const response = await axios.get(baseUrl);
res.status(200).json({
  data: response.data,
});

Building the form component

In the previous section, we saw how we can write our API calls on the server-side. we’ll be using that API call in this section as we create the form component that will send the first and last name values from the input fields to API query parameters.

We’ll be keeping the code snippets short so that this article doesn’t get too long. Let’s start by taking a look at the content of index.js below.

import React from "react";
import styled from "styled-components";
import axios from "axios";
import Card from "../../components/Card";

const Wrapper = styled.section`
  padding: 0 100px 0 100px;
  height: 100%;
  width: 100%;

  // remaining style goes here
`;

const UserAPIComponent = () => {
const [userData, setUserData] = React.useState([]);
const [firstName, setFirstName] = React.useState("");
const [lastName, setLastName] = React.useState("");

const getuserData = async () => {
  // api call goes here
};

const handleSubmit = (e) => {
   e.preventDefault();
   getuserData();
};

return (
   <Wrapper>
     <h3>Search for Anyone</h3>
     <form onSubmit={handleSubmit}>
        <label htmlFor="firstname">First name</label>
        <input
          type="text"
          name="firstname"
          value={firstName}
          placeholder="First Name"
          onChange={(e) => setFirstName(e.target.value)}
        />
        <label htmlFor="lastname">Lastname</label>
        <input
          type="text"
          name="lastname"
          value={lastName}
          placeholder="Lastname"
          onChange={(e) => setLastName(e.target.value)}
        />
        <div className="btn-container">
           <Button>Search</Button>
        </div>
      </form>
      <div className="results-container">
        {userData ? <Card result={userData} /> 
        : "loading..."}
      </div>
  </Wrapper>
 );
};

export default UserAPIComponent;

Since this is a React component that is receiving data from an API endpoint, it should have an internal state of its own. The snippet below shows how we defined the different state variables with React Hooks.

const [userData, setUserData] = React.useState([]);
const [firstName, setFirstName] = React.useState("");
const [lastName, setLastName] = React.useState("");

The firstName and lastName variables receive the text values that are typed into the input field by anyone.

The userData state variable helps us store the response that we get from the API call in an array, so we can use the JavaScript map() method to render the response on the webpage.

Notice how we’re using axios to get data from the API endpoint, and how the base URL is not a typical https:// URL, instead, it is the path to the file where we made the server-side API call before.

const getuserData = async () => {
axios.get(`/api/usersfirstName=${firstName}&lastName=${lastName}`, {
       headers: {
         Accept: "application/json",
         "Access-Control-Allow-Origin": "*",
       },
})
  .then((response) => response)
  .then((response) => {
    setUserData(response.data.data); 
  })
  .catch((err) => console.log(err));
};

We repeat almost the same process in the user.js file, but this time around with the necessary fetch headers and assignment of the state variables to the API query parameters.

In the second .then() method, we ensured that the response from the API call is treated as an array, hence the need for response.data.data. If we had stopped at setUserData(response.data), JavaScript will throw a type-error whenever we try to do the following:

{
  userData.map((users, index) => {
    return (
      // some JSX
    )
  })
}

This is because response.data is having an object data-type, and the map() operation does not work on JavaScript objects, only arrays.

The handleSubmit handler ensures that the webpage isn’t reloaded at every API call, upon the click of the search button.

const handleSubmit = (e) => {
  e.preventDefault();
  getuserData();
};

Building the card component

The card component serves as the presentational component of the app. Data gets passed down to it through the usage of props in React.

Once again, for the sake of brevity, we’ll not be taking a look at all the major content of the card component. Let’s take a look at the modified structure below

import React from "react";
import { FiUser } from "react-icons/fi";
import styled from "styled-components";

const Wrapper = styled.div`
  height: 56%;
  width: 32%;
  margin: 0 15px 30px 0;
  background: #fff;
  box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.05);
  border-radius: 8px;
  padding: 0 15px 0 15px;
`;

const Card = ({ result }) => {
  return (
     <>
      {result.map((users, index) => {
        return (
           <Wrapper className="users-card" key={index}>
             <p>
               <span>
                 <FiUser />
               </span>
                 {users.name.full !== null ? 
                   users.name.full 
                   : "no name data" }
             </p>
             <p>Title: {users.employments[0].title}</p>
             <p>
               Organization:
                {
              users.employments[0].organization.name !== null
              ? users.employments[0].organization.name
              : "no employment info"}
             </p>
          </Wrapper>
        );
      })}
   </>
  );
};

export default Card;

The result prop is passed to the Card component, which in turn, gets utilized in the App component (in index.js).

The ternary operator checks for the validity of userData, if it is true, the Card component is rendered. If it isn’t, the loading… string is displayed on the webpage.

<div className="results-container">
  {userData ? 
    <Card result={userData} /> 
    : "loading..."
  }
</div>

You’ll also notice how we’re performing conditional rendering with the ternary operator in the “Organization” paragraph below.

If there isn’t any data that corresponds with a user’s organization details, the "no employment info" string is displayed. If there is, the user’s organization is displayed.

<p>
  Organization:
  {users.employments[0].organization.name !== null
  ? users.employments[0].organization.name
  : "no employment info"}
</p>

Conclusion

The video below shows the end result of what we have been building all along from the beginning of this article. You can always check your browser’s dev tools, move to the network tab, to see if the API key is showing or not.

If you want to have a look at the code base, here’s the link to it.

The link points to the specific file (of this article) in the repository. You can check out my other article demos here and also have a look at the repository as a whole.

If you read this article up till this point, thank you for doing so, and please don’t forget to share it.