Forem: Teyim Asobo

Conquer Every User Journey: Building Robust E2E Tests with Playwright- part 1

Teyim Asobo — Wed, 20 Mar 2024 09:33:15 +0000

In everyday software development, making sure parts of our application work as expected will involve us testing the app. This could include clicking a button, a dropdown, or an input field to make sure they behave as expected. Testing very simple applications manually can get the work done and make you sleep at night. However, manual testing becomes tedious and inefficient for very large applications.

Say Hello to Automated testing.In part 1 of this post, you will learn about what automated testing is, the types of automated tests, the tools used for automated testing, and of course the fun part... we get our hands dirty with some code examples in part 2.

What is Automation testing

Let's assume we are new to the English language, and break down these terms :

Automation:This refers to using machines or software to do tasks that would normally be done by a person. Imagine a car wash that automatically cleans your car instead of someone scrubbing it by hand.
Testing:In the world of software development, testing involves checking if a program works as expected. We want to make sure there are no bugs or errors that prevent it from functioning properly. Think of it like testing a new recipe in the kitchen to see if it turns out delicious!

From the above definitions, we can say automated testing is writing code that tests our applications for us. So we use testing tools to say "Hey you see this element, when I do this action, I expect these results". and out test is said to "pass" when the expected result = the actual results from interacting with those elements when the test is running.

Types of Automated test

There are primarily 3 types of testing: Unit test, Integration test, and End-to-end test (E2E). These 3 test are usually presented by the following pyramid

This pyramid indicates complexity in writing and maintaining tests as you go up the pyramid. This indicates we should write more Unit tests which are easier to write and run faster. On the other hand, we should write a few End-to-End tests for crucial user journeys since they are more complex to write and maintain and also take more time to run.
Let's take a closer look at each of these types of tests:

Unit test: Unit test involves testing individual, isolated pieces of code e.g. testing a component, utility functions, etc. In frontend applications, it usually makes sense to write unit tests for crucial business logic and heavily used utility functions. with this type of test, mocking is used to abstract out 3rd party logic and API calls
Integration test: Integration testing is all about checking how 2 or more of these interact and collaborate. It verifies that when you perform actions on one component (like clicking a button), the other components react as expected (like displaying a new page or updating information). While unit testing focuses on the individual functionality of each component in isolation, integration testing brings them together to ensure they play nicely as a team.
E2E test: Imagine a user starting on the homepage of your application, clicking through different pages, interacting with various components, and finally reaching a specific goal, like completing a purchase. E2E testing mimics this entire user experience from beginning to end. E2E testing focuses on the user's perspective. It checks if the application flows smoothly, functions as expected at each step, and ultimately delivers a satisfactory experience for the user.

Popular Tools used for Frontend Automated testing

Unit test/Integration test: React Testing Library, Jest, Vitest
E2E test: Playwright, Cypress

Before we go ahead to start writing some test, let's look at test doubles

A Hand-shake With Test Doubles

Test doubles play a crucial part in automation testing as they allow us to abstract away logic like API calls, and calls to 3rd part libraries and fully focus on testing a component or a group of components in isolation.

Let's take a closer look at the 3 most common test doubles and their differences:

Stubs:
- Function: Stubs are the simplest type of test double. They are pre-programmed to return specific, predetermined values when their methods are called.
- Focus: Stubs don't care about how they are called. They simply provide a fixed response for specific inputs, allowing you to test the component's behavior under those conditions.
- Use case: Stubs are ideal for testing how a component reacts to specific data or interactions, without the complexity of dealing with real dependencies.
Example: You are testing a component that displays a welcome message based on the user's name. You can use a stub to simulate an external API that fetches user data and always return a specific name, allowing you to test the component's logic for displaying that name.
Spies:
- Function: Spies are similar to stubs but offer additional capabilities. They can record information about how they are called, such as the number of times a method was called or the arguments passed to it.
- Focus: Spies care about how they are called and can be used to verify specific interactions occurred during the test.
- Use case: Spies are helpful when you need to ensure that certain methods of a dependency were called with the expected arguments. They allow you to assert not only the outcome of the component but also the interactions it had with its dependencies.

Example: You are testing a component that sends data to an analytics service. You can use a spy to track how many times the analytics service method was called and with what data, ensuring the component interacts with the service as expected.

Mocks:
- Function: Mocks are the most versatile type of test double. They combine the functionalities of stubs and spies, allowing you to pre-program expected behavior and verify interactions. Additionally, Mocks can simulate more complex behaviors, such as throwing errors or returning different values under specific conditions.
- Focus: Mocks offer the most control over the behavior of the test double. You can define expectations for how they should be called and verify if those expectations are met during the test.
- Use case: Mocks are useful for complex scenarios where you need to control the behavior of a dependency in different ways and ensure the component reacts appropriately.

Example: You are testing a component that interacts with a database. You can use a mock to simulate different database responses (success, failure) and verify the component handles them correctly.

Choosing the Right Double:

The choice between stubs, spies, and mocks depends on your specific testing needs and the complexity of the dependency being replaced.

Use stubs for simple scenarios where you only need to control the output.
Use spies to verify how the component interacts with the dependency.
Use mocks when you need complex behavior control and verification of interactions.

Dynamic Readme image based on GitHub Activity

Teyim Asobo — Mon, 29 Jan 2024 12:38:44 +0000

GitHub readme files are an excellent way to convey information about a project's structure, help, patches, updates, and more. But readme images can be used for more fun stuff like the GitHub profiles you see are readme files with some rich and often dynamic text and images.

Now that you have an idea of what readme images are, let's look at how I created a dynamic readme image that changes based on my GitHub activity. this article looks at the technical aspects and is not a step-by-step guide on creating it. with that said, the source code is on my GitHub in case you want to have a deeper dive into how things work.

Project Idea

My idea for this project was to create customized Github weekly stats, or some sort of fun, gamified way of displaying my GitHub activity. The aim was to encourage me to push more code to GitHub while having fun and a feeling of achievement in the whole process. When I commit code and do activities on GitHub, all of this is used to generate weekly points which increase the percentage on each level and will eventually help me clear a level. when I don't commit code, the percentage for a level drops by a given amount and I eventually drop in levels. this gave me the motivation to do more activities on GitHub, with me often being excited to see how much my percentage has advanced.

Architecture

How it works

A Nodejs script that fetches commits from the last 1 week from the GitHub API(excluding Github action commits) and updates the health and current level based on that. This script then runs every 7 days using GitHub action.

To generate the image, there is a template built with Tailwindcss in a Nextjs API route that uses _vercel-og _ to generate the image. it simply uses query params passed, to get the current level, health, and commits and give back the corresponding image

Challenges

one major challenge I faced was the image failing to load or loading very late after the readme has displayed. the initial approach I took was to embed the link to the Nextjs backend directly in the readme file, hence when I fetch updated GitHub data, I just update the query params, coursing a new image to be fetched..this coursed a major problem since the image usually delays to fetch and might often fail.

Solution

I fixed this by fetching and storing the image locally in the project repo and just referencing this in my readme file. this reduced the delay of waiting for my image to fetch after my readme file had been fully rendered.

Conclusion

With this, I can generate my weekly Github stats as a dynamic readme image, making it a more exciting experience to commit code to GitHub. below are links to the Nextjs API route repo and the main repo which contains the majority of the logic

Walle
Facile

A Deep dive into CSR, SSR, SSG and ISR

Teyim Asobo — Mon, 29 Jan 2024 12:21:27 +0000

The evolution of the web has given rise to many innovative ways through which servers render and deliver web pages to the browser. some of which include server-side rendering(SSR), client-side rendering(CSR), static site generation(SSG), and incremental Static regeneration/revalidation(SSR). While most of these techniques have brought immense improvement in website load/delivery speed, they also have their use cases, pros, and cons. In this article, we dive a little bit deeper, taking a behind-the-scenes look at how these techniques work and when to use them.

Hi, I am a senior frontend Engineer currently in search of freelance work (upwork), and full-time roles (Github), Will appreciate any referrals or opportunities you bring my way. Thanks

Client-side rendering (CSR)

With client-side rendering, when a request is made to the server, the server responds with a blank HTML file and a javascript bundle. the javascript now builds the Dom(HTML elements) from scratch based on some virtual Dom(React virtual Dom) in a case where the app is built with React. hence depending on the bundle size returned to the browser, the user usually will see a blank screen for some seconds before the website information is then displayed.

steps involved in client-side rendering

The user makes a request to the server
The server returns a blank HTML page
The browser fetches and downloads the JS bundle
JS constructs HTML UI and makes it interactive(attaches necessary event handlers)
Any request to 3rd party APIs are made
Users can now fully interact with the web page

When to use client-side rendering

Client-side rendering is best used in web applications with large complex features and pages.

Pros

Reduced server-side workload
Reduced server cost
A better client experience

Cons

Poor SEO, since the initial page sent to the browser, is empty, web crawlers can't index the content of the page
Slow initial load since the dom is being constructed on the client side.

Server-side rendering(SSR)

With Server-side rendering, when a request is made to the server for a page, the server fetches relevant data for that page from the backend, constructs the full HTML page, and sends it back to the browser which will now become visible.

Note: even if javascript is disabled in our browser, we still see the full page, but can't interact with it.

Hence with server-side rendering, we construct the full HTML page on the server and return it to the browser.

When to use server-side rendering

SSR can be used on websites in which SEO is crucial. or in situations where each user has unique content shown on the initial load

Pros

Easy indexing by search engines
Fast load times especially in case of a slow connection

Cons

High server load, since the server has to build the page on every request
Slower transition between pages in the application

Static site generation(SSG)

with SSG, the server builds our website page together with its static assets once and serves it on a CDN(content delivery network). any subsequent request for a web page is served from the CDN. In SSG, pages are usually generated during application build time

When to use server-side generation

SSG can be used for websites whose content does change very often e.g blogs

Pros

High-performance thanks to CDN caching
The static HTML page will always be served even if the backend is down

Cons

The content of the page served by the CDN can easily get outdated in case of rapidly changing content.

Incremental static regeneration(ISR)

This concept is mostly popular with Nextjs. ISR is very similar to SSG, they work basically the same, but ISR goes an extra step. After the static page is served on the CDN, and after some interval, the page on the CDN is then invalidated and a new version of the page is regenerated with fresh data. with this, we can use SSG with data that is frequently changing.

when to use incremental static regeneration
we can use ISR with websites where we want to get fresh updates delivered to the customer per page basis without having to redeploy the site and with the benefits of SSG.

Pros

Less server load
Content delivery is very fast
Rebuilding/deploying the website to display fresh content is not needed.

Cons

Might need extra configuring steps

These page rendering techniques are used in different situations and have several pros and cons. Most modern applications will often make use of more than one e.g SSG + CSR or ISR + CSR.combining these techniques provide an amazing way of getting the best of both worlds, be it website performance or SEO.

Vite js: The Lightweight and Lightning-fast Build Tool for Your Next Web Project

Teyim Asobo — Mon, 29 Jan 2024 12:02:30 +0000

Vitejs is a fantastic build tool, that aims at providing a faster and better development experience for web projects. This article aims at taking an in-depth look at what Vitejs is, how it works, and its benefits.

What is Vitejs

Vite js is a fantastic frontend build tool that boosts the frontend development experience by providing :

Fast server start times by serving files to the browser via native ECMAScript modules (ESM).
Optimized builds using Rollup and Esbuild for generating static assets for productions
Super fast hot module replacement.

Before we look into detail how Vitejs accomplishes these, let's have a look at what modules are in Javascript and why exactly we need a module bundler.

Understanding Modules

Most often, when building small web pages, putting all our functions in one javascript file, let's say main.js would be fine. This is not the case when building larger javascript applications where separation of concern is key. we need a way to separate different files based on the functionality of what they do. This is where Javascript modules come in. A module is simply a file that carries out specific functionality and allows you to share its functionality with other parts of your application. To allow a module to be used elsewhere in our application, we use the export statement, and to use that module in another file, we use the import statement. the most common module systems are ECMAScript modules(ESM) and CommonJs(CJS).

How does the browser fetch and evaluate modules?

The web browser fetches and evaluates imported modules via HTTP get request. it also fetches and evaluates the module's imports when needed. let's see an example.

Below is a simple javascript application that uses modules:



<!DOCTYPE html>
<html>
  <head>
    <script type="module" src="main.js"></script>
  </head>
  <body>
    <h1 id="app"></h1>
  </body>
</html>

we import our main.js file here, which simply imports a constant from the hello.js module and sets that as the H1 text.



import { hello } from "./hello.js";
document.getElementById("app").innerHTML = hello;

and our hello.js is a simple module that exports a constant



export const hello = "Hello";

now let's head to our web browser and see how it works.

When we open the webpage, we see a Hello message, which is expected. now let's look at our network tab:

The 2 files that are of interest to us here are the main.js file and hello.js file which has been fetched by our browser. But hold on a minute, why are we having a 304 status code? well here is the thing, when the browser first makes a request for a module, the browser gets back a status code 200 which is fine.. on subsequent requests, if the requested module has not changed, we get a 304 response status code which means not modified.

Note: This concept will serve as a good foundation for understanding how Vitejs serves our source code.

Understanding module bundlers

Module bundlers bundle multiple js files into a single file, that can be downloaded and executed by the browser. Not only javascript files but also bundling images and CSS files into static assets. Now imagine you are building a very large application, and you have multiple modules and also utilize multiple 3rd party libraries. You can see how inefficient this will quickly become in terms of managing all these dependencies, and also for N number of modules you use in your application, your browser will have to make N HTTP requests for those various modules, which is not very ideal. A module bundler will get an entry point, in our case, main.js generate a dependency graph by looking through the dependencies of its dependencies, and bundle that into one javascript file our browser can execute.

Module bundlers also provide functionality like dev servers, Hot module replacement, and more. Examples of some module bundlers are Webpack, Rollup, Parcel, and Vitejs.

We have gotten an idea of how JavaScript modules work, and we have also seen what module bundlers are and how they work. Now that the basic foundation is laid, let's move to understand how Vitejs operates and how it improves your development experience

Understanding Vitejs

With traditional bundlers, they build and serve files during development and create optimized builds for production when needed. This is fine and is what most devs have been comfortable with for years, but the benefits of building files during development and production weigh more on the production side and could be very uncomfortable to deal with during development. Other Bundlers often face the following problems:

Slow server start in large apps since app modules/components need to be built and served
Slow updates to reflect changes since the whole application has to be rebuilt and served

Vite js provides the best of both worlds(optimization for development and production) by serving our files/components via native ES modules during development and creating static assets for production.

How Vitejs solves slow server start time

With other module bundlers like Webpack, during server start, the module bundler traverses the dependencies of dependencies(generates dependency graph), creates a bundle, and then serves this bundle. This is the typical behavior with applications with no code splitting, hence components that are not currently being displayed or not necessary are also bundled, causing very large applications with many modules/components to take some time to be bundled and served.

Vite js solves this by dividing our application modules into 2 categories: dependencies, and source code. The dependencies are 3rd party libraries that don't change during development and are quite large and expensive to process. Vitejs prebuilds these dependencies using ESbuild, a module bundler written in Go which is 10x faster than other javascript-based module bundlers. The source code is non-plain components/files that need to be transformed to plain JS (JSX components and CSS ) and are often edited and changed during the development process. So in summary, during the initial server start, only our main entry file and its dependencies are transformed to Js and served to our browser via native ESM.

How Vitejs solves slow updates

Most modern module bundlers support Hot Module Replacement(HMR), which is simply updating just the edited module and reflecting its changes in the browser without rebuilding the entire application and causing the browser to reload which will lead to the application state being lost. But even HMR could be slow for most very large applications, hence they might be a slight delay for changes to be reflected. Vitejs solve this by:

Performing HMR via native Es module: when a file is updated, a single HTTP request is made to download just the updated file/module with the help of 304 not modified status code as we saw earlier, making updates consistently fast regardless of the size of your application.
Vitejs Caches dependencies are initially pre-built with ESbuild in our browser, hence preventing unnecessary dev-server requests.

Bundling for production

Vite js uses Rollup under the hood to create optimized production-ready static assets. Hence Vitejs uses ESbuild to pre-build dependencies during development and Rollup for production builds.

Conclusion

Vite js is an amazing tool, which will help to improve your development experience and also create optimized production builds. Vitejs should be the go-to bundler for your next front-end dev project.

Create reusable button Components with React,Typescript , Tailwind and Tailwind-variants 2025

Teyim Asobo — Mon, 29 Jan 2024 11:34:14 +0000

So, You write a few components here and there and have written some button components of your own. But then your button components are not flexible and reusable enough, and you end up rewriting a lot of logic and styles within your react components trying to make it fit different cases in different parts of your application,

Well, you are in the right place. This article serves as an easy-to-follow guide on how to create a reusable and flexible button component using React, Typescript, Tailwind CSS, and the Tailwind-variant package.

Hi, I am a senior frontend Engineer currently in search of freelance work (upwork), and full-time roles (Github), Will appreciate any referrals or opportunities you bring my way. Thanks

Prerequisites

As mentioned above, we will be using React, Typecript, and Tailwind CSS when building our components, so basic knowledge of creating components using these will help you better understand how things work together. of course, if u have not used Tailwind CSS before, you are welcome to follow along as Tailwind is straightforward.

Project Setup

Now let's set things up so we can start building our component. we will start by creating a simple React + Typescript + Tailwind CSS project.

Create a simple React project with Vite:

npm create vite@latest

Follow the prompts to finish the setup process.

Setup Tailwind in the project:

Visit the Tailwind website and follow the simple installation guide here

Install tailwind-variants:

npm install tailwind-variants

Tailwind Variants is a first-class variant API library for Tailwind CSS. it helps us create variants of UI components that could be based on a design system easily.

Creating Button Styles

Now that we are done setting everything up, we can go ahead and start setting the base styles for the button component. Create a components folder, in the src folder of your application. Add a button folder and add 2 files in this folder: a Button.tsx file which is our main button component and a ButtonStyles.ts file which will hold all our button style variants. You should end up with something like this:

Great. now let's dive into the ButtonStyles.ts components and add some basic button styles.

We are going to create a baseButton variant, this variant will contain all the base styles that every button should have. We do this by importing tv from tailwind-variants, passing it an object containing our styles, and assigning that to the baseButton constant

import { tv } from 'tailwind-variants';

export const baseButton = tv({
  base: 'text-center relative font-semibold whitespace-nowrap align-middle outline-none inline-flex items-center justify-center select-none',
  variants: {
    size: {
      xs: 'text-xs py-1 px-2',
      md: 'text-sm py-2 px-4',
      lg: 'text-base py-3 px-6',
      xl: 'text-lg py-4 px-8',
      xxl: 'text-xl py-5 px-10',
      square_xs: 'text-xs h-4 w-4 p-1',
      square_sm: 'text-sm h-6 w-6 p-1',
      square_md: 'text-base h-8 w-8 p-1',
      square_lg: 'text-lg h-10 w-10 p-1',
      square_xl: 'text-xl h-12 w-12 p-1',
    },
    vPadding: {
      xs: 'py-[4px]',
      sm: 'py-[8px]',
      md: 'py-[12px]',
      lg: 'py-[16px]',
    },
    vSpace: {
      xs: 'my-1',
      sm: 'my-2',
      md: 'my-4',
      lg: 'my-6',
    },
    HSpace: {
      xs: 'mx-1',
      sm: 'mx-2',
      md: 'mx-4',
      lg: 'mx-6',
    },
    align: {
      center: 'mx-auto',
      right: 'ml-auto',
      left: 'mr-auto',
      top: 'mb-auto',
      bottom: 'mt-auto',
    },
    rounded: {
      none: 'rounded-none',
      xs: 'rounded-[2px]',
      sm: 'rounded-[4px]',
      normal: 'rounded-[8px]',
      lg: 'rounded-[12px]',
      full: 'rounded-full',
    },
    behavior: {
      block: 'w-full',
    },
  },
});

Nice!!, we now have some base styles for our buttons. let's go ahead and create a solid button variant with 4 colors: Green, Teal, Yellow, and Gray

// create solid button styles
export const solidButton = tv({
  extend: baseButton,
  variants: {
    color: {
      green:
        'bg-[#58cc02] text-gray-100 shadow active:shadow-none active:translate-y-[5px]',
      teal: 'bg-[#0D9488] text-gray-100 shadow-teal active:shadow-none active:translate-y-[5px]',
      yellow:
        'bg-[#FFC700] text-gray-100 shadow-yellow active:shadow-none active:translate-y-[5px]',
      gray: 'bg-[#64748B] text-gray-100 shadow-blueGray active:shadow-none active:translate-y-[5px]',
    },
  },
});

We extend all the variants and styles from the base button and then add custom variants that will apply to solid buttons. this means a solid button will have a color, and size, can be rounded, and have all the other properties from the baseButton. For the custom shadow, I added new box-shadow variables in my tailwind config.

/** @type {import('tailwindcss').Config} */
export default {
  content: ['./index.html', './src/**/*.{js,ts,jsx,tsx}'],
  theme: {
    boxShadow: {
      DEFAULT: '0 3px 0 #57a300',
      teal: '0 3px 0 #0F766E',
      yellow: '0 3px 0 #E49E00',
      blueGray: '0 3px 0 #475569',
      none: 'none',
    },
    extend: {},
  },
  plugins: [],
};

Now, when creating button components, there are several things we need to in mind:

We want our button to extend the attributes of the native HTML button tag
We want the variant styles to be applied to our button
We might want to be able to override button variant styles with custom styles via the className attribute

With all these in mind, our Button component will look something like this

/* eslint-disable react/jsx-props-no-spreading */
import { forwardRef, useMemo } from "react";
import { type VariantProps } from "tailwind-variants";
import { TbLoader } from "react-icons/tb";
import { outlineButton, solidButton,ghostButton } from "./ButtonStyles";

// define all the button attributes
type BaseButtonAttributes = React.ComponentPropsWithoutRef<"button">;

// define the ref type
type Ref = HTMLButtonElement;

// extend the base button attributes
interface ButtonProps extends BaseButtonAttributes {
  isLoading?: boolean;
  disabled?: boolean;
  leftIcon?: React.ReactElement;
  rightIcon?: React.ReactElement;
  buttonStyle?: VariantProps<typeof solidButton |typeof outlineButton|typeof ghostButton>;
  className?:string,
  buttonVariant?: "solid" | "outline" | "ghost";
}

const Button = forwardRef<Ref, ButtonProps>((props, ref) => {
  // destructure neccesary props
  const { type, children, buttonStyle, buttonVariant, disabled, isLoading, leftIcon, rightIcon,className, ...rest } = props;

  // determine icon placement
  const { newIcon: icon, iconPlacement } = useMemo(() => {
    let newIcon = rightIcon || leftIcon;

    if (isLoading) {
      newIcon = <TbLoader className="animate-spin" size={25} />;
    }

    return {
      newIcon,
      iconPlacement: rightIcon ? ("right" as const) : ("left" as const),
    };
  }, [isLoading, leftIcon, rightIcon]);

  const renderButtonVariant=()=>{
    if(buttonVariant==="solid"){
      return solidButton({...buttonStyle,className})
    }
   }

  return (
    <button
      className={renderButtonVariant()}
      {...rest}
      type={type ? "submit" : "button"}
      ref={ref}
      disabled={disabled || isLoading}
    >
      {/** render icon before */}
      {icon && iconPlacement === "left" ? (
        <span className={`inline-flex shrink-0 self-center ${children && !isLoading && "mr-2"}`}>{icon}</span>
      ) : null}

      {/** hide button text during loading state */}
      {!isLoading && children}

      {/** render icon after */}
      {icon && iconPlacement === "right" ? (
        <span className={`inline-flex shrink-0 self-center  ${children && !isLoading && "ml-2"}`}>{icon}</span>
      ) : null}
    </button>
  );
});

// set default props
Button.defaultProps = {
  buttonStyle: {},
  buttonVariant: "solid",
  isLoading: false,
  disabled: false,
  leftIcon: undefined,
  rightIcon: undefined,
};

export default Button;

that's a lot of code, but don't worry, let's get a closer look at some parts of this Button component.

Button Props

// define all the button attributes
type BaseButtonAttributes = React.ComponentPropsWithoutRef<"button">;

// extend the base button attributes
interface ButtonProps extends BaseButtonAttributes {
  isLoading?: boolean;
  disabled?: boolean;
  leftIcon?: React.ReactElement;
  rightIcon?: React.ReactElement;
  buttonStyle?: VariantProps<typeof solidButton>;
  className?:string,
  buttonVariant?: "solid";
}

Here, we define the basic props of the component. our ButtonProps is an interface that extends all the attributes of a button e.g. onClick, ref, type, and more. taking a closer look at this we see the buttonStyle prop and buttonVariant prop. The buttonStyle prop is used to set various styles for a button which we defined in the ButtonStyles.ts file e.g. size, color, rounded, and more. Thanks to Typescript, we get amazing intellisence for this when working with our Button.

Rendering Icons

  // determine icon placement
  const { newIcon: icon, iconPlacement } = useMemo(() => {
    let newIcon = rightIcon || leftIcon;

    if (isLoading) {
      newIcon = <TbLoader className="animate-spin" size={25} />;
    }

    return {
      newIcon,
      iconPlacement: rightIcon ? ("right" as const) : ("left" as const),
    };
  }, [isLoading, leftIcon, rightIcon]);

Here we use the useMemo hook to run an anonymous arrow function that returns the icon passed to our button and its placement.

Great!!, now we have set up our Button component and we are ready to call it in another component and render some buttons.

Rendering Button

In my App.tsx component I import my Button component and call it like so:

 <div className="p-6 space-x-4 flex-wrap">
        <Button buttonStyle={{ color: 'green', rounded: 'lg', size: 'md' }}>
          Button
        </Button>
        <Button buttonStyle={{ color: 'teal', rounded: 'lg', size: 'md' }}>
          Button
        </Button>
        <Button buttonStyle={{ color: 'yellow', rounded: 'lg', size: 'md' }}>
          Button
        </Button>
        <Button buttonStyle={{ color: 'gray', rounded: 'lg', size: 'md' }}>
          Button
        </Button>

results:

Nice!! , we have rendered 4 buttons with different colors. now let's create more Button variants called an Outline Button and Ghost Button.

In our ButtonStyles.ts we will add these button variants

//create outline button styles
export const outlineButton = tv({
  extend: baseButton,
  base: 'ring-1',
  variants: {
    color: {
      green:
        'ring-[#58cc02] text-[#58cc02] shadow active:shadow-none active:translate-y-[5px]',
      teal: 'ring-[#0D9488] text-[#0D9488] shadow-teal active:shadow-none active:translate-y-[5px]',
      yellow:
        'ring-[#FFC700] text-[#FFC700] shadow-yellow active:shadow-none active:translate-y-[5px]',
      gray: 'ring-[#64748B] text-[#64748B] shadow-blueGray active:shadow-none active:translate-y-[5px]',
    },
  },
});

//create ghost button styles
export const ghostButton = tv({
  extend: baseButton,
  variants: {
    color: {
      green: 'text-[#58cc02]',
      teal: 'text-[#0D9488]',
      yellow: 'text-[#FFC700]',
      gray: 'text-[#64748B]',
    },
  },
});

Again, this is very similar to our Solid Button variant. But our styles for the various colors have changed. With this, we can make use of these new variants in our buttonStyle prop, and also modify our buttonVariant prop to have our new variants

// extend the base button attributes
interface ButtonProps extends BaseButtonAttributes {
  isLoading?: boolean;
  disabled?: boolean;
  leftIcon?: React.ReactElement;
  rightIcon?: React.ReactElement;
  buttonStyle?: VariantProps<typeof solidButton |typeof outlineButton|typeof ghostButton>;
  className?:string,
  buttonVariant?: "solid" | "outline" | "ghost";
}

and our renderButtonVariant function now looks like this:

 const renderButtonVariant=()=>{
    if(buttonVariant==="solid"){
      return solidButton({...buttonStyle,className})
    }
    if(buttonVariant==="outline"){
      return outlineButton({...buttonStyle,className})
    }
    return ghostButton({...buttonStyle,className})
  }

Now let's render some new Button variants in our App.tsx component

 <div className="p-6 space-x-4">
        <Button
          buttonStyle={{ color: 'green', rounded: 'lg', size: 'md' }}
          buttonVariant="outline"
        >
          Button
        </Button>
        <Button
          buttonStyle={{ color: 'teal', rounded: 'lg', size: 'md' }}
          buttonVariant="outline"
        >
          Button
        </Button>
        <Button
          buttonStyle={{ color: 'yellow', rounded: 'lg', size: 'md' }}
          buttonVariant="outline"
        >
          Button
        </Button>
        <Button
          buttonStyle={{ color: 'gray', rounded: 'lg', size: 'md' }}
          buttonVariant="outline"
        >
          Button
        </Button>
      </div>
 <div className="p-6 space-x-4">
        <Button
          buttonStyle={{ color: 'green', size: 'md' }}
          buttonVariant="ghost"
        >
          Button
        </Button>
        <Button
          buttonStyle={{ color: 'teal', size: 'md' }}
          buttonVariant="ghost"
          leftIcon={<TbAdFilled size={20} />}
        >
          Button
        </Button>
        <Button
          buttonStyle={{ color: 'yellow', size: 'md' }}
          buttonVariant="ghost"
          rightIcon={<TbAdFilled size={20} />}
        >
          Button
        </Button>
        <Button
          buttonStyle={{ color: 'gray', size: 'md' }}
          buttonVariant="ghost"
          rightIcon={<TbAdFilled size={20} />}
        />
      </div>

results:

We can also try out different button states like the loading state

 <Button buttonStyle={{ color: 'green', rounded: 'lg', size: 'md' } isLoading >
  Button
 </Button>

results:

Overriding Styles

There might be situations where we might need to override our button styles, maybe we need that button just 2px wider or some other edge case has come up and you just need to modify a button without touching the base styles we set. We can easily do that with the className attribute

 <div className="flex p-6">
        <Button
          className="px-[100px]"
          buttonStyle={{
            color: 'green',
            rounded: 'lg',
            size: 'md',
            align: 'center',
          }}
        >
          Button
        </Button>
      </div>

and the button looks like this

Conclusion

Tailwind-variants provide a flexible approach to building modern components for our Tailwind CSS with Typescript projects. This is great, especially when building design systems using Tailwind CSS.

live code -code link

Effortless Testing Setup for React with Vite, TypeScript, Jest, and React Testing Library 2025

Teyim Asobo — Sun, 28 Jan 2024 09:00:55 +0000

Recently, I have been learning to write some tests in React using Jest and RTL(React Testing Library), which has been a fun and eye-opening adventure so far. Setting up testing in a Nextjs app which I used to practise testing was not too complicated, and I managed to get things working. I recently wanted to start writing some tests for a project I am working on which is a React+Vitejs, and Typescript application. This proved challenging to set up, resulting in me looking through a few outdated articles here and there, pulling a hair or 2, and almost crying about why the gods of testing were against me. Thankfully, I finally resolved my errors and had my tests running smoothly.

This post therefore serves as an easy-to-follow, updated guide on how to set up testing with Jest and React-testing-library in your Vite + Typescript application.

Hi, I am a senior frontend Engineer currently in search of freelance work (upwork), and full-time roles (Github), Will appreciate any referrals or opportunities you bring my way. Thanks

Challenges faced

While setting up the test in my Vite project, the 2 major problems that are commonly faced are:

Configuring Jest to handle SVG images
Handling path aliases (absolute imports) with Jest

In this post, we solve the above problems and set up testing in our application. Without wasting much time, let's jump right in.

Setting up a Vite project

Let's get started by creating a simple Vite project. Run the following command to create a React application using Vite: npm create vite@latest . Follow the instructions and select the necessary dependencies

Now, cd into your project directory and run npm install to install all dependencies.

Installing Jest and React testing library

Now let's install Jest and RTL and other related dependencies:

npm install -D jest @testing-library/react ts-jest @types/jest ts-node @testing-library/jest-dom jest-environment-jsdom @testing-library/user-event

and wait for the packages to finish installing.

Great, now if you open your package.json file, you should see all of these packages as dev dependencies.

Now create a jest.setup.ts file with the following code :

import "@testing-library/jest-dom";

Also, create a jest.config.js file with the following configuration code

export default {
  testEnvironment: "jsdom",
  transform: {
    "^.+\\.tsx?$": "ts-jest",
  },
  setupFilesAfterEnv: ["<rootDir>/jest.setup.ts"],
};

Handling Styles and SVG's

Now we need 2 more packages for our test to run correctly, the first package is identity-obj-proxy which will help jest transform files with the extension .css, .less, .sass, or .scss. When a file with any of these extensions is imported into your code during testing, Jest will substitute the import with the identity-obj-proxy module. This is a common technique for mocking stylesheets in Jest tests.

The second package we need is jest-transformer-svg. When an SVG file is imported into your code during testing, Jest will substitute the import with the jest-transformer-svg module. This suggests that there might be a custom transformer (jest-transformer-svg) configured for transforming SVG files during the testing process.

To install this package, run:
npm install -D identity-obj-proxy jest-transformer-svg

After successfully installing, modify your jest.config.js file to look like so:

export default {
  testEnvironment: "jsdom",
  transform: {
    "^.+\\.tsx?$": "ts-jest",
  },

  moduleNameMapper: {
    "\\.(css|less|sass|scss)$": "identity-obj-proxy",
    "^.+\\.svg$": "jest-transformer-svg",
  },

  setupFilesAfterEnv: ["<rootDir>/jest.setup.ts"],
};

Great!!, we have done a lot of configuration, let's write a test and see if things work correctly. Firstly, head over to your package.json and add the following script : "test": "jest"

Let's create a simple component that renders a list of users, with some tests for that component. Create a components folder in the src directory and create users folder with a Users.tsx file and a Users.spec.tsx file.

the Users.tsx component looks like this

const Users = () => {
  return (
    <div>
      <h1>Users</h1>
      <ul>
        <li>name 1</li>
        <li>name 2</li>
      </ul>
    </div>
  );
};

export default Users;

Our test for this component in the Users.spec.tsx file looks like this

import { render, screen } from "@testing-library/react";
import Users from "./Users";

describe("User", () => {
  test("renders heading", async () => {
    render(<Users />);
    expect(screen.getByRole("heading", { name: "Users" })).toBeInTheDocument();
  });

  test("renders a list of users", async () => {
    render(<Users />);
    const users = await screen.findAllByRole("listitem");
    expect(users).toHaveLength(2);
  });
});

We have a simple component with some test setup. let's try to run our test using the npm run test command.

Our test passes..in some cases, this will fail because of the following Typescript error:

We fix this by including our jest.setup.ts file in our tsconfig.json file like so:

{
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true
  },
  "include": ["src", "./jest.setup.ts"],
  "references": [{ "path": "./tsconfig.node.json" }]
}

Specifically, we add ./jest.setup.ts as an array value of the include property. Our Typescript error now disappears and our test runs smoothly.

Handling absolute imports

When setting up our applications, some of our applications might be making use of absolutes imports for clean and readable import statements. However, using absolute imports with Jest will need tiny adjustments, Firstly let's set up absolute import or path aliases in our Vite app and then make it work with Jest. To do that, we need to install the following package

npm install -D vite-tsconfig-paths

After successful installation, we need to modify the vite.config.ts file and the tsconfig.json file. add the following code as part of the compilerOptions property

//absolute import
    "baseUrl": "./src",
    "paths": {
      "@/*": ["./*"]
    }

Our tsconfig.json file looks like this

{
  "compilerOptions": {
    "target": "ES2020",
    "useDefineForClassFields": true,
    "lib": ["ES2020", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "skipLibCheck": true,

    /* Bundler mode */
    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx",

    /* Linting */
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true,

    //absolute import
    "baseUrl": "./src",
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["src", "./jest.setup.ts"],
  "references": [{ "path": "./tsconfig.node.json" }]
}

We also modify our vite.config.ts file

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tsconfigPaths from "vite-tsconfig-paths";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react(), tsconfigPaths()],
});

In your jest.config.ts file, add "^@/(.*)$": "/src/$1" to the moduleNameMapper property.

export default {
  testEnvironment: "jsdom",
  transform: {
    "^.+\\.tsx?$": "ts-jest",
  },

  moduleNameMapper: {
    "\\.(css|less|sass|scss)$": "identity-obj-proxy",
    "^.+\\.svg$": "jest-transformer-svg",
    "^@/(.*)$": "<rootDir>/src/$1",
  },

  setupFilesAfterEnv: ["<rootDir>/jest.setup.ts"],
};

Amazing!! now you can import components like so:

import Counter from "@/components/counter-two/Counter-two";

using the @ path alias and use them in your test.

Getting test coverage report

Most often when writing tests, we need to know the test coverage. Code coverage reports provide insights into how much of your code is covered by tests. We need a command to Instruct Jest to generate code coverage reports after running the tests. Add the following command to your script in the package.json file

"coverage": "npm test --coverage --watchAll --collectCoverageFrom='src/components/**/*.{ts,tsx}'",

We then run npm run coverage . This runs Jest in watch mode and provides the coverage report after every test run.

Conclusion

Setting up tests in React+Vite and Typescript applications is not that straightforward, as we often face a lot of challenges while setting it up. This post serves as an updated, step-by-step, easy-to-follow guide on setting up tests in your React+Vite and Typescript applications.

Code: Github link

Using Zustand to Manage State in React App

Teyim Asobo — Wed, 07 Sep 2022 13:15:09 +0000

Building modern web applications often implies our application is made up of several components, which we need to keep in sync by sharing some state between them. State management libraries like Zustand, provide an intuitive way to share state through out our applications, by providing a centralized store for our state ,solving issues like prop drilling. This article aims to guide the user on how to get started with Zustand in their react application.

What is Zustand

Zustand is a small, fast and scalable state management solution that uses simplified flux principles, is based on hooks and has little to no boilerplate code. Having about 20.6k stars on github, Zustand is becoming one of the most loved state management solutions thanks to its simplicity.

- small
Zustand is one of the smallest state management libraries with a bundle size of just 1.16kb.

- fast
Zustand is fast, thanks to its small size and little boilerplate code, making us have instantaneous UI updates on changes to our state.

- scalable
With Zustand, we can create a store, which is a central point of truth where all our global app state resides in. Our store is simply a hook, which we can easily import and use where needed. making Zustand very scalable.

Enough talk, lets get out hands dirty by building a simple todo application and use Zustand to manage state, so you get to see how things work

Getting started with React and Zustand

Setting up Zustand in our react app is as easy as setting up our react app with any other npm dependency. To get things started, run the following command



npx create-react-app todo-app
cd todo-app
npm install zustand

or if you already have an existing react app, simply run



npm install zustand
yarn add zustand

Now that our state management library is all setup in our react app, we can start working with it. My App.js file is very simple



function App() {

  const inputRef = useRef();

  return (
    <div>
      <div style={{ justifyContent: 'center', display: 'flex', padding: '15px' }}>
        <input type={'text'} placeholder='enter user name' style={{ padding: '10px,15px' }} ref={inputRef} />
        <button >Add</button>
        <button >fetch</button>
      </div>
      <div style={{ display: 'flex', justifyContent: 'center', marginTop: '20px', borderTop: '1px solid black' }}>
        <ul style={{ textAlign: 'center', }}>
        </ul>
      </div>
    </div>
  );
}

export default App;

A Very simple UI for our todo app. An input box, 2 buttons, and an unordered list to render todo elements.

Creating and Accessing our Store

creating store

In our src folder, we create a store.js file which will contain our global state. Our store.js file looks like this



import create from 'zustand';

let store = () => ({
    users: [{ id: 1, name: 'Teyim Asobo' }, { id: 2, name: 'Fru Brian' }],
})

export const useStore = create(store);

Here, we have created a simple store using the create function imported from Zustand. Our store is a hook (useStore), and can be accessed any where in our application via a simple import. Our store currently contains an array of users, with 2 users initialiased.

Now that our store is created, lets try to access our state from our App.js component.

Accessing store

We can bind our components to our state, by calling our hooks from anywhere in our applications




import { useStore } from './store'
import { useRef } from 'react';

function App() {
  const inputRef = useRef();
  const users = useStore(state => state.users)
  return (
    <div>
      <div style={{ justifyContent: 'center', display: 'flex', padding: '15px' }}>
        <input type={'text'} placeholder='enter user name' style={{ padding: '10px,15px' }} ref={inputRef} />
        <button >Add</button>
        <button >fetch</button>
      </div>
      <div style={{ display: 'flex', justifyContent: 'center', marginTop: '20px', borderTop: '1px solid black' }}>
        <ul style={{ textAlign: 'center', }}>
          {users?.map(user => (
            <li key={user.id}>
              {user.name}
              <button style={{ marginLeft: '15px' }}>delete</button>
            </li>
          ))}

        </ul>
      </div>
    </div>
  );
}

export default App;

We have imported our useStore hook from our store, used it to store the users state in a users variable, which we then render out as list of users

Updating our State

To be able to update our state, we will create 2 new properties in our store, addUser and deleteUser which we will use to update our state immutably. The store.js file now looks like this



import create from 'zustand';

let store = (set) => ({
    users: [{ id: 1, name: 'Teyim Asobo' }, { id: 2, name: 'Fru Brian' }],
    addUser: (user) => set((state) => ({ users: [...state.users, user] })),
    deleteUser: (userId) => set((state) => ({ users: state.users.filter(user => user.id !== userId) }))
})

export const useStore = create(store);

Now, back in our App.js component, we store the addUser and deleteUser store properties in variables.



import shallow from 'zustand/shallow'
import { useStore } from './store'

const { addUser, deleteUser, users} = useStore(
    (state) => ({ users: state.users, addUser: state.addUser, deleteUser: state.deleteUser}),
    shallow
  )

Here, we construct a single object with multiple state-picks for a cleaner and better looking code, rather than using atomic state picks. Shallow is a function we import from Zustand. by default, when using atomic state picks, Zustand detects changes with strict-equality (old === new). when constructing a single object with multiple picks, this is not efficient because the object will always be recreated and hence (oldObject !== newObject) therefore will not trigger a UI update. The Shallow function tells Zustand to compare state values by moving into the object itself and comparing its keys, if any one is different, then it triggers an update.
our App.js file now looks like this



function App() {
  const { addUser, deleteUser, users } = useStore(
    (state) => ({ users: state.users, addUser: state.addUser, deleteUser: state.deleteUser}),
    shallow
  )
  const inputRef = useRef();

  const addUserHandler = () => {
    addUser({ id: users.length + 1, name: inputRef.current.value })
    inputRef.current.value = ''

  }

  return (
    <div>
      <div style={{ justifyContent: 'center', display: 'flex', padding: '15px' }}>
        <input type={'text'} placeholder='enter user name' style={{ padding: '10px,15px' }} ref={inputRef} />
        <button onClick={addUserHandler}>Add</button>
        <button>fetch</button>
      </div>
      <div style={{ display: 'flex', justifyContent: 'center', marginTop: '20px', borderTop: '1px solid black' }}>
        <ul style={{ textAlign: 'center', }}>
          {users?.map(user => (
            <li key={user.id}>
              {user.name}
              <button onClick={() => { deleteUser(user.id) }} style={{ marginLeft: '15px' }}>delete</button>
            </li>
          ))}

        </ul>
      </div>
    </div>
  );
}

export default App;

addUser and deleteUser can be used as normal functions to add and remove users from state.

Handling Async actions

Zustand makes storing async data in state very easy. To demonstrate this, we are going to use mockapi.io to create some dummy data which we can access via an API which mockapi.io provides.



let store = (set) => ({
    users: [{ id: 1, name: 'Teyim Asobo' }, { id: 2, name: 'Fru Brian' }],
    addUser: (user) => set((state) => ({ users: [...state.users, user] })),
    deleteUser: (userId) => set((state) => ({ users: state.users.filter(user => user.id !== userId) })),
    fetchUser: async (endpoint) => {
        const reponse = await fetch(endpoint)
        const userData = await reponse.json()
        set({ users: userData })
    }
})

We recieve an api endpoint via the fetchUser property, fetch the data from the endpoint, convert this data to JSON and then use the set function to set this data to our state.
We can then call and use fetchUser in our App.js component.



function App() {
  const { addUser, deleteUser, users, fetchUser } = useStore(
    (state) => ({ users: state.users, addUser: state.addUser, deleteUser: state.deleteUser, fetchUser: state.fetchUser }),
    shallow
  )
  const inputRef = useRef();

  const addUserHandler = () => {
    addUser({ id: users.length + 1, name: inputRef.current.value })
    inputRef.current.value = ''

  }

  return (
    <div>
      <div style={{ justifyContent: 'center', display: 'flex', padding: '15px' }}>
        <input type={'text'} placeholder='enter user name' style={{ padding: '10px,15px' }} ref={inputRef} />
        <button onClick={addUserHandler}>Add</button>
        <button onClick={() => fetchUser('https://62fa5e3affd7197707eb05e4.mockapi.io/users')}>fetch</button>
      </div>
      <div style={{ display: 'flex', justifyContent: 'center', marginTop: '20px', borderTop: '1px solid black' }}>
        <ul style={{ textAlign: 'center', }}>
          {users?.map(user => (
            <li key={user.id}>
              {user.name}
              <button onClick={() => { deleteUser(user.id) }} style={{ marginLeft: '15px' }}>delete</button>
            </li>
          ))}

        </ul>
      </div>
    </div>
  );
}

export default App;

The API endpoint gives us a list of 50 users, which we then store in our state. The output looks like this

Persisting data and using Devtools

Zustand provides easy to use middlewares, which we can use to persist data, and to track state via redux devtools. by default, Zustand persist data using localstorage hence state is not lost after page refresh. A common use case may be when dealing with Auth state, or a simple cart functionality in your E-commerce application where the user still sees a list of cart items even after re-visting the site. To persist our app state, we import the persist middleware from Zustand



import { persist} from 'zustand/middleware'

let store = (set) => ({
    users: [],
    addUser: (user) => set((state) => ({ users: [...state.users, user] })),
    deleteUser: (userId) => set((state) => ({ users: state.users.filter(user => user.id !== userId) })),
    fetchUser: async (endpoint) => {
        const reponse = await fetch(endpoint)
        const userData = await reponse.json()
        set({ users: userData })
    }
})

store = persist(store, { name: 'user' })
export const useStore = create(store);

When we now click on the fetch button to fetch a list of users from our API endpoint which is then stored in state, our state is persisted in local storage with key users.

Using Devtools

Zustand provides a middleware called devtools, which we can import and use to track our state changes using the Redux Dev tools browser extension. you might be familiar with this if you have worked with Redux before.



store = persist(store, { name: 'users' })
store = devtools(store);
export const useStore = create(store);

Above, we have persisted our store in local storage and passed our store to our Devtools middleware. We can now monitor and track our state in the browser.

Conclusion

Zustand is a state management library that helps developers to manage application state, with its strong holds being it having a small size and easy to setup. Relative to other libraries like Redux, Zustand helps developers manage complex application state using hooks. After reading this guide, you should be able to :

Setup Zustand in your React application
Create a store
Access and modify state in store
Store data in state via Async request
Persist state in local storage and use Redux dev tools to track and monitor state.