Forem: Łukasz

Deploy NextJS app to GitHub Pages using GitHub Actions

Łukasz — Mon, 19 Apr 2021 09:22:25 +0000

GitHub pages allow us to host static sites from a repository. NextJS can be used as a static site generator. If we combine these two things and add some GitHub Action we get a React-based website that is easy to maintain, test, and host.

Prepare NextJS application

To generate static output we need to add next export command that creates a static version of the application.

  "scripts": {
    "dev": "next dev",
    "build": "next build",
+   "export": "next export",
    "start": "next start"
  },

According to the NextJS documentation, there is a few caveats we must meet (e.g. we can not use getServerSideProps because of static rendering without a server) for successfully export. If you use a default next/image loader, you have to add an default loader.

If our NextJS application is ready, we should try npm run build && npm run export command. Output Export successful. means that the application is ready to deploy.

If you want to use a custom domain just add a CNAME file to public directory.

GitHub Page

To host a website on GitHub Pages we have to activate it in repository settings. We can select a custom domain (in this case you have to add the CNAME file that contains an address and change DNS). You can also check the Enforce HTTPS option.

Every .dev domain is on the HSTS preload list, which makes HTTPS required on all connections. So if you want to use .dev domain you have to check Enforce HTTPS

GitHub Action

GitHub provides 2,000 Actions minutes/month for free accounts. It is more than enough to check how it works and use it in some side projects.

Let's move to create GitHub Action. Enter your project on GitHub then navigate to Actions tab and choose Node.js By GitHub Actions (name of the action is up to you).

I used the following script:

# This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

name: GitHub Pages deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2.3.1
      - name: Use Node.js 14.x
        uses: actions/setup-node@v1
        with:
          node-version: "14.x"

      - name: Installing my packages
        run: npm ci

      - name: Build my App
        run: npm run build && npm run export && touch ./out/.nojekyll

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@4.1.0
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH: gh-pages # The branch the action should deploy to.
          FOLDER: out # The folder the action should deploy.

I think that this yml file is easy to understand. Some rough explanations:

action will be triggered on every push to main branch,
Ubuntu will be used as OS (you can also choose Windows or macOS),
in the first step script will checkout our code from the repository and use NodeJS in the given version,
npm ci is used to install packages instead of npm install because it is faster than what we care about due to GitHub Actions limitations,
step named Build my App is the main one:
- npm run build && npm run export builds and exports app,
- run: touch ./out/.nojekyll is because the _next folder is by default not served by GitHub because of Jekyll processing, .nojekyll file prevents that,
github-pages-deploy-action is used to push a static exported site to gh-pages branch.

npm ci used in action requires package-lock.json that isn't created by yarn. There are some ways to handle it (e.g. yarn install --frozen-lockfile), but I decided to just use npm instead of yarn.

Summary

Now we can serve a static website on free hosting with automated deployment on push to main. Https is provided by GitHub Pages. The only cost is custom domain (if we want to). Other static site generators like Gatsby, Jekyll, or Hugo (on almost every website you can read that their framework is the fastest one) can be used with GitHub Pages and Actions almost the same way as NextJS.

Check out a repository with an example application of NextJS app built with described GitHub Action that is hosted right here.

Originally published at https://lukaszwozniak.dev on April 18, 2021.

Testing of redux-thunk action

Łukasz — Sat, 17 Apr 2021 07:40:31 +0000

In this post, I will present some practical approaches to test an application that uses thunks from the redux-thunk library.

While browsing the web looking for ways and good practices to test redux state, many times I came across tests that check implementation details, not logic.

I don't see much sense in such an approach, which will almost certainly be expensive to maintain - testing will become sensitive to change. What should be of interest to us is the effect of dispatched action on the state and possible check of selectors, if we have any.

Thunk implementations test

// Arrange
const store = mockStore(initialState);

// Act
await store.dispatch(someThunkFunction(requestPayload));

// Assert
const expectedActions = [
  someImplementedFunction_1(true), // expectation of implementation details
  someImplementedFunction_2("some param"),
  someImplementedFunction_3(123),
];
const actions = store.getActions();

expect(actions).toEqual(expectedActions);

The above example checks the actions executed by someThunkFunction. The mockStore function used in the example comes from the redux-mock-store library.

Imagine you are doing refactoring and changing the implementation of someThunkFunction. From now on, calling two instead of three functions will set the appropriate state of the application.

someImplementedFunction_1(true),
+ someImplementedFunction_2('some param', 123),
- someImplementedFunction_3(123)

If we change its implementation details, e.g. it will contain 2 actions instead of 3, but the effect on the state remains the same - the test will not pass. The information from this test is, in my opinion, useless.

State test after thunk dispatch

In this post, I will focus on testing async thunk action. We skip testing actions and action-creators because they should not contain anything worth testing (the example presented at the end of the post is based on the Redux Toolkit, which manages them itself). Single actions and selectors should be trivial.

We dispatch the thunk and check the state of the application we are interested in with the appropriate selectors (if we have any). Otherwise, we compare individual elements of the obtained state with expectations (never add additional selectors only for testing!). This allows us to freely modify someThunkFunction.

As long as the state is correct - we have a green test and we do not bother with it. If the result is different after the changes, we will get valuable information. We will see what the state after the dispatch looks like and decide whether to fix the implementation or adapt the test to the new state.

// Arrange
const store = mockStore(initialState);

// Act
await store.dispatch(someThunkFunction(requestPayload));

// Assert
const expectedState = {
  app: {
    someBoolean: true,
    someString: "some param",
    someNumber: 123,
  },
};
const state = store.getState();

expect(state).toEqual(expectedState);

Example of redux-thunk test

To write tests as shown, you must enable state creation with an initial value of preloadedState.

// getStore.ts

const rootReducer = combineReducers({
  epics: epicsReducer,
  tasks: tasksReducer,
});

export const getStore = (preloadedState) =>
  configureStore({
    reducer: rootReducer,
    middleware: [thunk],
    // configureStore with preloadedState
    preloadedState,
  });

In our simple example, we have an array of Epic and Task objects. Tasks have an epicId field indicating the Epic they belong to. We will try to write test that removes epic with id === 0 and tasks with epicId === 0.

// epicsSlice.ts

const preloadedState = {
  epics: {
    list: [
      { id: 0, name: "epic 0" }, // epic to remove
      { id: 1, name: "epic 1" },
    ],
  },
  tasks: {
    list: [
      { id: 0, epicId: 0, name: "epic 0 first task" }, // task to remove (epicId: 0)
      { id: 1, epicId: 0, name: "epic 0 second task" }, // task to remove (epicId: 0)
      { id: 2, epicId: 1, name: "epic 1 first task" },
      { id: 3, epicId: 1, name: "epic 1 second task" },
    ],
  },
};

Let's create the method removeEpicAndItsTasksThunk that removes an Epic and all Tasks pointing to that Epic based on the given id. To complicate the example a bit, we will add a Promise that returns ids of Tasks to delete.

export const removeEpicAndItsTasksThunk = createAsyncThunk(
  "removeEpicAndItsTasks",
  async (epicId, { getState, dispatch }) => {
    const state = getState();

    const tasksId = await new Promise((resolve) => {
      console.log("Waiting for some async action.");

      setTimeout(() => {
        const ids = state.tasks.list
          .filter((task) => task.epicId === epicId)
          .map((task) => task.id);

        console.log("Async action resolved after (at least) 2000ms.");
        resolve(ids);
      }, 2000);
    });

    dispatch(removeTasksById(tasksId));
    dispatch(removeEpicById(epicId));
  }
);

Arrange

Thanks to preloadedState we can initialize the state the way we need. As I mentioned - we want to be sure, that the Epic and all Tasks in this Epic will be removed.

// Arrange
const preloadedState = {
  epics: {
    list: [
      { id: 0, name: "epic 0" }, // epic to remove
      { id: 1, name: "epic 1" },
    ],
  },
  tasks: {
    list: [
      { id: 0, epicId: 0, name: "epic 0 first task" }, // task to remove (epicId: 0)
      { id: 1, epicId: 0, name: "epic 0 second task" }, // task to remove (epicId: 0)
      { id: 2, epicId: 1, name: "epic 1 first task" },
      { id: 3, epicId: 1, name: "epic 1 second task" },
    ],
  },
};

const expectedEpicList = [{ id: 1, name: "epic 1" }];

const expectedTaskList = [
  { id: 2, epicId: 1, name: "epic 1 first task" },
  { id: 3, epicId: 1, name: "epic 1 second task" },
];

const store = getStore(preloadedState);

Act

The only thing Act does is call removeEpicAndItsTasksThunk with some id (0 in our case). Additionally, we cover removeTasksById and removeEpicById methods.

// Act
await store.dispatch(removeEpicAndItsTasksThunk(0));

Assert

In this section, we check if the state after calling removeEpicAndItsTasksThunk method is correct. Besides, we test two selectors: getEpicsList and getTasksList.

// Assert
const state = store.getState();
const epicList = getEpicsList(state);
const taskList = getTasksList(state);

expect(epicList).toEqual(expectedEpicList);
expect(taskList).toEqual(expectedTaskList);

Summary

The presented approach of thunk testing provides high code coverage. We do not check implementation details, only the result. We increase the resistance of tests to change in the code that do not affect the resulting state of the application

Check out a repository with described example.

Originally published at https://lukaszwozniak.dev on March 30, 2021.