There are two main sections:

• Improving slow tests

• Preventing flaky tests

So let’s dive in!

Improving slow tests

While researching and investigating our vast test suite, I noticed a few issues that were making tests run slowly. Here’s how we fixed them:

1. Render only what's necessary

Rendering large React components/pages was the most common reason for our tests to run slowly. Therefore, it's important to only render what is truly necessary when running each test.

If you're testing something quite isolated like max characters validation on an input field, you can just render a form (or even the input field itself) instead of the entire page. On the other hand, if you're asserting that an item is added to a table after filling out a form, rendering the parent component might make more sense.

Instead of rendering large tables or data grids in every test (e.g 50 rows), consider limiting the rows to just a handful.

2. Consider other React Testing Library queries:

It's important that we use the byRole query by default to help improve our accessibility testing. However, the byRole query is known to be slow in some scenarios. As per the guidance given by the Testing Library team, if necessary, it may be worth considering alternatives like byLabelText or byText if you start to face performance issues.

3. Consider using hidden: true to skip visibility checks

As mentioned previously, it's best to mimic real user experiences as much as possible. However, if needed, getByRole performance can be improved by setting the hidden option to true which avoids expensive visibility checks. Note that since it skips visibility checks, it will return all elements, even those that are not visible to the user.

getByRole('button', { name: 'Submit', hidden: true });

4. Use MSW (Mock Service Worker) to mock endpoints

Prevent real API calls during testing to eliminate network delays and improve speed.

For more information on how to mock endpoints in the frontend, see Mock service worker (MSW).

5. Avoid userEvent.hover where possible

Hover actions can slow down tests. If necessary, consider using userEvent.hover(button, { pointerEventsCheck: PointerEventsCheckLevel.Never }) as it skips multiple pointer event checks.

Using { pointerEventsCheck: PointerEventsCheckLevel.Never } also comes in useful when you want to hover over a disabled element to ensure a tooltip is displayed. Without setting this option, the test will fail with an error specifying that the element is disabled and we cannot interact with it.

Again, only consider this when you actually face performance issues. It’s always best to simulate real user interactions by default.

6. Optimize component source code

Optimize the source code of the components being rendered. If it’s slow or re-renders often within the browser, it’ll be even slower when running tests.

Complex tests are often a symptom of complex code

Given this 👆, it’s worth taking the time to refactor and simplify the code where possible.

7. Combine assertions

This may seem to be a bit of a contradiction, but sometimes it’s faster to write longer tests rather than multiple smaller ones.

Though we can run into timeouts when we have longer running tests, in most cases you can write fewer, longer tests which actually result in faster overall test suite runs. i.e one single test which takes 2 seconds vs 2 separate tests which take 1.5 seconds each due to setup time.

// BEFORE
it('disables the purchase button while loading the page', async () => {
  const purchaseButton = await screen.findByRole('button', { name: 'Purchase'});
  expect(purchaseButton).toBeDisabled();
});

it('allows the user to purchase stuff', async () => {
  // Fill in some required form fields...
  ...

  expect(purchaseButton).toBeEnabled();

  await userEvent.click(purchaseButton);
  expect(await screen.findByText('Purchased!').toBeInTheDocument();
});

// AFTER
// We can move the assertion from the first test into the second, which shortens test suite time and actually improves readability.
it('allows the user to purchase stuff', async () => {
  const purchaseButton = await screen.findByRole('button', { name: 'Purchase'});
  expect(purchaseButton).toBeDisabled();

  // Fill in some required fields...
  ...

  expect(purchaseButton).toBeEnabled();

  await userEvent.click(purchaseButton);
  expect(await screen.findByText('Purchased!').toBeInTheDocument();
});

8. Avoid using delay in userEvent

This has significant impacts on the performance of tests:

userEvent.setup({ delay: 1000 });

9. Avoid manually reading/writing to the DOM

This can be quite slow in general, especially in JSDOM. React is optimized to do this in the most performant way possible. Therefore, it's best to avoid doing this ourselves.

10. Avoid using regex to find elements

We found using regex instead of strings where unnecessary can add a minor performance overhead.

// ❌ Unnecessary use of regex and has a minor performance impact.
getByRole(‘button’, { name: /save/i })

// ✅ More performant and also prevents UX bugs.
getByRole(‘button’, { name: ‘Save’ })

11. Consider .focus() and .paste() instead of userEvent.type

When simulating user typing in tests, userEvent.type can be slow as it carefully simulates each keypress event. For improved performance in cases where you don't need to test specific keyboard interaction behaviors, you can use .focus() and .paste() methods instead.

// ❌ Can be slow for longer input text
const descriptionInput = screen.getByLabelText('Description');

await userEvent.type(
  screen.getByLabelText('Description'),
  'This is a very long description text that would trigger multiple events'
);

// ✅ Faster alternative when you don't need to test keyboard behavior
const descriptionInput = screen.getByLabelText('Description');

// Focus on the input first
descriptionInput.focus();

// Paste the entire value directly
await userEvent.paste(
  descriptionInput,
  'This is a very long description text that would trigger multiple events'
);

12. Use fake timers for components with timeouts or debounce

When testing components that rely on timeouts or debounce, you should use Jest's fake timers to skip the actual waiting time.

it('searches and finds a user', async () => {
  const user = userEvent.setup({ advanceTimers: jest.advanceTimersByTime });

  jest.useFakeTimers();

  render(<UsersTable />);
  const searchInput = await screen.findByRole('textbox', { name: 'Search users' });

  await user.type(searchInput, 'Jimmy');
  expect(await screen.findByText('Jimmy Mc Nulty')).toBeInTheDocument();

  // Flush any pending timers and switch to real timers to avoid unexpected behavior in subsequent tests.
  jest.runOnlyPendingTimers();
  jest.useRealTimers();
});

For more information on how to use fake timers, see:

• Jest's documentation on fake timers

• Testing Library's documentation on fake timers

• Testing Library's documentation on using advanceTimers with userEvent

Preventing flaky tests

What even is a flaky test? It’s a test that sometimes fails, but if you retry it enough times, it passes, eventually.

Outside of speeding up slow tests, here are a couple of other things we can do to increase the reliability of our tests:

1. Wait for an element to be visible before asserting or performing an action on it

This happens more often when testing UIs which rely on async data. Therefore, it's important to use findBy when working with elements that may appear asynchronously.

// ❌ This test can randomly fail as we don't wait for the element to be visible before asserting.
it('adds a user to the table', async () => {
  await userEvent.click(screen.getByRole('button', { name: 'Add user' }));
  expect(screen.getByText('User added!')).toBeInTheDocument();
});

// ✅ This test passes as we use findBy, which waits for the element first.
it('adds a user to the table', async () => {
  await userEvent.click(await screen.findByRole('button', { name: 'Add user' }));
  expect(screen.getByText('User added!')).toBeInTheDocument();

  // We can use getBy from here on, until another async action occurs.
  expect(screen.getByText('Jimmy Mc Nulty')).toBeInTheDocument();
  expect(screen.getByText('Detective')).toBeInTheDocument();

  // Here's another async action
  await userEvent.click(screen.getByRole('button', { name: 'Update user' }));

  // Need to use findBy here again after performing an async action above.
  expect(await screen.findByText('User updated!')).toBeInTheDocument();
});

2. Avoid asserting loading states on initial load

We often show skeleton loading states while waiting for async data to load. This results in a nice experience as the user knows that something is happening in the background. However, since we use MSW to mock data in our tests, fetching often completes so quickly that the query can’t find the “loading” element by the time the assertion takes place.

Instead, it’s best to find an element you know will be present when the page has completed all required fetching and is fully loaded. This gives you the same result, but is more robust as you are no longer dealing with random timings or render cycles.

// ❌ This assertion can randomly timeout and fail because the loading element never appears in the first place. The fetch completed so quickly!
expect(await screen.findByText('Loading...')).toBeInTheDocument();

// ✅ Instead, find an element you know will only appear when the UI is fully loaded.
expect(
  await screen.findByRole('button', { name: 'Purchase the thing' })
)).toBeInTheDocument();

But I want to test loading states…

If you are solely testing a loading component and are using MSW, you can make use of delay (or page url query params) to simulate a delay in the response, which will allow you to test the loading state in isolation.

it('shows a loading state', async () => {
  server.use(
    http.get('/users', async () => {
      await delay('infinite')
    })
  )

  await screen.findByText('Loading...');
})

3. Disable React Query retries

By default, in an error scenario, React Query will retry three times. This isn’t something you want to happen when running tests that intentionally check for error scenarios. Therefore, it’s best to turn off retries completely when running tests. The easiest way to do this is to create a custom wrapper which you can then reuse across all tests.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      // ✅ turns retries off
      retry: false,
    },
  },
})

const wrapper = ({ children }) => (
  <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
);

See Turn off retries for more information.

4. Reset MSW handlers

When using MSW handlers directly in your tests, it's important to reset the handlers after each test to avoid side effects in subsequent tests. This can be done by calling server.resetHandlers() within the afterEach block.

afterEach(() => {
  server.resetHandlers();
});

it('shows the list of users', async () => {
  server.use(
    http.get('/users', () => {
      return HttpResponse.json({ data: users });
    })
  );

  render(<SomeComponent />);

  // Your test logic...
});

Another option is to add it to setupTests.ts which will run it for each test across your project.

5. Use advanceTimers instead of delay:null when using fake timers

As mentioned in the Testing Library documentation, using delay: null can lead to unexpected behavior in tests. Instead, use advanceTimers to control the timing of your tests more predictably.

6. Remove dead code and tests

It's important to continuously remove code and accompanying tests that are no longer customer facing. Otherwise, they unnecessarily take up valuable CI/CD time and resources.

7. Avoid testing implementation details

If we already have UI based tests to cover features, we likely don’t need to test its implementation details as well (e.g expect(function).toHaveBeenCalled()), which are generally less valuable and often require changes any time you refactor your code.

Measuring and identifying slow tests

We use jest-slow-test-highlighter to highlight slow tests. This runs automatically as part of each test run and will highlight any individual test that takes longer than a 5 seconds to run. The times will vary depending on the device it's being run on (your fast laptop vs a slower CI machine).

Another simple alternative is to use console.time, which is useful to determine exactly which line is causing bottlenecks in your test.

it('should perform some action', () => {
  console.time('test-duration');

  // Your test logic here

  // Logs the time spent on this test
  console.timeEnd('test-duration');
});

Other considerations

Here's a list of other things we considered, but they either didn't seem to make much difference, or we haven't gotten around to trying out yet:

• Switching from Jest to Vitest.

• Switch from babel-jest to swc/jest transformer.

• Disable type checking in Jest by setting isolatedModules to true in jest.config.ts.

• Switch from JSDOM to happy-dom.

• Try different variations of Jest's --maxWorkers flag.

Final thoughts

After applying these fixes across our test suite, we saw a noticeable boost in speed and reliability, resulting in far fewer broken CI builds. Hopefully you can apply some of these same techniques to speed up your own tests and make them more reliable.

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 engineer. If this appeals to you then feel free to follow me on BlueSky. 🦋

Bye for now. 👋

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:

• Dynamic import

• React.lazy()

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 BlueSky. 🦋

Bye for now. 👋

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.

hasQueryParam()

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 hasQueryParam(
  queryName: string,
  queryValue: string = 'true'
) {
  const searchParams = new URLSearchParams(window.location.search);
  return searchParams.get(queryName) === queryValue;
}

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

export const handlers = [
  rest.get(`/your/api/endpoint`, (req, res, ctx) => {
    if (hasQueryParam('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 (hasQueryParam('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 (hasQueryParam('loading')) {
    return response(
       context.delay('infinite'), 
       context.json({})
    );
  }

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

  if (hasQueryParam('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 BlueSky. 🦋

Bye for now. 👋

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. You can also use vite-plugin-checker if you prefer having type errors directly reported in the browser.

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:

• Vite

• @vitejs/plugin-react

• vite-tsconfig-paths

• vite-plugin-svgr

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 to import SVGs as React components. For example:

import Logo from './logo.svg?react'.

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 svgr from 'vite-plugin-svgr';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    react(), 
    viteTsconfigPaths(),
    svgr({
      include: '**/*.svg?react',
    }),
  ],
});

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-jsx"
  },
  "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:

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 this 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 specifically 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 BlueSky. 🦋

Bye for now 👋

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:

• prettier-eslint

• eslint-plugin-prettier

• eslint-config-prettier

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 by adding a .prettierignore file. 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 BlueSky. 🦋

Bye for now 👋

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 BlueSky. 🦋

Bye for now 👋

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:

1. Test works as expected.

2. Selector does not match anything and test breaks loudly.

3. 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 BlueSky. 🦋

Bye for now 👋

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 BlueSky. 🦋

Bye for now 👋

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 BlueSky. 🦋

Bye for now 👋

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 BlueSky. 🦋

Bye for now 👋

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:

1. Checkout branch: popup-toast-notification

2. Run app locally: npm start

3. Go to the "Profile" page.

4. Change your name.

5. Click "Update".

6. 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 BlueSky. 🦋

Bye for now 👋

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

Text editing

Chrome

Slack

iTerm2

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.

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:

• Mac tips for Windows switchers

• A list of Windows and Mac terms to help you find what you’re looking for.

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 BlueSky. 🦋

Bye for now 👋