Forem: Cathal Mac Donnacha 🚀

Route-based code splitting with React

Cathal Mac Donnacha 🚀 — Fri, 04 Aug 2023 13:31:28 +0000

Code splitting is a technique used to optimize the loading performance of web apps by breaking down the bundled JavaScript files into smaller, more manageable chunks. By loading only the required code for a specific route or page, route-based code splitting significantly reduces the initial load time and improves the overall user experience.

In this article, we will explain some aspects of how we can achieve route-based code splitting along with some code examples.

Why Route-based Code Splitting?

When developing large-scale applications, loading all the JavaScript code upfront can lead to increased initial load times and negatively impact user experience. In contrast, route-based code splitting allows you to divide your application into smaller chunks based on different routes or features. Only the code relevant to the current route is loaded, resulting in faster loading times for the specific page and better overall application performance.

By using route-based code splitting, you can prioritize the most critical code for each route, optimizing the initial loading experience and reducing the time to interactive (TTI).

What do we need?

In order to actually implement route-based code splitting, we need to make use of two things:

Let's take a look at these in a bit more detail.

Dynamic import

Dynamic import is an ECMAScript feature that allows us to import modules on the fly. This is really powerful and unless you're unlucky enough to have to support IE, it can be used in all major browsers.

Here's what the syntax looks like:

import('./path-to-my-module.js');

import will return a promise, so you would handle it just like any other promise within your app.

import('./carModule.js')
  .then(module => {
    module.startEngine();
  })
  .catch(error => {
    console.error('Error loading carModule:', error);
});

// or you can use async/await
const carModule = await import('./carModule.js');
carModule.startEngine();

A great use case for this would be when you only make use of a heavy module in a specific part of your app.

<button onClick={onSortCarsClick}>Sort cars<button/>

function onSortCarsClick() {
  // Load in the heavy module
  const carModule = await import('./carModule.js');
  carModule.sortCars();
}

React.lazy()

React.lazy() is a function in React that enables you to perform "lazy" or "on-demand" loading of components. It ensures that the component will only be loaded when it's actually rendered.

Before React.lazy() was introduced, you might have needed to set up a more complex build tooling configuration to achieve similar code splitting behavior. With React.lazy(), this process is simplified and integrated directly into React's core.

const MyLazyComponent = React.lazy(() => import('./MyComponent'));

Suspense

Since the component is no longer statically imported, we need to display something while it's dynamically loading. For that, we use React's <Suspense> boundary.

In the example below, you'll see we are displaying some fallback UI while the component is being loaded.

<Suspense fallback={<div>Loading...</div>}>
  <MyLazyComponent/>
</Suspense>

Show me the code

Here's a full example of how we can use a combination of dynamic imports, React.lazy() and React Router to achieve route-based code splitting.

import { lazy, Suspense } from 'react';
import { BrowserRouter as Router, Switch, Route, Link } from 'react-router-dom';

// These components will only be loaded when they're actually rendered.
const Home = lazy(() => import('./components/Home'));
const About = lazy(() => import('./components/About'));
const Contact = lazy(() => import('./components/Contact'));

function App() {
  return (
    <Router>
      <nav>
        <ul>
          <li>
            <Link to="/">Home</Link>
          </li>
          <li>
            <Link to="/about">About</Link>
          </li>
          <li>
            <Link to="/contact">Contact</Link>
          </li>
        </ul>
      </nav>

      <Suspense fallback={<div>Loading...</div>}>
        <Switch>
          <Route path="/about">
            <About />
          </Route>
          <Route path="/contact">
            <Contact />
          </Route>
          <Route path="/">
            <Home />
          </Route>
        </Switch>
      </Suspense>
    </Router>
  );
}

export default App;

Code splitting using bundlers

Modern bundlers have built-in support for code splitting to enable efficient loading of modules. What often happens is when a bundler comes across a dynamic import within your app, it automatically creates a separate chunk (javascript file) which can be loaded later. This way it's not bundled within your main bundle file, and hence improving the initial load time of your app.

Final thoughts

As you can see, code splitting has the potential to give us big performance improvements. However, it's important not to become too obsessed with it as like most performance-related features, it also adds complexity, so only use it where it makes sense. This is why it's often a great first step to only use it for routes, and take it from there.

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now. 👋

Mocking Error, Empty and Loading states with MSW

Cathal Mac Donnacha 🚀 — Tue, 06 Dec 2022 13:40:17 +0000

One of the less exciting things about being a Frontend Developer is having to handle error, empty and loading states. It may not be the most fun thing to do, but it's necessary in order to give your users the best experience possible. Thankfully, Mock Service Worker (MSW) makes this really simple, and in turn...kinda fun. 😀

In this article, we take a look at how we can use MSW to mock these states for both local development and in our tests.

Getting started

While mocking these states, you'll see that we make use of page URL query parameters. I find this to be a great pattern as it gives us the flexibility to change them on the fly using only the browser, which makes developing UIs to handle these scenarios a breeze!

Mocking errors

Here's an example of how you can mock a simple error:

export const handlers = [
  rest.get(`/your/api/endpoint`, (req, res, ctx) => {
    // Check if the '?error=true' query param has been 
    // included in the page url.
    const pageParams = new URLSearchParams(window.location.search);
    const isError = pageParams.get('error') === 'true';

    // Example: http://localhost:3000/your_page_url?error=true
    if (isError) {
      // Query param was found, so return an error response.
      return res(
        ctx.status(404),
        ctx.json({ message: 'Oops! Something went terribly wrong.' })
      );
    }

    // Otherwise - return a 200 OK response.
    return res(ctx.status(200), ctx.json({ data: 'Some cool data' }));
  })
];

As you can see, you have full control over what data MSW will return, depending on the query parameter included in the page URL.

You can also include this same error scenario in your tests:

describe('MyPage', () => {
  afterEach(() => {
    // Make sure to reset page url state after each test, otherwise 
    // tests written after this one will still include the 
    // `?error=true` param.
    window.history.replaceState({}, '', '/');
  });

  it('should display an error for some reason', async () => {
    // Add a query param to the page url so that we get 
    // an error response back.
    window.history.replaceState({}, '', '/?error=true');

    await renderPage();

    // Check that the error message was displayed.
    expect(await screen.findByText('Oops! Something went terribly wrong.')).toBeInTheDocument();
  });
});

Suppressing intentional errors

When testing network errors, you may notice some console.error messages polluting the test output. If this is the case for you, and since these errors are expected, you can simply suppress them inside your test:

it('should display an error for some reason', async () => {
  // Suppress console errors that we intentionally trigger in this test.
  jest.spyOn(console, 'error').mockImplementation(() => {});
}

Mocking empty states

This is similar to mocking errors, but you return an empty response instead:

rest.get(`/your/api/endpoint`, (req, res, ctx) => {
  const pageParams = new URLSearchParams(window.location.search);
  const isEmpty = pageParams.get('empty') === 'true';

  if (isEmpty) {
    // Example: http://localhost:3000/your_page_url?empty=true
    return res(ctx.status(200), ctx.json([]));
  }
})

Mocking loading states

This is something I find extremely useful when developing loading components. Here, we apply an infinite delay to the response so that it never resolves:

rest.get(`/your/api/endpoint`, (req, res, ctx) => {
  const pageParams = new URLSearchParams(window.location.search);
  const isEmpty = pageParams.get('loading') === 'true';

  if (isLoading) {
    // Example http://localhost:3000/your_page_url?loading=true
    return res(ctx.status(200), ctx.json({}), ctx.delay("infinite"));
  }
})

Alternative mocking patterns

Though the examples given above which make use of page URL query parameters are what I recommended, here are some other ways to simulate states:

In tests, you could use runtime overrides so that the response will only occur inside your single test.
Return an error depending on the payload sent. e.g A certain username.
Look up the request URL query parameters using conditional responses. This is similar to what we've used above, except you would get the query parameter from the request URL instead of the page URL.

Utility functions

After using this pattern for a while, I decided to create some utility functions which I've found useful while creating handlers.

isQueryParamPresent()

As you can see from the examples above, we have some code that checks if a page URL query parameter is present:

const pageParams = new URLSearchParams(window.location.search);
const isSomething = pageParams.get('something') === 'true';

This can get quite repetitive when you have multiple query parameters to check for. Let's go ahead and improve this by creating a re-usable utility function:

// utils.ts
export function isQueryParamPresent(
  queryName: string,
  queryValue: string = 'true'
) {
  const searchParams = new URLSearchParams(window.location.search);
  return searchParams.get(queryName) === queryValue;
}

// handlers.ts
import { isQueryParamPresent } from './utils';

export const handlers = [
  rest.get(`/your/api/endpoint`, (req, res, ctx) => {
    if (isQueryParamPresent('error') {
      return res(
        ctx.status(404),
        ctx.json({ message: 'Oops! Something went terribly wrong.' })
      );
    }

    // You can also check for different values (true is the default).
    // Example http://localhost:3000/your_page_url?animal=dog
    if (isQueryParamPresent('animal', 'dog') {
      return res(
        ctx.status(200),
        ctx.json({ type: 'dog', name: 'Banjo' })
      );
    }

    return res(ctx.status(200), ctx.json({ data: 'Some cool data' }));
  })
];

customResponse()

As your project grows, so will your handlers. Having to deal with error, empty and loading scenarios for every single request handler will start to get quite verbose. Therefore, I take advantage of MSW's custom response composition to automatically include these scenarios in each response. It will also add a realistic server delay to the response, mimicking a real-world app. This gives us some nice "built-in" features which are abstracted away from the handlers.

// utils.ts
import { compose, context, response, ResponseTransformer } from 'msw';

export function customResponse(...transformers: ResponseTransformer[]) {
  if (isQueryParamPresent('loading')) {
    return response(
       context.delay('infinite'), 
       context.json({})
    );
  }

  if (isQueryParamPresent('error')) {
    return response(
      context.status(400), 
      context.json({ error: 'Oops! Something went terribly wrong.' })
    );
  }

  if (isQueryParamPresent('empty')) {
    return response(
      context.status(200), 
      context.json([])
    );
  }

  // Return the exact same response transforms which were passed in, 
  // but also add a realistic server delay.
  return response(...transformers, ctx.delay());
}

// handlers.ts
import { customResponse } from './utils';

export const handlers = [
  rest.get(`/your/api/endpoint`, (req, res, ctx) => {
    // Now error, loading and empty states are handled 
    // under the hood by customResponse(). Nifty!
    return customResponse(
      ctx.status(200), 
      ctx.json({ data: 'Some cool data' })
    );
  })
];

These utility functions have really improved the developer experience within our team as we no longer have to write the same error, loading and empty checks over and over. We also used to add delays to every single response individually, so not having to even think about that has been awesome!

Page vs request URL query parameters

Another popular pattern is to use request URL query parameters to return the appropriate response. For example:

rest.post('/your/api/endpoint', async (req, res, ctx) => {
  // Check if the 'userId' param exists in the request url.
  const userId = req.url.searchParams.get('userId')

  if (userId === 'mr-bad-user-1234') {
    return res(
      ctx.status(403),
      ctx.json({ errorMessage: 'User not found' }),
    );
  }
})

The above is fine when only using MSW for tests, but not so great when using it for local development in the browser.

I prefer to use page URL query parameters for the following reasons:

We can achieve the same behaviour across both tests and local development as you will be re-using the same mock definitions.
We can easily change the UI by swapping out query parameters in the browser's URL address bar.
We can bookmark URLs to quickly display certain scenarios, without having to remember the query parameters.

Live code example

Here's a CodeSandbox app where I've added live examples for the scenarios shown above.

You can also run the tests by opening a new terminal within CodeSandbox and running the yarn test command.

Upcoming beta

It's worth mentioning that at the time of writing this article, there's a new and improved version of MSW on the horizon which is currently in beta. Though I look forward to trying it out and applying these patterns to it, I decided to reference the latest production version (0.47.1) as it's what most folks will continue to use for the next while.

Final thoughts

That's about it! You can see just how useful MSW can be, not just for testing, but for local development too. At the end of the day, it's just Javascript, so there's nothing stopping you from returning whatever data you want depending on a query parameter. The sky is truly the limit!

If you found this article helpful or have additional tips, please leave a comment below. 🙂

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now. 👋

Migrating from Create React App (CRA) to Vite

Cathal Mac Donnacha 🚀 — Mon, 22 Aug 2022 09:51:14 +0000

I recently migrated a production app within my company from create-react-app (CRA) to Vite, and the results have been great so far!

In this article, I go through all the steps I took as part of the migration, in the hope that it might help others who are going through the same process.

Why switch?

I want to start by saying that I really like CRA, it's helped me to quickly set up and maintain lots of projects (personal and professional). However, here are some of the reasons why we ultimately decided to make the switch:

No dedicated maintainer.
Slow to release. This will only cause more issues down the line as more features are added to React and Webpack.
Increasing number of vulnerabilities causing github dependabot alerts which our security team require we fix, regardless of it being a build tool or not.
Speed. This wasn't really an issue for me as I rarely restart my dev server and my CI pipeline handles the production build for me. In saying that, the app I'm migrating is quite small, so this may be a bigger deal for those with larger and more complex apps. I certainly wouldn't migrate for this reason alone, but I must admit, the speed improvements are quite impressive.
Vite has matured a lot and the community has grown significantly compared to when I first created this CRA based app 2 years ago. If I was to evaluate both again for a new project, I would choose Vite this time around.

Given all of these, I thought it was time to make the switch.

The only real "disadvantage" to using Vite is that it doesn't type-check your code, it only transpiles it to Javascript. I personally think this is fine as many IDE's nowadays have great Typescript support.

Migration steps

Here are all of the steps I took to migrate from CRA to Vite. It's worth noting that I am migrating a Typescript project, though most of the steps should be similar to Javascript projects.

Let's get started! 😀

1. Install dependencies

We need to install these 4 dependencies:

npm install --save-dev vite @vitejs/plugin-react vite-tsconfig-paths vite-plugin-svgr

Note:

We need vite-tsconfig-paths in order to tell Vite how to resolve absolute paths from the tsconfig file. This way you can import modules like this:

import MyButton from 'components'

instead of

import MyButton from '../../../components'

We need vite-plugin-svgr in order to import SVGs as React components. For example:

import { ReactComponent as Logo } from './logo.svg'.

2. Create Vite config file

Create a vite.config.ts at the root of your project. This is where you specify all of the Vite configuration options.

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import viteTsconfigPaths from 'vite-tsconfig-paths';
import svgrPlugin from 'vite-plugin-svgr';

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

3. Move `index.html`

Move the index.html file from the /public folder out to the root of your project. Find out why this is done here.

4. Update `index.html`

URLs are treated a bit differently in Vite, so we'll have to remove all references of %PUBLIC_URL%. For example:

// Before
<link rel="icon" href="%PUBLIC_URL%/favicon.ico" />

// After
<link rel="icon" href="/favicon.ico" />

We need to also add an entry point to the <body> element:

<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div>
<!-- Add entry point 👇 -->
<script type="module" src="/src/index.tsx"></script>

5. Update `tsconfig.json`

The main things you need to update in the tsconfig.json file are target, lib and types. For example:

{
  "compilerOptions": {
    "target": "ESNext",
    "lib": ["dom", "dom.iterable", "esnext"],
    "types": ["vite/client", "vite-plugin-svgr/client"],
    "allowJs": false,
    "skipLibCheck": false,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "module": "ESNext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react"
  },
  "include": ["src"]
}

You can also take a look at Vite's tsconfig.json file here for reference.

6. Create `vite-env.d.ts` file

Since we're using Typescript, we need to create a vite-env.d.ts file under the src folder with the following contents:

/// <reference types="vite/client" />

7. Remove `react-scripts`

It's time to say goodbye to CRA once and for all. 👋 Run this command to uninstall it: npm uninstall react-scripts.

We can also delete the react-app-env.d.ts file.

8. Update scripts in `package.json`

Since we've removed react-scripts, we now need to update the scripts within package.json to reference vite instead:

"scripts": {
  "start": "vite",
  "build": "tsc && vite build",
  "serve": "vite preview"
},

9. Start it up!

Once you run npm start, you should now hopefully see your app open in the browser, powered by the amazing Vite.

If your app is small enough, this is all you might need to do. Otherwise, read on for more optional steps.

Optional steps

Here are some additional optional steps you can take, depending on your own project setup.

ESLint & Prettier

I've written a separate guide on how you can set up ESLint & Prettier here.

Tests

I've also written a guide on how you can replace Jest with Vitest here.

Environmental variables

It's pretty straightforward to migrate environmental variables, you simply rename REACT_APP_ to VITE_ within your .env files. I just did a find and replace for these and it worked a treat.

Then, instead of referencing the variables using process.env.REACT_APP_, you'll use import.meta.env.VITE_.

You can even go one step further and specify types for your environment variables by creating an env.d.ts file in the src folder. For example:

interface ImportMetaEnv {
  readonly VITE_TOKEN: string;
  readonly VITE_CLIENT_ID: number;
}

interface ImportMeta {
  readonly env: ImportMetaEnv;
}

If you need to check for node environments (i.e development or production), you can do so by using the import.meta.env object:

if (import.meta.env.DEV) {
  // do something in development mode only
}

if (import.meta.env.PROD) {
  // do something in production mode only
}

For more on environmental variables, see these Vite docs.

Change build output folder

In Vite, the default production build folder name is dist, you can change this to CRA's default build folder if needed. I found this useful as my CI/CD scripts all referenced build.

// vite.config.ts

export default defineConfig({
  ...
  build: {
    outDir: 'build',
  },
});

Automatically open the app on server start

Something I liked about CRA is that it would automatically open the app in the browser on server start. Vite has this option too:

// vite.config.ts

export default defineConfig({
  ...
  server: {
    open: true,
  },
});

Change port number

If you need to change the port number from the default 3000, specify like this:

// vite.config.ts

export default defineConfig({
  ...
  server: {
    port: 4000,
  },
});

Benchmarks

Here about some benchmarks I recorded before and after the migration:

	CRA	Vite
npm install	21 seconds	9 seconds
Server startup time (cold)	11 seconds	856 milliseconds
Tests run	17 seconds	14 seconds
Production build	45 seconds	17 seconds
Production build size	886 KB / gzip: 249 KB	656.91 KB / gzip: 195.21 KB

You can really see the improvements in the server startup time, but other than that there wasn't a huge difference. Bear in mind though that this was a very small app, so could be even more important for those larger apps.

Troubleshooting

Here are some errors you may come across:

1. When running npm start, I see the following error: Error: Cannot find module 'node:path'.

Answer: As per this issue, you have to make sure you have updated your node version to 14.18.0 or v16+.

2. When running npm start, I see the following error: No matching export in MODULE_NAME for import TYPE_NAME.

Answer: This often happens when you're using a library with a umd bundle, where Vite expects an ESM bundle. This happened to me with okta-auth-js and the fix was to specifcally tell Vite to load the umd bundle in the Vite config file:

// vite.config.ts

export default defineConfig({
  ...
  resolve: {
    alias: {
      '@okta/okta-auth-js': '@okta/okta-auth-js/dist/okta-auth-js.umd.js',
    },
  },
});

3. My screen is blank after running npm start.

Answer: As per steps 3 and 4, make sure you've moved and updated the index.html file.

Check out the Vite troubleshooting docs for more.

Final thoughts

Overall I've been very happy with Vite. The migration was straightforward and the developer experience has improved significantly. It can do everything CRA can, but with better implementations. If you found this article helpful or have additional tips, please leave a comment below. 🙂

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Setting up ESLint & Prettier in ViteJS

Cathal Mac Donnacha 🚀 — Thu, 11 Aug 2022 09:52:50 +0000

I recently migrated from create-react-app (CRA) to ViteJS, and as part of that, I set up ESLint and Prettier. In this article, I go through all the steps I took.

Let's get started!

1. Install dependencies

We need to install the following dependencies:

ESLint: Our main linter.
Prettier: Our main code formatter.
@typescript-eslint/eslint-plugin: An ESLint plugin which provides rules for TypeScript codebases.
@typescript-eslint/parser: A parser which allows ESLint to lint TypeScript source code.
eslint-config-prettier: An ESLint configuration which disables the formatting rules in ESLint that Prettier is going to be responsible for handling, hence avoiding any clashes.
eslint-plugin-import: Tells ESLint how to resolve imports.
eslint-plugin-jsx-a11y: Checks for accessiblity issues.
eslint-plugin-react: React specific linting rules for ESLint.

npm install eslint prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-config-prettier eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react

Something worth noting - when I looked into getting ESLint to work nicely with Prettier, I searched across many open source projects and found these 3 kept popping up:

I kept wondering which I should use as I saw that some projects used all, both, or only one. In the end, I came across this answer on Stack Overflow which helped me understand which plugin was most suitable (eslint-config-prettier).

2. Configure ESLint

Now it's time to configure ESLint.

ESLint config file

First let's create the .eslintrc.js configuration file. I like to create mine as a javascript file so that I can add comments. Here's what it looks like:

module.exports = {
  extends: [
    // By extending from a plugin config, we can get recommended rules without having to add them manually.
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:import/recommended',
    'plugin:jsx-a11y/recommended',
    'plugin:@typescript-eslint/recommended',
    // This disables the formatting rules in ESLint that Prettier is going to be responsible for handling.
    // Make sure it's always the last config, so it gets the chance to override other configs.
    'eslint-config-prettier',
  ],
  settings: {
    react: {
      // Tells eslint-plugin-react to automatically detect the version of React to use.
      version: 'detect',
    },
    // Tells eslint how to resolve imports
    'import/resolver': {
      node: {
        paths: ['src'],
        extensions: ['.js', '.jsx', '.ts', '.tsx'],
      },
    },
  },
  rules: {
    // Add your own rules here to override ones from the extended configs.
  },
};

ESLint ignore file

Now we create an .eslintignore file. This is where we tell ESLint which directories and files to ignore. This is project dependent, but here's an example:

node_modules/
dist/
.prettierrc.js
.eslintrc.js
env.d.ts

Add a new script entry

In your package.json file, you can add a lint script entry to run ESLint from the command line.

  "scripts": {
    ...
    "lint": "eslint . --ext .ts,.tsx"
  },

Now run npm run lint to check for linting errors. If you don't see any, it might mean that there are none (lucky you), so make sure to purposely add one in order to test it out e.g declaring a variable without using it.

3. Configure Prettier

Now that we've taken care of ESLint, let's go ahead and create the prettierrc.js file. This is where we specify all of our Prettier formatting rules. Here's an example:

module.exports = {
  "trailingComma": "all",
  "tabWidth": 2,
  "semi": true,
  "singleQuote": true,
  "printWidth": 120,
  "bracketSpacing": true
}

Prettier ignore file

Similar to ESLint, we need to tell Prettier what files it should ignore. Again this will depend on your own project, but here's mine:

node_modules/
dist/
.prettierrc.js

IDE integration

In order to take full advantage of Prettier, you should be using it with an IDE to format your code after you save a file. If you're using VS Code, you can install the Prettier extension. You can then set the following settings:

Or if you have access to the settings.json file, you can simply add these:

{
  "prettier.configPath": ".prettierrc.js",
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

Now, whenever you make changes to a file and save it, you should notice that Prettier auto formats it for you if needed. Pretty nice right? 😀

Automation

If you'd like, you can go a bit further and automate the linting and formatting process a bit. I like to use Husky which allows you to run your linter, tests etc. on a git commit/push etc. You can also then use pretty-quick along with husky to automatically format your code whenever you git commit, just in case someone on your team hasn't set it up in their IDE.

Want to see more?

That's it for today! I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Migrating from Jest to Vitest

Cathal Mac Donnacha 🚀 — Wed, 25 May 2022 13:16:20 +0000

I recently migrated from create-react-app (CRA) to ViteJS, and as part of that, I switched my test runner from Jest to Vitest.

In this article, I go through all the steps I took as part of the migration, in the hope that it might help others who are going through the same process.

Why switch?

I had originally planned to keep using Jest during the migration of CRA to ViteJS, but I kept running into issues, mainly because Jest support for ES Modules is still experimental. There is a Vite plugin called vite-jest but it's still very much a work in progress.

Vitest is also pretty early in its development stages, but I felt that it was stable enough to give it a try, and I'm sure glad I did. It has many advantages but one thing I really like about it compared to other test runners is that it shares the same config file and plugins as Vite itself, so there's only one single pipeline to worry about.

Migration steps

Here are all of the steps I took to migrate from Jest to Vitest.

Note: These steps are unique to the way Jest was installed within CRA, so they may vary if you installed and configured Jest manually.

Let's get started!

1. Install dependencies

We need to install 3 dependencies:

Vitest: Our test runner.
jsdom: To mimic the browser while running tests.
c8: To generate our code coverage reports.

To install these dev dependencies, run the following command:

npm install --save-dev vitest jsdom c8

2. Update vite.config.ts

As I mentioned previously, the beauty of using Vitest is that it integrates seamlessly with Vite, so all we have to do is update the vite.config.ts file.

You'll also need to add a reference to the Vitest types using a triple slash command at the top of your config file.

/// <reference types="vitest" />
import { defineConfig } from 'vite'

export default defineConfig({
  test: {
    // ...
  },
})

You may have different requirements, but here's what mine ended up looking like:

/// <reference types="vitest" />
import { defineConfig } from 'vite'

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/setupTests.ts',
    coverage: {
      reporter: ['text', 'html'],
      exclude: [
        'node_modules/',
        'src/setupTests.ts',
      ],
    },
  },
});

Here's the full list of config options, but I'll briefly explain each one I used:

globals: Setting this to true allows you to reference the APIs globally (describe, expect, it, should etc.), just like Jest.
environment: This is where you choose what browser-like environment you want to use.
setupFiles: This is the path to the setup files which run before each test file. In CRA, this file (setupFiles.ts) is included by default, so I left it as is.
coverage: This is the configuration I use for the c8 reporter. I also specify the folders that I exclude from the report.

3. Convert tests

Vitest has been designed with a Jest compatible API (describe, expect, it, should etc.), so migrating tests was an absolute breeze. Unless you mock modules or methods, you probably won't need to do anything here.

I was making use of Jest method mocking, but all I had to was change jest.fn() to vi.fn(). You'll have to import vi in your test if you want to do the same: import { vi } from 'vitest';

4. Update package.json

Let's update the package.json scripts to reference vitest instead of react-scripts.

 "scripts": {
    ...
    "test": "vitest watch",
    "test:no-watch": "vitest run",
    "test:coverage": "vitest run --coverage"
  },

You'll notice I also added a new entry to run code coverage and provided a way to run tests without a watcher, this comes in handy when running tests in a CI/CD pipeline.

We can npm uninstall @types/jest since we won't need it anymore. I have kept @testing-library/jest-dom around though as it's required by React Testing Library.

Finally, I removed any "jest" configuration I had in this file:

  "jest": {
    "collectCoverageFrom": [
      "src/**/*.{js,ts,tsx}",
      "!/node_modules/",
    ]
  },

5. Update tsconfig.json

To get TypeScript working with the global APIs, add vitest/globals to the types field in your tsconfig.json file.

"types": ["vitest/globals", .....]

You may also run into an error like this:

../node_modules/@types/jest/index.d.ts:34:1 - error TS6200: Definitions of the following identifiers conflict with those in another file: test, describe, it, expect, beforeAll, afterAll, beforeEach,

At the time of writing this article, it still seems to be an open issue. However, a workaround I found is to add "skipLibCheck": true, to your tsconfig.json file.

6. Run tests

Hopefully the migration worked for you and all that's left to do now is to run npm test. 🎉

Final thoughts

Overall I'm extremely happy with Vitest, they've really made the migration so easy. I'm even more impressed with their docs given it's still pretty new, especially the number of examples they have. If you found this article helpful or have suggestions, please leave a comment below. 🙂

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Playwright E2E testing: Tips and best practices

Cathal Mac Donnacha 🚀 — Wed, 23 Mar 2022 13:07:28 +0000

I've been using Playwright for a couple of months now, and though I'm certainly no expert, I've learned some tips, tricks and best practices along the way. In this article, we go through some of them, with the aim of helping you write even better E2E tests.

1. Prioritize user-facing attributes

You should use user-facing attributes like text content, accessibility roles and label as much as possible. A user won't know what "id" or "class" means so why should we use them in our tests to find elements? Not only will your tests mimic how your users find elements, but they will also be more robust as user-facing attributes generally change less than ids, class names or other implementation details.

For example, use await page.locator('text=Login') instead of await page.locator('#login-button'). A real user will find a button by its text content, not its id, so your tests should too.

Remember, the more your tests resemble the way your software is used, the more confidence they can give you.

2. Use locators over selectors

Using locators will help prevent flakiness or unnoticed breakages when your web page changes. These breakages have the potential to go unnoticed when using standard selectors.

For example, use await page.locator('text=Login').click() instead of await page.click('text=Login').

The main reason locators help mitigate flakiness is down to its level of strictness. There are three possible outcomes when using locators:

Test works as expected.
Selector does not match anything and test breaks loudly.
Multiple elements match the selector (e.g. there is a second "Login" button added to the page somewhere), and the locator complains about this and the test breaks with a nice error message.

This means you don't have to be very thoughtful of selectors, and picking just text=Login is totally fine - Playwright will do all the heavy lifting to ensure correct and non-flaky testing.

3. Use Page Object Model (POM)

Page Object Model is a common pattern that can help avoid duplication, improve maintainability and simplify interactions between pages in multiple tests.

Writing tests using POM feels more natural as it conveys more intent and encourages behaviour over raw mechanics. Playwright have included this example in their docs to give you an idea on how to implement it.

In saying that, you don't always have to use POM either. Use it when it makes sense to abstract. I often start without POM and only create page object models when I feel that the tests will benefit from it.

Duplication is far cheaper than the wrong abstraction - Sandi Metz.

4. Use double quotes to find specific elements

If you are finding multiple elements with the same partial string, try using double quotes to enable case sensitivity. For example, await page.locator('text=Checkout') could return two elements as it finds a "Checkout" button and a "Check out this new shoe" heading. Use double quotes if you only want to return the button on its own e.g await page.locator('text="Checkout"'). See Playwright text selectors for more.

5. Avoid selectors tied to implementation

xpath and css can be tied to the DOM structure or implementation. For example:

await page.locator('#tsf > div:nth-child(2) > div.A8SBwf > div.RNNXgb > div > div.a4bIc > input').click();

Pretty gnarly right? These selectors can break when the DOM structure changes, so it's best to avoid relying on them.

Final thoughts

That's all the tips I have for you today. If you have any tips or best practices of your own, please share them in the comments below. 🙂

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Working around CORS in create-react-app

Cathal Mac Donnacha 🚀 — Tue, 01 Feb 2022 14:48:47 +0000

One problem we often face as frontend developers is dealing with CORS when making API requests.

What is CORS?

CORS (Cross-Origin Resource Sharing) is essentially a mechanism that allows a server to express what other domains can make requests to it. For example, my app could be hosted on http://domain-a.com, so only requests made from that same domain are allowed. If another app hosted on http://domain-b.com tried to make a request to http://domain-a.com, it would fail depending on the CORS policy.

Where does CRA fit in?

While using CRA (create-react-app), I've often run into a situation where I want to test my local changes against another team's API endpoint. I mean, there's only so much mocking you can rely on! By default, CRA runs locally on http://localhost:3000, so if I try to make an API request out to http://domain-a.com/users.json, CORS would block it. However, when developing locally, CRA lets us get around this by proxying all unknown requests to a specified domain. This can now help us make sure our frontend code lines up with the backend's responses.

What's the workaround?

All we need to do is add one new field in package.json. For example:

"proxy": "http://domain-a.com",

After you restart your CRA dev server, you should now be free to make requests to http://domain-a.com/users.json. This will of course only work locally and you should only make requests to a dev API endpoint, not production. That's it!

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Cypress vs Playwright: Which is best for E2E testing?

Cathal Mac Donnacha 🚀 — Thu, 16 Dec 2021 13:56:14 +0000

Cypress was our go-to end-to-end (E2E) testing tool, and we were pretty happy with it, up until recently that is. Lately, we've run into a couple of testing scenarios where Cypress support has been limited, notably around multiple domains/tabs and iFrames. This caused us to re-evaluate the available E2E tools and it ultimately came down to two options; keep Cypress or switch to Playwright.

In this article, I compare both tools in the format of an ADR, which should help us decide which tool to go with. Let the battle commence!

Cypress

https://www.cypress.io/

Good, because it's very easy to learn and get set up with basic tests.
Good, because it has a nice dashboard to view test reports, analytics and recordings.
Good, because it supports Chromium and Firefox.
Good, because it has a very slick Test Runner UI.
Good, because it's built specifically for end-to-end testing.
Good, because you can edit your test code in the browser and instantly see it run as you change the code.
Good, because it's mature and has good community support.
Bad, because it doesn't support multiple domains.
Bad, because authentication requires a lot more setup due to lack of multi-domain support.
Bad, because it doesn't support Webkit (Safari)
Bad, because you cannot run tests against multiple browsers at the same time.
Bad, because iFrame support is limited.
Bad, because there is no "hover" support.
Bad, because the chaining command syntax can quickly get out of hand for more complex tests.
Bad, because you have to pay a premium to get access to some dashboard features (e.g flake detection)
Bad, because to do parallelization well, it requires vendor-locked software.

Playwright

https://playwright.dev/

Good, because it supports Chromium, Firefox and Webkit (Safari).
Good, because it supports multiple domains and tabs.
Good, because it supports 5 language bindings (Javascript, Typescript, Java, Python, .NET)
Good, because it's fast.
Good, because you can run tests against multiple browsers at the same time.
Good, because it fully supports parallelization, even locally.
Good, because it supports parallel tests within a single test file.
Good, because it's Javascript first, so feels more natural.
Good, because it has "hover" support.
Good, because iFrames are natively supported.
Good, because it supports reuse of authentication state to speed up tests.
Good, because it lets you choose your test runner (e.g. Jest but the default one is advised)
Good, because signing in is simple, you just fill in the form.
Good, because it's completely free.
Good, because it has few dependencies.
Bad, because it's still quite new, so possibility of a smaller community.
Bad, because 3rd party tutorials are out of date due to changing API.
Bad, because it's a mix between an automation and testing framework.
Bad, because it has a steeper learning curve.
Bad, because it does not have a dedicated dashboard so would be harder to debug tests remotely.

Common features between both

Good documentation
API testing
Point & click test recording
Test debugging tools
Test retries
Automatic waiting
Video and screen capture
Mobile emulation
Regularly updated and well maintained
Run only a subset of tests
Network monitoring

Conclusion

In the end, we decided to go with Playwright, mainly because of its native support for multiple domains, tabs and iFrames. I will say that I found Cypress' debugging to be more developer-friendly and in general "slicker", but that wasn't enough to make us stay put.

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Why you should make your tests fail

Cathal Mac Donnacha 🚀 — Thu, 02 Dec 2021 13:58:36 +0000

Let's face it, most of us developers don't necessarily love writing tests. We sometimes end up rushing through them, and once we see that green tick next to a passing test, we're generally pretty happy to move on. However, an enemy is lurking amongst us.

False positive test

The enemy I'm talking about here is otherwise known as a false positive test. Let's take a look at what this beast looks like.

Here we have a select element with some countries as options:

<select>
  <option value="">Select a country</option>
  <option value="US">United States</option>
  <option value="IE">Ireland</option>
  <option value="AT">Austria</option>
</select>

Here's my test:

it('should allow user to change country', () => {
  render(<App />)
  userEvent.selectOptions(
    screen.getByRole('combobox'),
    screen.getByRole('option', { name: 'Ireland' } ),
  )
  expect(screen.getByRole('option', { name: 'Ireland' })).toBeInTheDocument();
})

The test passes, isn't that great? ✅ I'm afraid not. 😭 Let's see why after we intentionally make it fail.

Making your test fail

Here's a real example of a false positive test situation I ran into recently:

it('should allow user to change country', () => {
  render(<App />)
  userEvent.selectOptions(
    screen.getByRole('combobox'),
    screen.getByRole('option', { name: 'Ireland' } ),
  )

  // Changed expected country from "Ireland" to "Austria" - this should fail.
  expect(screen.getByRole('option', { name: 'Austria' })).toBeInTheDocument();
})

I was expecting the check for "Austria" to fail because it wasn't the selected country, and I was pretty surprised to see that it was still passing. Looks like we have just identified a false positive test.

Let us take a step back. The purpose of my test is to ensure that when changing a country, it is indeed the now selected option. However, after debugging for while I eventually realised that the test above only checks that the country "Ireland" exists, instead of checking if it's selected.

Here's how I eventually fixed it:

it('should allow user to change country', () => {
  render(<App />)
  userEvent.selectOptions(
    screen.getByRole('combobox'),
    screen.getByRole('option', { name: 'Ireland' } ),
  )

  // Now checking if the option is selected
  expect(screen.getByRole('option', { name: 'Ireland' }).selected).toBe(true);
})

Now, I am correctly checking that the option is selected and all is good. I wouldn't have found this unless I intentionally made my test fail, so I'm glad my persistence has paid off and I avoided a potential bug.

Final thoughts

I've been burnt enough times in the past by false positive tests that I have vouched to always intentionally make my tests fail before moving on to the next one. Since doing this, I've gotten a lot more confident in my tests knowing that they'll only pass in the correct circumstances.

That's about all I have to share with you today. Let me know in the comments if you found this article useful. 🙌

Want to follow along?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

6 tips every code review author should know

Cathal Mac Donnacha 🚀 — Mon, 08 Nov 2021 13:59:50 +0000

I've submitted my fair share of code reviews at this point of my frontend development career and I've picked up a couple of tips along the way, so I wanted to share some of them with you.

1. Keep it small 🤏

Try and keep your code reviews as small as possible. This is better for reviewers as it makes it easier for them to focus on one or two goals. It's also better for you as it means you can push your code to production more often, giving yourself a sense of achievement.

As a code reviewer, there's nothing worse than getting a huge code review that takes days to go through. You'll find a reviewer's attention to detail will drop off after 60 minutes of review time, meaning you won't get the best out of your reviews.

By keeping your reviews small, you're more likely to get faster feedback and approvals, meaning you can ship your code more often. Win. 🚀

In saying this, there are times where your code reviews simply can't be small. This may occur if you're making changes that affect multiple services or you're working with legacy code that can't be broken down as easily. This is fine too, these tips are just a guide to follow when you can.

As a frontend developer, I try to break down large stories into multiple smaller tasks, meaning I can submit smaller code reviews too. I often follow Martin Fowler's Keystone Interface method to achieve this.

2. Write a good description 👨‍💻

Include a brief description in your code review where you give a summary of the changes made. This is very important as it gives the reviewer the context required to put themselves in the user's shoes while they review your code.

3. Include screenshots or recordings 📹

If the changes you have made are visual then it's important to include screenshots, or even better...screen recordings. Similar to the previous tip, this gives the reviewer some more context into the changes you've made as they can link your code with what they see in your screenshots or recordings. As they say, "a picture paints a thousand words". I'm not sure if your screenshot will end up in any art galleries, but you can be sure they will benefit your reviewers. 😀

4. Give instructions on how to verify your changes 👨‍🏫

Depending on the code review, it's important to give your reviewers a way to play around with your changes for themselves. This is the number one best way to receive feedback, especially if the changes are visual. I've often found small issues during code reviews relating to how responsive a webpage is, which is something I wouldn't have spotted by looking at the code or screenshots.

On our team, we often use Heroku review apps which gives you a sandboxed version of your app. It gets deployed whenever we create a new code review. This has become a fundamental part of our code review process. However, most teams won't have this luxury so another good option is to ask the reviewer to checkout your branch and run it locally.

Here's an example of some instructions you could include in your code review:

Checkout branch: popup-toast-notification
Run app locally: npm start
Go to the "Profile" page.
Change your name.
Click "Update".
You should see a toast notification appear at the top of your screen.

5. Give reviewers enough time ⏱️

There is no point in requesting a large code review on the very last day of the sprint. It's important to give reviewers enough time so that they don't feel rushed or pressured into giving approvals. By giving reviewers the time they need, they can give you adequate feedback and it also gives you that extra bandwidth to make any requested changes.

6. Avoid scope creep ✋

As engineers, we always strive to develop the perfect solution. This can be good, but it can also lead to distractions in code reviews where reviewers will request extra features. How many times have you heard someone say "This is good, could you add this X feature to make it even better?". As the code review author, it's important to know when a request is outside the scope of the task you're working on. Getting feature request ideas is fantastic, but it's something you should discuss with your product manager and team members, and possibly create a new task for it. This could then be delivered as part of a separate code review.

Final thoughts 🤔

That's it. 😀 Hopefully this article can help you improve your code reviews, but remember that these are just tips to guide you and so it's important to figure out what works for you and your team.

If you found this article useful then please give it a like, and if you have some tips of your own, feel free to leave a comment. 🙌

Want more? 📢

I mainly write about real-world tech topics I face in my everyday life as a frontend developer. If this appeals to you, then feel free to follow me on Twitter for more: https://twitter.com/cmacdonnacha

Bye for now 👋

Tips for developers switching from Windows to Mac

Cathal Mac Donnacha 🚀 — Mon, 01 Nov 2021 13:07:27 +0000

I was a Windows fan all my life, both at home since I was 10 years old, and at work for 8 years of my frontend development career. However, when I moved jobs recently I was given a MacBook Pro, and so I had little choice but to dive headfirst into everything MacOS. It was a bit strange at first and it honestly took me a few days to get settled in with the Mac, but once I did, I really started to like it.

From the beginning, there were a couple of things I missed about Windows, and some alternative apps that I had to find. In this article, I go through some of the things that helped me, in the hope that I can help smoothen the ride for other developers starting out on their Windows to Mac journey.

Package manager 📦

I used to use Chocolatey as my package manager on Windows. I found it really useful to install and organise all of my various packages, and so I wanted to find the best alternative for Mac. Brew was the answer! I've been using it for the past year and haven't had any issues or missing features compared to Chocolatey.

Terminal 📺

ConEmu was my go-to terminal on Windows and so I was pretty bummed out when I realised that it wasn't supported on Mac. After asking some folks on my team, they suggested iTerm2 and I must admit it's equally fantastic.

One feature that is not included in iTerm2 though is the ability to display the currently active git branch at a glance. Worry not! oh-my-zsh to the rescue 🦸‍♂️ You can install it using this curl command and hey presto, you now see those nice pretty git branches in your terminal.

Similar to ConEmu, I use a feature in iTerm2 called "window arrangements" to automatically launch tabs whenever I open the terminal. I find this really handy, as it automatically navigates to the correct directory and opens my regular 3 git, serve and test tabs for me. This feature has saved me countless hours over the years!

Finder 🗄

Finder is the default file manager on the Mac and it's equivalent to Windows Explorer, with some differences. The biggest difference for me was the lack of a classic cut and paste. On Windows you could simply press ctrl + x and ctrl + v. However, to do this on Mac you have to select the file and then press cmd + c and cmd + option + v.

Hidden Files

To show hidden files in Finder just press command + shift + ..

If you want to show hidden files by default just open your terminal and run this command:

defaults write com.apple.finder AppleShowAllFiles YES; killall Finder;

Split screen 💻

I often use split screen to view both the browser and VS Code side by side. On Windows, this is quite simple to do using a feature called Snap Assist. You simply just drag a window to the edge of the screen and then select the other window you want to show beside it.

Again I was pretty disappointed to find out that you couldn't easily achieve this on the Mac. Not to worry though, it does have a feature called Split View, which is close enough for me. It's not as quick and easy but gets the job done.

Window management app

A reader suggested Rectangle for split screen window management and I must say, I'm impressed!

MS Paint 🎨

Oh man, how I loved this app. As a frontend developer, I was constantly taking screenshots, pasting them into Paint and then drawing arrows, boxes and text on top of them to include in JIRA tickets, emails etc. I even remember using it to create some icons back in the day. I couldn't believe the Mac didn't have a native paint app. However, I found two solutions that helped me dry my tears.

1. Shape detection in Preview

I may be easily amused, but this feature blew my mind when I first tried it. When you take a screenshot (command + shift + 3), a thumbnail will appear in the bottom right corner of the screen. Once you click on the thumbnail, the native Preview app on the Mac will open. From here you can draw a rough circle, square, or arrow and if it's recognised as a standard shape, it’s replaced by that shape. How cool is that?!

2. Sketchpad

One drawback to the native Preview app is that you can't simply copy and paste two images onto one canvas. Again, I do this a lot when creating "before and after" screenshots of tasks I'm working on. It's so much easier to convey this in one single side-by-side image instead of two separate ones.

Again MS Paint was great for this, so I had to find an alternative. I tried lots of Mac apps, browser extensions and web apps but struggled to find anything suitable, user friendly, and free, which had similar features to MS Paint. Finally, I found it! Sketchpad is a fantastic web app where you can quickly copy and paste images side by side, draw, add text, fill vectors and lots more.

Screenshots and video recording 📹

I touched on this earlier, but as a frontend developer, I take a lot of screenshots and recordings so that I can attach them to JIRA tickets, Slack messages, emails and so on. I think that this is an important part of any frontend developer's workflow, so I wanted to go through it in a bit more detail.

Basic screenshot

Using the command + shift + 3 shortcut, you can take a screenshot of the currently active screen. You should then see a thumbnail appear in the right bottom corner of your screen. Clicking on this will bring up the native Preview app, which (as mentioned earlier) you can use to draw on the image. It will save the image to your default screenshots folder on your Mac, which is useful if you want to refer back to it later.

Capture a portion of the screen

Using the command + shift + 4 shortcut, you can take a screenshot of a portion of the screen. This will save the image to your Mac. Out of all the screenshot options, I probably use this the most.

Capture a portion of the screen and copy to clipboard

Using the command + shift + control + 4 shortcut, you can take a screenshot of a portion of the screen. The difference between this and the previous shortcut is that it will only copy the image to your clipboard. It will not save the image to your Mac. This is useful if you want to quickly copy and paste screenshots into chat or an email body, but not take up space on your hard drive.

Screenshot a window

Using the command + shift + control + space shortcut, you can take a screenshot of a particular window.

Record the screen

Using the command + shift + 5 shortcut, you will see a toolbar appear which allows you to record the entire screen, or just a portion of it.

To stop recording, just press the same command + shift + 5 shortcut again and press the "stop" button. I use this very often in PRs, or when showing my team some early progress of a feature I'm working on.

You can even trim the beginning and end of the video using this button:

Noteworthy screenshot app

I thought it was worth calling out a great free tool which I've found very useful called Shottr. It hasn't fully replaced the native screenshot functionality for me, but it's mighty close.

Shortcuts ⌨️

First of all, the keyboard is subtly different compared to Windows. The command key is what you'll use for most shortcuts and commands, it's mostly similar to the ctrl key on Windows. In most cases, shortcuts that require the use of the alt key on windows will use the option key on Mac.

Once I got used to these differences I started to look up various shortcuts for applications I use every day. Below are only some of the shortcuts I use, but here is the full list if you need it.

Basics

Shortcut	Description
`command` + `x`	Cut
`command` + `c`	Copy
`command` + `v`	Paste
`command` + `w`	Close window
`command` + `z`	Undo
`command` + `spacebar`	Open spotlight to quickly find and open apps, documents, and other files.
`command` + `tab`	Switch apps
`command` + `n`	New finder window
`command` + `delete`	Delete file / folder
`command` + `shift` + `.`	Show hidden files in Finder
`control` + `down arrow`	Show all windows of the active app (i.e all Chrome windows)
`command` + `shift` + `3`	Take a screenshot of the currently active screen
`command` + `shift` + `4`	Take a screenshot a portion of the screen
`command` + `shift` + `4` + `space`	Take a sccreenshot of a window of your choosing
`command` + `shift` + `control` + `4`	Take a screenshot of a portion of the screen and copy it to the clipboard
`command` + `c` then `command` + `option` + `v`	Cut and paste files in finder
`enter`	Rename selected file or folder

Text editing

Shortcut	Description
`command` + `left arrow`	Go to beginning of line
`command` + `right arrow`	Go to end of line
`command` + `control` + `spacebar`	Show Emoji viewer 😃
`command` + `shift` + `v`	Paste without formatting
`option` + `backspace`	Delete word
`command` + `backspace`	Delete all text left of cursor

Chrome

Shortcut	Description
`command` + `option` + `i`	Open dev tools
`command` + `r`	Reload page
`command` + `f`	Search within the page
`command` + `shift` + `t`	Open last closed tab

Slack

Shortcut	Description
`command` + `shift` + `c`	Format higlighted text to code
`command` + `k`	Quick switcher
`command` + `shift` + `u`	Add link text (You can also paste a link directly onto highlighted text to achieve the same)

iTerm2

Shortcut	Description
`control` + `u`	Delete line
`control` + `y`	Restore previous deleted line. This is handy if you need to run another command then come back to the previous one.
`command` + `t`	New tab

VS Code

For VS Code, I have customised a lot of the shortcuts myself as I personally think they make more sense and are easier to remember, so I've included them below. However, here's a list of the default out-of-the-box shortcuts.

Shortcut	Description
`command` + `click`	Go to definition
`command` + `p`	Quick search
`option` + `left arrow`	Go back
`option` + `right arrow`	Go forward
`command` + `d`	Copy lines down i.e duplicate line of code
`control` + `e`	Add cursor to next matching text
`command` + `/`	Comment out line
`command` + `backspace`	Delete line
`command` + `\`	Open file in side pane

Final thoughts 🤔

You might wonder if I miss Windows for frontend development, well my answer is "kinda but not really". Yes, Windows does some things better, but Mac has some of its own advantages. I think Mac is a happy medium for software developers who work on a lot of backend code as it's based on Unix, runs most Linux applications but is still user friendly. However, as a frontend developer, all I really need is VS Code and a browser to do my work, both of which work exactly the same regardless of which OS I'm using.

Hopefully, this article can make the Windows to Mac switch that small bit easier for you. If you found this article useful, or have some tips of your own, feel free to leave a comment 🙌

Useful resources 📖

I found these resources useful when learning the basics during my Windows to Mac switcharoo:

Want more? 📢

Bye for now 👋

How to test a select element with React Testing Library

Cathal Mac Donnacha 🚀 — Sun, 10 Oct 2021 15:52:27 +0000

I recently needed to add tests for a <select> element I was developing, and I couldn't find a lot of resources on how to do this with React Testing Library, so I'll share the approach I went with.

The `<select>` element

First of all, let's create a <select> element with some options. Here I have an array with 3 countries:

const countries = [ 
  { name: "Austria", isoCode: "AT" },
  { name: "United States", isoCode: "US" }, 
  { name: "Ireland", isoCode: "IE" }, 
]

Here's the <select> element itself, it has:

A default placeholder <option> asking the user to "Select a country".
A .map method so we can iterate over the countries array and add an <option> element for each one.

<select>
  <option>Select a country</option>
  {countries.map(country => (
    <option key={country.isoCode} value={country.isoCode}>
      {country.name}
    </option>
  ))}
</select>

Tests

Now that we have a basic <select> element which displays some countries, let's go ahead and write some tests! Yay...my favourite part 😀

The beauty of React Testing Library is that it makes you focus more on writing tests the way an actual user would interact with your application, so that's the approach I've taken with the tests below. Of course you may have your own unique scenarios, if you do, just think "How would a real user interact with my select element?".

Default selection

it('should correctly set default option', () => {
  render(<App />)
  expect(screen.getByRole('option', { name: 'Select a country' }).selected).toBe(true)
})

Correct number of options

it('should display the correct number of options', () => {
  render(<App />)
  expect(screen.getAllByRole('option').length).toBe(4)
})

Change selected option

it('should allow user to change country', () => {
  render(<App />)
  userEvent.selectOptions(
    // Find the select element, like a real user would.
    screen.getByRole('combobox'),
    // Find and select the Ireland option, like a real user would.
    screen.getByRole('option', { name: 'Ireland' }),
  )
  expect(screen.getByRole('option', { name: 'Ireland' }).selected).toBe(true)
})

Gotchas

Initially when I started to look into writing tests for these scenarios I went with the following approach:

it('should allow user to change country', () => {
  render(<App />)
  userEvent.selectOptions(
    screen.getByRole('combobox'),
    screen.getByRole('option', { name: 'Ireland' } ),
  )
  expect(screen.getByRole('option', { name: 'Ireland' })).toBeInTheDocument();
})

Notice the difference? I was only checking that the "Ireland" <option> existed instead of checking if it was actually selected. Yet my test was still passing 🤔

expect(screen.getByRole('option', { name: 'Ireland' })).toBeInTheDocument();

Let's take a look at why this happened. When the component is loaded, the following is rendered:

<select>
  <option value="">Select a country</option>
  <option value="US">United States</option>
  <option value="IE">Ireland</option>
  <option value="AT">Austria</option>
</select>

So from JSDOM's point of view, the "Ireland" <option> always exists within the document, causing my test to pass!

Whereas the correct approach is to use .selected:

expect(screen.getByRole('option', { name: 'Ireland' }).selected).toBe(true);

Gotchas like this can be just as dangerous as not writing the test in the first place as it gives you false confidence about your tests. This is why I always recommend intentionally causing your tests to fail, like this:

expect(screen.getByRole('option', { name: 'Austria' }).selected).toBe(true);

❌ Test failed: should allow user to change country
Expected: true
Received: false

This way you can be confident that it only passes for the intended scenario 🥳

Full code example

Here's a codesandox which includes the basic examples shown above.

Final thoughts

So there it is, you should now be able to write some basic tests for your <select> elements using React Testing Library. Of course, I'm not an expert on this topic, I'm simply sharing what I learned in the hope that I can pass on some knowledge.

If you found this article useful, please give it a like and feel free to leave any feedback in the comments 🙏

Want to see more?

I mainly write about real tech topics I face in my everyday life as a Frontend Developer. If this appeals to you then feel free to follow me on Twitter: https://twitter.com/cmacdonnacha

Bye for now 👋

Forem: Cathal Mac Donnacha 🚀

Route-based code splitting with React

Why Route-based Code Splitting?

What do we need?

Dynamic import

React.lazy()

Suspense

Show me the code

Code splitting using bundlers

Final thoughts

Want to see more?

Mocking Error, Empty and Loading states with MSW

Getting started

Mocking errors

Suppressing intentional errors

Mocking empty states

Mocking loading states

Alternative mocking patterns

Utility functions

isQueryParamPresent()

customResponse()

Page vs request URL query parameters

Live code example

Upcoming beta

Final thoughts

Want to see more?

Migrating from Create React App (CRA) to Vite

Why switch?

Migration steps

1. Install dependencies

2. Create Vite config file

3. Move index.html

4. Update index.html

5. Update tsconfig.json

6. Create vite-env.d.ts file

7. Remove react-scripts

8. Update scripts in package.json

9. Start it up!

Optional steps

ESLint & Prettier

Tests

Environmental variables

Change build output folder

Automatically open the app on server start

Change port number

Benchmarks

Troubleshooting

Final thoughts

Want to see more?

Setting up ESLint & Prettier in ViteJS

1. Install dependencies

2. Configure ESLint

ESLint config file

ESLint ignore file

Add a new script entry

3. Configure Prettier

Prettier ignore file

IDE integration

Automation

Want to see more?

Migrating from Jest to Vitest

Why switch?

Migration steps

1. Install dependencies

2. Update vite.config.ts

3. Convert tests

4. Update package.json

5. Update tsconfig.json

6. Run tests

Final thoughts

Want to see more?

Playwright E2E testing: Tips and best practices

1. Prioritize user-facing attributes

2. Use locators over selectors

3. Use Page Object Model (POM)

4. Use double quotes to find specific elements

5. Avoid selectors tied to implementation

Final thoughts

Want to see more?

Working around CORS in create-react-app

3. Move `index.html`

4. Update `index.html`

5. Update `tsconfig.json`

6. Create `vite-env.d.ts` file

7. Remove `react-scripts`

8. Update scripts in `package.json`

The `<select>` element