DEV Community: Neil Chen

Enhance User Experience with Automatic Token Refresh

Neil Chen — Sun, 03 Sep 2023 03:24:35 +0000

The Security Implications of Token-Based Authorization

Token-based authentication employs a token to access backend services. However, the more frequently a token is used, the higher the risk of it being compromised. To improve security, a prevalent approach is using a "refresh token". Instead of relying on a single token to access the API throughout a session, two distinct tokens are used.

Understanding Access and Refresh Tokens

Post the login phase, users are provided with two tokens: the Access Token and the Refresh Token. The authorization service issues these tokens, along with some associated metadata.

{
    "access_token": "<access_token>",
    "refresh_token": "<refresh_token>",
    "expiring_time": "<expiring_time>",
    "user_id": "<user_id>"
}

The Access Token, primarily for API access, is more vulnerable to exposure. Thus, it has a set expiration time (e.g., 30 minutes). When it expires, the Refresh Token is used to procure a new Access Token.

Streamlining the Implementation

The primary goal in frontend design is to shield users from the complexities of the token-refreshing process. Some guides suggest renewing the token just before it expires. However, this doesn't account for all scenarios.

For instance, if the backend loses its login status due to updates or replication issues, tokens can expire prematurely. Consequently, clients might lose access, compelling users to re-login, which isn't ideal.

We'll now delve into a method to navigate these challenges, ensuring a seamless user experience.

Refresh Token Based on Status, Not Just Time

Every API call is examined. If a token has expired, a specific error informs us. Using AWS Cognito service as an illustration:

// Status Code 401
{
  "errors" : [ {
    "errorType" : "UnauthorizedException",
    "message" : "Valid authorization header not provided."
  } ]
}

We can inspect the error and intercept it before it affects our client-side operations. For this, we utilize "axios".

Axios offers an Interceptor function. It allows for additional procedures before sending requests or after receiving responses.

axios.interceptors.response.use(function (response) {
    // Any status code that lie within the range of 2xx cause this function to trigger
    // Do something with response data
    return response;
  }, function (error) {
    // Any status codes that falls outside the range of 2xx cause this function to trigger
    // Do something with response error
    return Promise.reject(error);
});

In the response phase, an interceptor is set up to manage token expiration issues, and it tries to fetch a new access token. If successful, the original request is resent. This ensures that, during daily operations with our axios instance, we rarely confront authorization challenges.

Below is the detailed structure of our refresh token interceptor:

import type { AxiosInstance, AxiosRequestConfig, AxiosError } from 'axios';

interface TaskItem {
  originalRequest: AxiosRequestConfig;
  resolve: <T>(value?: T | PromiseLike<T>) => void;
  reject: (reason?: any) => void;
}

interface Config {
  axiosInstance: AxiosInstance;
  authorizeHeaderName: string;
  checkIfIsAuthErr: (status: number, data: any) => boolean;
  /**
   * Handler refresh logic, resolve with the new token str
   */
  refreshTokenHandler: () => Promise<string>;
  onRefreshTokenFailed?: () => void;
}

type AxiosRefreshToken = (
  refreshConfig: Config,
) => (err: AxiosError) => Promise<Promise<any>>;

const createAxiosAuthErrHandler: AxiosRefreshToken = (refreshConfig) => {
  const {
    axiosInstance,
    authorizeHeaderName,
    checkIfIsAuthErr,
    refreshTokenHandler,
    onRefreshTokenFailed,
  } = refreshConfig;

  let isRefreshing = false;
  const tasks: TaskItem[] = [];

  const axiosRefreshTokenInterceptor = async (
    err: AxiosError,
  ): Promise<Promise<any>> => {
    // reject if it not the axios error
    if (!err.response) throw err;

    const {
      config,
      response: { status, data },
    } = err;

    if (!checkIfIsAuthErr(status, data)) throw err;

    if (!isRefreshing) {
      isRefreshing = true;
      try {
        const newAccessToken = await refreshTokenHandler();
        isRefreshing = false;
        tasks.forEach((item) => {
          if (!item.originalRequest.headers) return;
          item.originalRequest.headers[authorizeHeaderName] = newAccessToken;
          item.resolve(axiosInstance(item.originalRequest));
        });
      } catch (refreshErr: InstanceType<Error>) {
        isRefreshing = false;
        tasks.forEach((item) => {
          item.reject(refreshErr);
        });
        //onRefreshTokenFailed?.();
      }
    }

    return new Promise((resolve, reject) => {
      tasks.push({
        originalRequest: config,
        resolve,
        reject,
      });
    });
  };

  return axiosRefreshTokenInterceptor;
};

export { createAxiosAuthErrHandler };

Upon facing an expiration issue, we don't immediately convey the rejection to our operational layer. Instead, we issue a new promise, postponing its execution until a new Access Token is received. If token refresh fails, appropriate actions (like resetting the login session or retrying the login) are initiated.

All we need to do now is register the interceptor with Axios:

const axiosRefreshTokenInterceptor = createAxiosAuthErrHandler({
      axiosInstance: fetchInstance,
      authorizeHeaderName: AUTH_HEADER,
      checkIfIsAuthErr: (status, data) =>
        status === 401 &&
        data?.errors?.[0]?.errorType === 'UnauthorizedException',
      refreshTokenHandler: refreshLogin,
      onRefreshTokenFailed: oauthLogin,
    });

const interceptor = fetchInstance.interceptors.response.use(
      (response) => response,
      async (err: AxiosError) => {
        const res = await axiosRefreshTokenInterceptor(err);
        return res;
      },
);

Conclusion

This article elucidated a prevalent challenge in client-side development. All measures detailed here aim to enhance user and developer experiences alike. Developers are thus relieved from fretting over token expiration during their routine tasks. We hope you found this informative and helpful!

Make Your Global Components Elegant with EventTarget

Neil Chen — Thu, 20 Apr 2023 10:35:30 +0000

What Are Global Components and EventTarget?

Global Components

Thanks to the component architecture, we can encapsulate state and logic into a small section. However, for some types of UI that exist in the global context and can be called from anywhere in the code, and it will be rendered as floating or overlay layout (such as Global Alert or Global Loading), we need a component that doesn't belong to a specific screen. I call these types of components Global Components.

EventTarget

EventTarget is a native browser API that is a separate constructor from the DOM's EventTarget interface. It can be a good browser implementation for EventEmitter, which already exists in Node.js's event module.

Want more detail? do check this Article for EventTarget

We can use EventTarget to listen and broadcast commands and information throughout the whole app without explicitly calling the impacted object. In other words, it makes global message passing easy.

class MyTarget extends EventTarget {}
const target = new MyTarget();
target.addEventListener(
    'sayHi',
    (event) => console.log(`sayHi to ${event.detail.name}`)
);
target.dispatchEvent(
    new CustomEvent('sayHi', { detail: { name: 'John' }  })
);

Global Alert with EventTarget

To implement a Global Alert in React, we usually use two major options: Global State Management Libraries (like Redux or Recoil) or Context.

For the first choice, we need to add another library, which adds another layer of dependency for this component, making it harder to maintain and less portable.

For the second option, you can only access the command in the hooks or components with useContext, and since we usually let this type of component wrap the root of the UI tree, it will trigger lots of unnecessary re-renders for the whole app.

And the most important part: for Global Alert, we don't care about its state like shown or not, but only how to trigger it.

So is there a simple pattern to fulfill this requirement? Yes, the old but gold EventTarget is here for you.

Below is the example with MUI:

import { useState, useEffect } from 'react';
import { Snackbar, Alert, AlertProps } from '@mui/material';

interface AlertInfo {
  type: AlertProps['severity'];
  text: string;
}

class AlertEventTarget extends EventTarget {}
const alertEventTarget = new AlertEventTarget();

export const globalAlert = (alertInfo: AlertInfo) =>
  alertEventTarget.dispatchEvent(
    new CustomEvent('alert', { detail: { alertInfo } }),
  );

export const GlobalAlert = () => {
  const [isOpen, setIsOpen] = useState(false);

  const [alertInfo, setAlertInfo] = useState<AlertInfo>({
    type: 'success',
    text: 'success',
  });

  useEffect(() => {
    alertEventTarget.addEventListener('alert', (e) => {
      setIsOpen(true);
      setAlertInfo(
        (e as CustomEvent<{ alertInfo: AlertInfo }>).detail.alertInfo,
      );
    });
  }, []);

  return (
    <Snackbar
      open={isOpen}
      anchorOrigin={{ vertical: 'top', horizontal: 'center' }}
      autoHideDuration={6000}
      onClose={() => setIsOpen(false)}
    >
      <Alert severity={alertInfo.type} sx={{ width: '100%', mt: 8 }}>
        {alertInfo.text}
      </Alert>
    </Snackbar>
  );
};

We can simply put this Global Alert Component anywhere, ideally in App.tsx, and call it everywhere. Since we're not relying on the Context, we can even call it outside the hooks!

// App.tsx
import { GlobalAlert } from '@/components/GlobalAlert'
const App = () => {
  return (
    <>
      <AppContent />
      <GlobalAlert />
    </>
  );
};

// In the component/hook
import { globalAlert } from '@/components/GlobalAlert'
const ExampleComponent = () => {
  return (
    <>
      <button
        onClick={() =>
          globalAlert({ type: 'success', text: 'trigger alert successfully!' })
        }
      >
        Trigger Alert
      </button>
    </>
  );
};

// In the pure function outside the hooks
import { globalAlert } from '@/components/GlobalAlert'
const exampleRequest = async () => {
  try {
    axios.post('/api/v1/xxx');
  } catch (e) {
    globalAlert({ type: 'error', text: e.message });
  }
};

With this pattern, we get the following benefits:

No unnecessary dependencies, making the component more portable
No need to use useContext or any other setup code to execute a little alert
Available calling alert outside the hook!

Global Loading Component Design

To explore more, we can extend this idea to Global Loading, like Overlay Loading or the Top Loading Bar, which are both quite common UI designs nowadays.

We can take a look at the final outcome at the beginning:

// App.tsx
import { GlobalOverlayLoading } from '@/components/GlobalOverlayLoading'
const App = () => {
  return (
    <>
      <AppContent />
      <GlobalOverlayLoading />
    </>
  );
};

// In normally components/hooks usage
import { useGlobalOverlayLoading } from '@/components/globalOverlayLoading';
const ExampleComponent = () => {
  const [isLoading, setIsLoading] = useState(false);
  useGlobalOverlayLoading(isLoading);
  return <>Content</>;
};

const ExampleHook = () => {
  const [isLoading, setIsLoading] = useState(false);
  useGlobalOverlayLoading(isLoading);
};

As presented, we can see how easy it is to trigger the global overlay loading with just one hook with just one state prop! There's no need to import this component in every part of the tree. Simple and elegant.

To reach this result, we need more effort, but everything will be worth it in the long term!

First Version of Design

The biggest thing we need to deal with is: how to handle state changing from different parts of the component tree simultaneously? Because we only have one Global Loading component, but it will receive multiple states at the same time, and we need to stop the loading animation after all the loading is done.

For the first version, we can let the hook caller pass an identifying key to the hook:

const ExampleHook2 = () => {
  const [isLoading, setIsLoading] = useState(false);
  useGlobalOverlayLoading('ExampleHook2_Key', isLoading);
};

This way, we can identify the different hooks or components to let them decide if the loading should stop. With this approach, we get the first version of the design:

import { Backdrop, CircularProgress } from '@mui/material';
import { useState, useEffect, useRef } from 'react';

class LoadingEventTarget extends EventTarget {}
const loadingEventTarget = new LoadingEventTarget();

interface LoadingEventDetail {
  key: string;
  isLoading: boolean;
}

export const useGlobalOverlayLoading = (key: string, state: boolean) => {
  useEffect(() => {
    loadingEventTarget.dispatchEvent(
      new CustomEvent<LoadingEventDetail>('setLoading', {
        detail: { key, isLoading: state },
      }),
    );

    return () => {
      loadingEventTarget.dispatchEvent(
        new CustomEvent<LoadingEventDetail>('setLoading', {
          detail: { key, isLoading: false },
        }),
      );
    };
  });
};

export const GlobalOverlayLoading = () => {
  const [isShow, setIsShow] = useState(false);

  const storeRef = useRef<{ [key: string]: boolean }>({});

  useEffect(() => {
    loadingEventTarget.addEventListener('setLoading', (e) => {
      const { key, isLoading } = (e as CustomEvent<LoadingEventDetail>).detail;
      let shouldShowLoading = false;
      storeRef.current[key] = isLoading;
      for (const prop in storeRef.current) {
        if (storeRef.current[prop]) {
          shouldShowLoading = true;
          break;
        }
      }
      setIsShow(shouldShowLoading);
    });
  }, []);

  return (
    <>
      {isShow && (
        <Backdrop
          sx={(theme) => ({
            zIndex: theme.zIndex.modal + 1,
          })}
          open
        >
          <CircularProgress sx={{ color: '#fff' }} />
        </Backdrop>
      )}
    </>
  );
};

However, we wondered if we could make the process even simpler by just passing the loading state itself. To generate a unique ID for each hook or component, we introduced a cool React pattern called Hook Counter.

Hook Counter

let counter = 0;
const useHookCounter = () => {
  const [uniqKey] = useState(`key_${counter++}`);
};

The code inside the useState hook is only executed when the hook is initialized, and the resulting state is preserved between each re-render, giving us a stable key to use. So, whenever a new component calls the useHookCounter hook, we can obtain a unique identifier to identify it.

Combine EventTarget & Hook Counter

By combining Hook Counter and EventTarget, we were able to achieve our desired outcome with minimal effort and higher flexibility and readability. The final result is presented below:

import { Backdrop, CircularProgress } from '@mui/material';
import { useState, useEffect, useRef } from 'react';

class LoadingEventTarget extends EventTarget {}
const loadingEventTarget = new LoadingEventTarget();

interface LoadingEventDetail {
  key: string;
  isLoading: boolean;
}

let counter = 0;
export const useGlobalOverlayLoading = (state: boolean) => {
  const [key] = useState(`key_${counter++}`);

  useEffect(() => {
    loadingEventTarget.dispatchEvent(
      new CustomEvent<LoadingEventDetail>('setLoading', {
        detail: { key, isLoading: state },
      }),
    );

    return () => {
      loadingEventTarget.dispatchEvent(
        new CustomEvent<LoadingEventDetail>('setLoading', {
          detail: { key, isLoading: false },
        }),
      );
    };
  });
};

export const GlobalOverlayLoading = () => {
  const [isShow, setIsShow] = useState(false);

  const storeRef = useRef<{ [key: string]: boolean }>({});

  useEffect(() => {
    loadingEventTarget.addEventListener('setLoading', (e) => {
      const { key, isLoading } = (e as CustomEvent<LoadingEventDetail>).detail;
      let shouldShowLoading = false;
      storeRef.current[key] = isLoading;
      for (const prop in storeRef.current) {
        if (storeRef.current[prop]) {
          shouldShowLoading = true;
          break;
        }
      }
      setIsShow(shouldShowLoading);
    });
  }, []);

  return (
    <>
      {isShow && (
        <Backdrop
          sx={(theme) => ({
            zIndex: theme.zIndex.modal + 1,
          })}
          open
        >
          <CircularProgress sx={{ color: '#fff' }} />
        </Backdrop>
      )}
    </>
  );
};

Conclusion

In this article, we explored a way to design Global Components using the browser-native API, EventTarget, which allows for a global data passing workflow with minimized setup effort. For global state control that requires accessing and checking data, such as navigation or theme, we still recommend using Redux and Context. However, keep in mind that this will add another layer of complexity. We hope this pattern inspires you to design the architecture of your React application!

Frontend Integration Test with Graphql Mocking

Neil Chen — Tue, 18 Apr 2023 09:04:53 +0000

Last Updated: 2023/05/15

Why Frontend Integration Test ?

In accordance with the Frontend Testing Philosophy outlined by Kent C. Dodds, the most valuable type of test for frontend developers to write is an integration test. This type of test strikes a good balance between effort and code quality confidence.

So, what should we test in frontend integration tests to achieve the best confidence and minimize effort in maintaining and coding these tests?

In my opinion, UI operations and API calls are the most important aspects, as they are fully controlled by the frontend application. Anything that occurs after the API call requires backend dependencies, and we have no responsibility to ensure that the database update logic or data synchronization works correctly. Therefore, testing any UI updates based on data fetching is not worth the effort. Additionally, we need to implement some part of the backend logic to return the newest data we just sent, which is not worth the effort either.

Playwright as a solution

As the philosophy presented, we need to make our test and environment as close to the real production environment as possible. Instead of using an interceptor like mock-axios, which would be injected into the frontend code, we can choose a testing framework like Playwright that provides API mocking on the browser side. This means that passing test cases ensure that our web app will work perfectly in the production environment, assuming that the backend service is functioning properly.

Please refer to the official document to set up Playwright in your current project.

Once you have set up the basic testing environment, you can write a test case that triggers an API request with Playwright's API mocking method (keep in mind that it mocks the API at the browser layer, so you don't need to modify your frontend codebase).

Here's an example:

import { test, expect } from '@playwright/test';

test('has title', async ({ page }) => {
  await page.route('https://backend.api', async (route) => {
    const json = {
      message: { msg: "It's a test message!" },
    };
    await route.fulfill({ json });
  });

  await page.goto('https://myApp.frontend/');

  await expect(page).toHaveTitle(/MyApp/);
});

However, writing API mocking for every API in each test can be tedious. Instead of using the beforeEach hook, you can use Fixtures in Playwright to create a global mocking layer for your default API, making code maintenance easier.

Here's an example:

// helper.ts
import { test as baseTest } from '@playwright/test';

export const test = baseTest.extend({
  model: async ({ page }, use) => {
    await page.route('https://backend.api', async (route) => {
      const json = {
        message: { msg: "It's a test message!" },
      };
      await route.fulfill({ json });
    });
  },
});

//example.test.ts
import { test } from './helper';

test('should add an item', async ({ model }) => {
  // ...
});

test('should remove an item', async ({ model }) => {
  // ...
});

// All tests will have the mock API effect!

Make Playwright works with Graphql

GraphQL is built on top of the HTTP POST request, so we only need to parse the request body to extract information about the request. To simplify this process, we can use a popular mock helper library - MSW as a GraphQL parser (which we'll explore in more detail in the next post).

// handleRoute.ts
import type { Route } from '@playwright/test';
import type { RequestHandler } from 'msw';
import { Headers } from 'headers-polyfill';
import { handleRequest, MockedRequest, type MockedResponse } from 'msw';
import EventEmitter from 'events';

const emitter = new EventEmitter() as Parameters<typeof handleRequest>[3];

export const handleRoute = async (route: Route, handlers: RequestHandler) => {
  try {
    const request = route.request();

    let requestHeaders = {};
    try {
      requestHeaders = await request.allHeaders();
    } catch {}

    const headers = new Headers(requestHeaders);
    const method = request.method();
    const url = new URL(request.url());
    const postData = request.postData();

    const mockedRequest = new MockedRequest(url, {
      method,
      headers,
      body: postData ? Buffer.from(postData) : undefined,
    });

    const handleMockResponse = async ({
      status,
      headers,
      body,
      delay,
    }: MockedResponse) => {
      if (delay) {
        await new Promise((resolve) => {
          setTimeout(resolve, delay);
        });
      }

      return route.fulfill({
        status,
        body: body ?? undefined,
        contentType: headers.get('content-type') ?? undefined,
        headers: headers.all(),
      });
    };

    await handleRequest(
      mockedRequest,
      [],
      {
        onUnhandledRequest: () => {
          console.error('no match handler');
        },
      },
      emitter,
      {
        resolutionContext: {
          /**
           * @note Resolve relative request handler URLs against
           * the server's origin (no relative URLs in Node.js).
           */
          baseUrl: url.origin,
        },
        onMockedResponse: handleMockResponse,
      },
    );
  } catch (err) {
    console.error(err);
  }
};

// helper.ts

import { test as baseTest, expect as baseExpect } from '@playwright/test';
import type { RequestHandler } from 'msw';
import { handleRoute } from './handleRoute';

type fixtures = {
  model: { addHandler: (handlers: RequestHandler) => void };
};

export const test = baseTest.extend<fixtures>({
  model: [
    async ({ page }, use) => {
      // if you want to have some default hadlers, you can put them into this array
      const handlers: RequestHandler[] = [];

      await page.route('**/graphql', (route) => handleRoute(route, handlers));

      use({
        addHandler: (handler: RequestHandler) => handlers.unshift(handler),
      });
    },
    { auto: true },
  ],
});

With above configuration we finally can add handler directly in our test!

  //example.test.ts
  import { test } from './helper';
  import { graphql } from 'msw';

  test('example test', async ({ page, model }) => {
    model.addHandler(
      graphql.query('GetAllUsers', (req, res, ctx) => {
        return res(
          ctx.data({
            users: [
              {
                firstName: 'John',
                lastName: 'Maverick',
              },
              {
                firstName: 'Cathaline',
                lastName: 'McCoy',
              },
            ],
          }),
        );
      }),
    );

    await page.goto('http://frontend,app/users');
  });

The Frustration of writing Mocking Data

Writing mock data for integration tests can be frustrating, especially if your service keeps evolving, and each field of the API could change. We need a better way to make our lives easier.

Only when writing or maintaining tests doesn't consume too much time, can we push our test coverage to the next level. Fortunately, we have many tools available in the community for automatically generating RESTful APIs and GraphQL mock data with pre-defined schemas. We can rely on these tools to keep the implementation between the frontend and backend in sync.

Graphql Codegen for generating Mock Data

When your project starts to adopt GraphQL, you'll find many codegen tools that can help you improve your code quality. Today, we'll use a mature codegen tool called GraphQL Code Generator.

Please follow the official document to set up the environment.

We will depend on two useful plugins: TypeScript Mock Data and TypeScript MSW.

TypeScript Mock Data

With this plugin, you can generate mock data statically or dynamically based on your GraphQL schema using well-known mock data libraries such as Casual or Faker. It also makes writing mock data with default values easier. You can specify only the crucial attribute related to the test. For example:

scalar AWSTimestamp

type User {
  id: ID!
  name: String!
  avatar: Avatar
  status: Status!
  updatedAt: AWSTimestamp
}

// generated mock data configuration with Casual static data
export const aUser = (overrides?: Partial<User>): User => {
  return {
    id: overrides && overrides.hasOwnProperty('id') ? overrides.id! : 'a5756f00-41a6-422a-8a7d-d13ee6a63750',
    name: overrides && overrides.hasOwnProperty('name') ? overrides.name! : 'libero',
    avatar: overrides && overrides.hasOwnProperty('avatar') ? overrides.avatar! : anAvatar(),
    status: overrides && overrides.hasOwnProperty('status') ? overrides.status! : Status.Online,
    updatedAt: overrides && overrides.hasOwnProperty('updatedAt') ? overrides.updatedAt! : 1458071232,
  };
};

// In test case
import * as mockData from './generated'
const user = mockData.aUser({ name: 'johndoe' });

TypeScript Msw

This plugin integrates Graphql Codegen and MSW, allowing for the generation of API mocking helpers with strong types. This provides maximum benefits for writing API mocking. For example:

query GetUser($id: ID!) {
  getUser(id: $id) {
    name
    id
  }
}

mockGetUserQuery((req, res, ctx) => {
  const { id } = req.variables

  return res(
    ctx.data({
      getUser: { name: 'John Doe', id }
    })
  )
})

With these two brilliant plugins, we can write our mock APIs smoothly without losing any of the side properties that the API should respond with. For example:

 mockGetUserQuery((req, res, ctx) => {
    const { id } = req.variables

    return res(
      ctx.data({
        getUser: mockData.aUser({ login: 'johndoe' });
      })
    )
  })

Combine with Playwright Graphql Mocking

Combine the example in the previous part, we can write our code quite smoothly like follow:

//example.test.ts
import { test } from './helper';
import * as mock from './generated'

test('example test', async ({ page, model }) => {
  model.addHandler(
    mock.mockGetUserQuery((req, res, ctx) => {
      const { id } = req.variables

      return res(
        ctx.data({
          getUsers: [
            mockData.aUser({ name: 'johndoe' }),
            mockData.aUser({ name: 'charle' })
          ]
        })
      )
    })
  );

  await page.goto('http://frontend,app/users');
 });

Testing Mutation

So far, we have only demonstrated the use of mock data with queries. However, in most cases, we also need to test mutations, such as form submissions or order placements.

Since we can dynamically control API handlers, we can inject mutations into our handlers and test if the variables being passed to the backend are correct.

mutation UpdateUser($id: ID!, $name: String) {
  updateUser(input: { id: $id, name: $name }) {
    id
  }
}

//example.test.ts
import { test } from './helper';
import * as mock from './generated'

test('update user', async ({ page, model }) => {
  const targetUser = mock.aUser();
  const editedUserName = 'test_user_name';

  let isVarsRight = false;

  model.addHandler(
    mock.mockUpdateUser((req, res, ctx) => {
      const { id, name } = req.variables;
      expect(id).toEqual(targetUser.id);
      expect(name).toEqual(editedUserName);
      isVarsRight = true;
      return res(ctx.data({} as any));
    }),
  );

  await page.goto('http://frontend,app/user');

  await page.getByLabel('name').fill(editedUserName);
  await page.getByTestId('SaveIcon').click();

  expect(isVarsRight).toBeTruthy();
});

You may find it odd that we need a flag called isVarsRight and expect it at the end of the test. This is because the expect function in the handler's callback runs outside of the test process, and any errors it produces will not be captured by Playwright.

Conclusion

This article only showcases some of the potential of using Graphql Codegen with Playwright to significantly improve the developer experience when writing frontend integration tests. As Graphql becomes more and more popular, I'm excited to see what other solutions the community will come up with. However, our team is quite satisfied with our current workflow. I hope that these articles can serve as a starting point or source of inspiration for you to build a better frontend test infrastructure!

A Better Way to Design a Loading Button Component

Neil Chen — Mon, 17 Apr 2023 15:15:58 +0000

UI Feedback for Loading

When a user clicks a submit button that sends a request, we need to provide a loading UI feedback to inform the user that the backend is processing the request. A simple way to implement this is to have a global overlay loading animation that blocks the user's actions and makes them wait. However, this implementation can make users feel that they are not in control. To improve the user experience, we usually choose to have a button that can turn into a loading state.

The Burden of Repetitive Work

Handling requests and making each button change between loading and enabled states can be quite annoying. Although there are solutions like the useMutation hook in React Query, which can wrap the implementation details of the fetching and return the isLoading state for you to pass to the button props, sometimes we don't want to add another layer of fetching with hooks, or we want to make a pure request using other libraries like Redux or pure axios fetch. In such cases, we can use the following technique to make our lives easier.

Loading Button Component Design

We can create a custom button component with the following code:

import { useState } from 'react';

interface LoadingButtonProps {
  isLoading?: boolean;
  onClick: () => void | Promise<void>;
  text?: string;
}

const LoadingButton = (props: LoadingButtonProps) => {
  const { isLoading, onClick, text } = props;

  const [isInternalLoading, setIsInternalLoading] = useState(false);

  const handleClick = async () => {
    setIsInternalLoading(true);
    try {
      await onClick();
    } finally {
      setIsInternalLoading(false);
    }
  };

  if (isLoading || isInternalLoading) {
    return <button disabled>Loading...</button>;
  }

  return <button onClick={handleClick}>{text}</button>;
};

We can then use this custom button component as follows:

const ExampleView = () => {
  return (
    <>
      <p>
        The Loading Button will change the loading state based on async function calling.
      </p>
      <LoadingButton
        onClick={async () => {
          await new Promise((resolve) => setTimeout(resolve, 1000));
        }}
      />
    </>
  );
};

The Loading Button component will change its loading state automatically, and we also have the flexibility to explicitly pass the isLoading state to this component to fulfill other situations.


const ExampleView2 = () => {
  const [isLoading, setIsLoading] = useState(false);

  return (
    <>
      <p>
        The Loading Button will change the loading state based on the passed props.
      </p>
      <LoadingButton
        isLoading={isLoading}
        onClick={() => {
          console.log('sync function calling');
        }}
      />
    </>
  );
};

Conclusion

Today I share a simple pattern to make fetch loading handling easier. I hope this little technique can help you to organize your code better and inspire you for other use cases!