Forem: Profy.dev

REST APIs - How To Connect Your React App Like The Pros (Incl Detailed Example)

Johannes Kettmann — Fri, 07 Oct 2022 12:23:10 +0000

Consuming REST APIs with React isn’t very difficult. It only takes a useEffect plus a few lines of code and you have the data in your frontend.

At least it seems like that at first.

But once you start adding features to your data fetching logic you quickly end up with a big mess of entangled spaghetti code.

Luckily there are a few libraries to our rescue (among them react-query). These not only make it really easy to fetch data but also deliver valuable and commonly used features right out of the box.

On this page, we’ll use an example project to see how quickly a “simple” approach to data fetching using useEffect can get out of hand. In contrast, we’ll see how easy it is to build advanced features using react-query by building a snappy paginated list component.

The Project
1. React Frontend
2. REST API
The “Simple” Approach With useEffect
1. The Code
2. The Problems
The Effective Approach With react-query
1. The Advantages
2. Setup
3. A Simple Implementation
4. Advanced Features For Free
5. Custom Hook As Best Practice
6. Usage With TypeScript
Advanced Example: A Paginated List Component With Great UX
1. Simple Pagination
2. Prefetching The Next Page
3. Reducing The Number Of Requests By Adjusting The Stale Time
Summary

The Project

Nobody wants to read through the setup of a new React app, I assume. So I prepared a realistic project for this article that shows a slightly more advanced use case for data fetching.

It’s an error-tracking tool similar to Sentry that I created for the React Job Simulator. It includes a React / Next.js frontend and a REST API which we will get our data from.

React Frontend

The goal is to fetch data and render it in our frontend like this:

You can see that this list has several pages (note the “Previous” and “Next” buttons at the bottom). This is very common in real-world projects.

But currently, we only see a single issue that is hard-coded in our frontend code.

The code responsible for rendering the list looks like the following at the moment. The goal is to replace the hard-coded data with data fetched from the API.

export function IssueList() {
  // hard-coded issues data
  const items = [
    {
      id: "mock-id",
      projectId: "6d5fff43-d691-445d-a41a-7d0c639080e6",
      name: "Mock Error",
      message: "This is hard-coded data that doesn't come from an API",
      stack: "Some mock stack trace",
      level: "error",
      numEvents: 105,
      numUsers: 56,
    } as Issue,
  ];

  // hard-coded meta data used for pagination
  const meta = {
      hasNextPage: true,
    currentPage: 1,
    totalPages: 7,
  }

  // state variable used for pagination
    const [page, setPage] = useState(1);

  return (
    <Container>
      <Table>
        <thead>
          <HeaderRow>
            <HeaderCell>Issue</HeaderCell>
            <HeaderCell>Level</HeaderCell>
            <HeaderCell>Events</HeaderCell>
            <HeaderCell>Users</HeaderCell>
          </HeaderRow>
        </thead>
        <tbody>
          {(items || []).map((issue) => (
            <IssueRow
              key={issue.id}
              issue={issue}
            />
          ))}
        </tbody>
      </Table>
      <PaginationContainer>
        <div>
          <PaginationButton
            onClick={() => setPage(page - 1)}
            disabled={page === 1}
          >
            Previous
          </PaginationButton>
          <PaginationButton
            onClick={() => setPage(page + 1)}
            disabled={!meta.hasNextPage}
          >
            Next
          </PaginationButton>
        </div>
        <PageInfo>
          Page <PageNumber>{meta.currentPage}</PageNumber> of{" "}
          <PageNumber>{meta.totalPages}</PageNumber>
        </PageInfo>
      </PaginationContainer>
    </Container>
  );
}

REST API

To get our data we’ll use the REST endpoint prolog-api.profy.dev/issue (click the link to see the JSON response). You can find more details about this REST API in its Swagger API documentation.

This is the response for the first page.

{
  "items": [
    {
      "id": "c9613c41-32f0-435e-aef2-b17ce758431b",
      "projectId": "6d5fff43-d691-445d-a41a-7d0c639080e6",
      "name": "TypeError",
      "message": "Cannot read properties of undefined (reading 'length')",
      "stack": "Cannot read properties of undefined (reading 'length')\n    at eval (webpack-internal:///./pages/index.tsx:37:7)\n    at invokePassiveEffectCreate (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:23482:20)\n    at HTMLUnknownElement.callCallback (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:3945:14)\n    at HTMLUnknownElement.sentryWrapped (webpack-internal:///./node_modules/@sentry/browser/esm/helpers.js:81:23)\n    at Object.invokeGuardedCallbackDev (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:3994:16)\n    at invokeGuardedCallback (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:4056:31)\n    at flushPassiveEffectsImpl (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:23569:9)\n    at unstable_runWithPriority (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:468:12)\n    at runWithPriority$1 (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:11276:10)\n    at flushPassiveEffects (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:23442:14)\n    at eval (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:23319:11)\n    at workLoop (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:417:34)\n    at flushWork (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:390:14)\n    at MessagePort.performWorkUntilDeadline (webpack-internal:///./node_modules/scheduler/cjs/scheduler.development.js:157:27)",
      "level": "error",
      "status": "resolved",
      "numEvents": 105,
      "numUsers": 56
    },
    ....
  ],
  "meta": {
    "currentPage": 1,
    "limit": 10,
    "totalItems": 98,
    "totalPages": 10,
    "hasPreviousPage": false,
    "hasNextPage": true
  }
}

The issue endpoint is a simple GET endpoint. But (as common in production APIs) this endpoint is paginated. That means that we don’t get all issues in a single request but only 10 at once (aka 10 per page). To get the next “page” of issues we simply append a query parameter like prolog-api.profy.dev/issue?page=2.

The endpoint also returns a meta object that contains information related to the pagination like the current page or the number of total pages.

The “Simple” Approach With useEffect

Let’s start with a “simple” approach that many beginner tutorials teach. We’ll see that it’s in fact very simple to get the data and render it in the UI. But as soon as we go into the nitty-gritty details things start to get complex.

The Code

Inside our component, we want to fetch the data during the initial render. With the useEffect hook this is simple:

import axios from "axios";

export function IssueList() {
  useEffect(() => {
    axios
      .get("https://prolog-api.profy.dev/issue")
      .then((response) => console.log(response));
  // empty dependency array means this runs only once (at least in production)
  }, []);

    ...
}

Note: We use axios here instead of the native fetch API since it is simpler to use and has some additional features.

When we refresh the app we now see the data logged in the console of our browser:

Next, we have to save the data in a state variable to render it in the UI.

export function IssueList() {
  const [data, setData] = useState();
  useEffect(() => {
    axios
      .get("https://prolog-api.profy.dev/issue")
      .then((response) => setItems(response.data));
  }, []);

  const { items, meta } = data || {};

  ...
}

And voila, we see the data in our app.

Easy enough, isn’t it?

The Problems

Yes, just fetching data like that is easy. But in a production application, we can’t just leave it there. What if we wanted to handle loading and error state?

export function IssueList() {
  const [data, setData] = useState();
  const [error, setError] = useState();
  const [isLoading, setLoading] = useState(false);
  useEffect(() => {
    setLoading(true);
    axios
      .get(`https://prolog-api.profy.dev/issue?page=${page}`)
      .then((response) => setItems(response.data.items))
      .catch((error) => setError(error))
      .finally(() => setLoading(false));
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }
  if (error) {
    return <div>An error occured: {error.message}</div>;
  }

  ...
}

What if we wanted to add a route parameter for pagination and cancel previous requests when the page changes?

export function IssueList() {
  const [page, setPage] = useState(1);
  const [data, setData] = useState();
  const [error, setError] = useState();
  const [isLoading, setLoading] = useState(false);

  useEffect(() => {
    setLoading(true);
    const abortController = new AbortController();
    axios
      .get(`https://prolog-api.profy.dev/issue?page=${page}`, {
        signal: abortController.signal,
      })
      .then((response) => setItems(response.data.items))
      .catch((error) => {
        // this is easily missed
        if (error.message !== "canceled") {
          setError(error);
        }
      })
      .finally(() => setLoading(false));

    return () => abortController.abort();
  }, [page]);

  if (isLoading) {
    return <div>Loading...</div>;
  }
  if (error) {
    return <div>An error occured: {error.message}</div>;
  }

  ...

What if we wanted to add other features that are often a requirement in real-world applications? Like

- retry requests when an error occurs
- pre-fetch data for the next page to improve UX
- refresh stale data after a while
- cache response data.

You get where this is going. The initially simple-looking code can quickly become a nightmare of entangled spaghetti full of bugs. Believe me, in a previous job a few years ago we went down this road… and it wasn’t pretty.

The Effective Approach With react-query

Luckily since a few years, we have libraries that abstract a lot of common use cases of data fetching. Popular examples are react-query, Redux Toolkit Query, or Apollo. react-query is one of the most widespread and versatile ones so we use it for this tutorial.

The Advantages

To get an overview of all the advantages it is a good idea to have a look at the react-query documentation. But I think this screenshot says it all.

Setup

To use react-query we need to wrap our app component with a QueryClientProvider. This is common practice that you probably know from other libraries as well.

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { ReactQueryDevtools } from "@tanstack/react-query-devtools";

const queryClient = new QueryClient();

export default function MyApp({ Component, pageProps }) {
  return (
    <QueryClientProvider client={queryClient}>
      <Component {...pageProps} />
      <ReactQueryDevtools initialIsOpen={false} />
    </QueryClientProvider>
  );
}

Additionally, we added the dev tools that come with react-query. We will talk about this further down the page.

A Simple Implementation

import axios from "axios";
import { useQuery } from "@tanstack/react-query";

export function IssueList() {
    const { data, isLoading, isError, error } = useQuery(["issues"], () =>
    axios.get("https://prolog-api.profy.dev/issue")
  );

  if (isLoading) {
    return <div>Loading...</div>;
  }
  if (isError) {
    return <div>An error occured: {error.message}</div>;
  }

    // data is here the response object returned by axios
  const { items, meta } = data.data;

  ...

These simple three lines of code give us already a loading and error state.

The first parameter ["issues"] that we pass to useQuery is used as a unique identifier for the data stored in the cache. The second parameter is the callback that connects to the API (the same axios call that we used in the useEffect). Optionally we can pass a third parameter with config options.

You can see that useQuery doesn’t actually fetch the data itself but is more like a wrapper around the data-fetching callback that adds additional functionality.

Advanced Features For Free

We saw at first glance that the loading and error states are supported out of the box. But under the hood, we also get a few really handy advanced features for free. Here are a few examples:

1. A request cache that automatically updates in the background

In this video, you can see that a request is sent on the initial page load (the loading screen is shown). But when we navigate to another page and back we don’t see the loading screen anymore. The data is immediately there because it was cached.

This isn’t all though. In the network tab at the bottom, you can see that a request is sent in the background. The cache is automatically updated with the newest server data.

2. Automatic updates of stale data

The cache is not only updated when we navigate back and forth inside the application. When the user switches to another tab and comes back to our app the data is by default updated in the background as well.

3. Dev tools

You may have seen the “flower” icon at the bottom left of the page? That’s the button to open the dedicated react-query dev tools. You can see exactly what kind of requests have been sent, what’s in the cache, and the data plus additional information for each request.

Very handy for debugging.

Custom Hook As Best Practice

Since data fetching logic is often shared between multiple components it’s best practice to extract custom hooks for each endpoint.

export function useIssues() {
  const { data } = useQuery(["issues"], () =>
    axios.get(`https://prolog-api.profy.dev/issue`)
  );
  return data;
}

Now we can use this hook in our component.

export function IssueList() {
  const [page, setPage] = useState(1);

  const issuesPage = useIssues();
  if (issuesPage.isLoading) {
    return <div>Loading...</div>;
  }
  if (issuesPage.isError) {
    return <div>An error occured: {issuesPage.error.message}</div>;
  }

  const { items, meta } = issuesPage.data || {};

  ...
}

Note that we have separated the fetching logic from the component now. In the previous simple example, the component used the response object from axios directly. Now we can easily encapsulate this in our custom hook. This can be beneficial, for example, if we want to replace axios with something else at some point.

To further improve our custom hook it’s common to extract the data fetching callback into its own function.

export async function getIssues() {
  const { data } = await axios.get("https://prolog-api.profy.dev/issue");
  return data;
}

export function useIssues() {
  return useQuery(["issues"], () => getIssues());
}

Now axios is further isolated and the getIssues function is responsible for handling the response data. Additionally, we can reuse the getIssues function in other parts of our app (e.g. the server for server-side rendering).

Usage With TypeScript

For type safety and improved developer experience, it’s easy to use TypeScript with react-query. Simply pass the type of the expected response data plus an error type to the useQuery generic.

import { useQuery, useQueryClient } from "@tanstack/react-query";
import axios from "axios";
import type { IssuePage } from "./types";

async function getIssues(page: number) {
  const { data } = await axios.get(
    `https://prolog-api.profy.dev/issue?page=${page}`
  );
  return data;
}

export function useIssues(page: number) {
  const query = useQuery<IssuePage, Error>(["issues", page], () =>
    getIssues(page)
  );
  return query;
}

The types in our case might look like this.

type PageMeta = {
  currentPage: number;
  limit: number;
  totalItems: number;
  totalPages: number;
  hasPreviousPage: boolean;
  hasNextPage: boolean;
};

enum IssueLevel {
  info = "info",
  warning = "warning",
  error = "error",
}

type Issue = {
  id: string;
  projectId: string;
  name: string;
  message: string;
  stack: string;
  level: IssueLevel;
  numEvents: number;
};

export type IssuePage = {
  items: Array[Issue];
  meta: PageMeta;
};

Now we not only have advanced errors and warnings in our IDE. We don’t even have to remember the data structure of our API data. The IDE’s autocomplete feature (here VS Code) takes care of that.

Advanced Example: A Paginated List Component With Great UX

Great, we saw a simple example of how to make a request to our REST API. We also already saw some of the hidden powers that come with react-query out of the box.

Now it’s time for a slightly more advanced example. We’ll implement the pagination for our issue list. At the surface, this only means adding a query parameter to the request URL. But as we’ll see in a bit there are some UX hick-ups that we’ll run into.

It’s magic how easily those are fixed just by adjusting a few react-query options.

Simple Pagination

Let’s start by adding pagination. In our useIssues hook we can simply add a parameter and append it to the URL.

async function getIssues(page) {
  const { data } = await axios.get(
    `https://prolog-api.profy.dev/issue?page=${page}`
  );
  return data;
}

export function useIssues(page) {
  return useQuery(["issues", page], () => getIssues(page));
}

Note that we also added the page parameter to the cache identifier of useQuery. You can compare it to the dependency array of the useEffect hook.

In our component, we can simply pass the page state variable to the useIssues hook and connect it to the pagination buttons.

export function IssueList() {
  const [page, setPage] = useState(1);

  const issuesPage = useIssues(page);
  if (issuesPage.isLoading) {
    return <div>Loading...</div>;
  }
  if (issuesPage.isError) {
    return <div>An error occured: {issuesPage.error.message}</div>;
  }

  // we use the meta data returned in the response to disable
  // the "Next" button below
  const { items, meta } = issuesPage.data || {};

  return (
    <Container>
      <Table>
        <thead>
          <HeaderRow>
            <HeaderCell>Issue</HeaderCell>
            <HeaderCell>Level</HeaderCell>
            <HeaderCell>Events</HeaderCell>
            <HeaderCell>Users</HeaderCell>
          </HeaderRow>
        </thead>
        <tbody>
          {(items || []).map((issue) => (
            <IssueRow key={issue.id} issue={issue} />
          ))}
        </tbody>
      </Table>
      <PaginationContainer>
        <div>
          <PaginationButton
            onClick={() => setPage(page - 1)}
            disabled={page === 1}
          >
            Previous
          </PaginationButton>
          <PaginationButton
            onClick={() => setPage(page + 1)}
            disabled={!meta.hasNextPage}
          >
            Next
          </PaginationButton>
        </div>
        <PageInfo>
          Page <PageNumber>{meta.currentPage}</PageNumber> of{" "}
          <PageNumber>{meta.totalPages}</PageNumber>
        </PageInfo>
      </PaginationContainer>
    </Container>
  );
}

The pagination works already well. When clicking on the buttons at the bottom able to see the different pages of issues as expected. As a bonus, thanks to the automatic caching the user doesn’t even see a loading screen when navigating to a previous page.

But as you can see the loading state that is shown when clicking on the “Next” button is pretty annoying. The table disappears completely until the new data arrives.

It would be great if we could show the old data until the next page is loaded. And no surprise, this is very simple: we just need to add an option to useQuery.

export function useIssues(page) {
  return useQuery(["issues", page], () => getIssues(page), {
    keepPreviousData: true,
  });
}

The loading state is gone! The table doesn’t disappear anymore.

This looks already a lot nicer. But the drawback is the delay between the button click and the next page being rendered. Depending on how fast the request resolves the user might not understand that the button has any effect and fall into “click rage”.

Prefetching The Next Page

But of course, react-query is there to the rescue. The docs have a section about prefetching data so that the user doesn’t have to wait. Here is the code from the docs:

const prefetchTodos = async () => {
  // The results of this query will be cached like a normal query
  await queryClient.prefetchQuery(['todos'], fetchTodos)
}

Even better, the docs (can’t praise them enough) provide examples for common use cases. Among them an example implementation for pagination that includes prefetching the next page. Let’s adapt that example to our application:

import axios from "axios";
import { useQuery, useQueryClient } from "@tanstack/react-query";

export function useIssues(page) {
  const query = useQuery(["issues", page], () => getIssues(page), {
    keepPreviousData: true,
  });

  // Prefetch the next page!
  const queryClient = useQueryClient();
  useEffect(() => {
    if (query.data?.meta.hasNextPage) {
      queryClient.prefetchQuery(["issues", page + 1], () =>
        getIssues(page + 1)
      );
    }
  }, [query.data, page, queryClient]);
  return query;
}

This makes paginating basically instantaneous. There’s no delay for the user (as long as the prefetch request has been resolved obviously).

When you look at the network requests at the bottom you can see how the next page is already loaded upfront.

Reducing The Number Of Requests By Adjusting The Stale Time

There’s a last small issue though: when clicking the “Next” button there are two requests. On the initial page load there are two requests as expected (page 1 and 2). But when we click on the “Next” button there are again two requests (page 2 and 3).

The reason is that react-query refetches “stale” data automatically. But for our kind of app, the data doesn’t go stale that quickly so the duplicate request for page 2 isn’t necessary. The additional requests may increase our server costs so we can as well get rid of them.

The solution is simple: we add another option called staleTime that we pass to useQuery.

export function useIssues(page) {
  const query = useQuery(["issues", page], () => getIssues(page), {
    keepPreviousData: true,
    // data is considered stale after one minute
    staleTime: 60000,
  });

  ...
}

Now we only see one request for the second page. We got rid of the unnecessary request.

Summary

While useEffect combined with fetch or axios seems like a simple solution at first you risk ending up with a whole bunch of unmaintainable spaghetti code.

Modern React projects use libraries to outsource the complexities of common use cases in data fetching. react-query is currently one of the most popular data-fetching libraries. And you have seen its power.

With only a few lines of code and a few config options, we were able to create a snappy paginated list with fairly good UX.

Still, we’ve seen only a fraction of what’s possible with react-query. Check out the awesome docs for many more features.

How To Approach A React Pair Programming Interview (Not Only The Tech Skills Count)

Johannes Kettmann — Fri, 30 Sep 2022 11:35:01 +0000

You’re invited to a React interview with a live coding session? Your first reaction was 🎉 and your second “OMG, what am I going to do? 🤯”

Pair programming sessions during an interview are really scary. Much more scary than take-home assignments. Especially if you’re applying for your first React job. There’s a much more experienced and professional developer who watches you writing code? And asks questions?

But hey, when life gives you lemons make lemonade. As intimidating as they are live coding sessions can be a real opportunity.

In contrast to take-home challenges, they don’t take that much of your time and you can show off a much broader skill set:

- Communication skills.
- Thought process.
- Personality.

And these can help you land the job even if you didn’t ace the challenge from a technical perspective.

As you will see on this page, you don’t need to be a 10x developer to ace a pair programming interview. You don’t even have to finish the challenge. So don’t worry too much about the coding part itself. Instead, show the interviewer that you have a structured thought and problem-solving process. Your chances of getting to the next stage will skyrocket.

Read on to learn how.

Soft Skills Are Important
How To Approach A Pair Programming Interview
1. Clarification
2. Planning
3. Implementation
4. Transparent Communication When The Time Runs Out
How To Practice For A Pair Programming Interview
1. Tech Skills
2. Common Tasks

Soft Skills Are Important

Who would you select for a job?

A developer who dives head-first into the challenge, cranking out code like crazy, but at the same time runs in the wrong direction because they misunderstood the task.
A developer who writes pretty good code but comes off as arrogant and gets defensive when you ask questions.
A developer who takes a bit longer to write code, makes mistakes, or doesn’t finish the task in time. But they ask questions, make sure they understand the task, share their thought process along the way, and are receptive to feedback.

Don’t get me wrong, the ideal candidate has both strong technical and strong soft skills. But even if you’re not a 10x developer from a technical perspective you can make a lot of ground with your soft skills

Just how to do so?

How To Approach A Pair Programming Interview

In this section, you’ll learn about a little framework that you can use when you go into a pair programming interview. It consists of four phases and is based on how work in a real-world developer team happens:

Clarification.
Planning.
Implementation.
Transparent communication (when the time runs out).

If you walk through these steps in a pair programming session you’ll signal a certain level of seniority in your thought process that many Junior developers lack. As you’ll see in a bit things that might look like annoyances or failures at first glance (e.g. asking questions or running out of time) are in fact opportunities to prove your professionalism and communication skills.

Clarification

A mistake that many developers (especially inexperienced ones) make, is to read the task once and dive head-first into the code. But to the interviewer, this can be a sign of Junior’s mindset. Such a rushed approach is a sign that on the job you might head in the wrong direction and waste lots of valuable time.

So before you start coding you should clarify the requirements. Read the assignment again and ask the interviewer if you have any questions.

Even if you think everything is clear there might be hidden assumptions on both sides. To flush those out you can repeat the task step by step in your own words. Like this:

"I just want to make sure that I get everything right. I have to do ... Is that right?".

This might feel like you’re annoying the interviewer. But it’s an essential process in real-world teams that prevents developers from wasting lots of time building features that don’t work as intended.

Planning

When the requirements are clear you can make a rough plan. Tell the interviewer how you would approach the problem.

For example, a common task is to fetch data from an API and render it. You could start by checking the response of the API in the browser (if it’s a simple GET request). Then you’d say:

"There are two options to fetch the data: I could use a useEffect and implement the API call there. But usually, I'd use a library like react-query. It’s very useful because it helps to handle a lot of overhead related to data fetching like loading state, error handling, caching, and so on. Then depending on the data structure I'd iterate over the array and render it in a component.”

This again helps to flush out hidden assumptions and misunderstandings. On top of that, coming up with different options and weighing them against each other is again a sign of seniority.

Note: even if you haven’t worked with react-query or similar libraries before you can still say that it’s a popular choice but you don’t have experience with it yet.

Implementation

Now it’s time to write the code. Obviously, it’s good if you practiced similar tasks before (more on that in a bit). A pair programming interview is a very stressful situation already. And having the practice and ideally, a bit of muscle memory will help you stay calm.

While you’re coding it’s a good idea to talk out loud. Explain what you just did and what you’re trying to achieve next. This shows your communication skills and highlights your thought process.

When you get stuck or don’t remember something you’re often allowed to use Google. You can also ask your interviewer for help. This is not a sign of weakness. It happens to everyone (especially in a stressful situation like this). And on the job, a common mistake by Junior developers is to not ask for help when they’re stuck. They often rather dig down a rabbit hole and waste time going in the wrong direction when the solution is indeed simple.

Finally, if you know how to write tests definitely go for it. You don’t need to test everything or use a TDD approach. Just one or two tests will show the interviewer that you are comfortable with this. You’ll appear much more professional. It might be a good idea to ask upfront though:

"I'd usually write a test for this component. But since the time is limited should I write one now?"

Not many candidates write tests in coding challenges. So this is a great way to stand out.

Transparent Communication When The Time Runs Out

From my experience, it’s often not that important to finish all the assignments in time. Especially if you take the time to clarify everything, talk the interviewer through your code, and write some tests, there’s a good chance that you don’t finish everything.

Let me share my personal way story: I was on a pair-programming interview. React hooks were still pretty new and I made the mistake of using useEffect to fetch data from an API even though I wasn’t very familiar with it. In this stressful situation, I failed to finish the task. But the interviewer appreciated that I talked him through my attempts and I passed the interview anyway.

If you realize that you’re running out of time upfront it’s a good idea to be transparent:

“Hey look, it's obvious that I won't complete the task in time. I still have to style this component and make the button callback work. Is there anything you want me to focus on?”

Running out of time (aka underestimating tasks) is very common in real-world projects. The most important thing is that developers openly communicate this to their managers. This allows the team to cut scope and at least ship something.

How To Practice For A Pair Programming Interview

Now that we talked about the importance of soft skills let’s move on to the technical part. Obviously, your tech skills are very important. Displaying a severe lack of React knowledge will likely cost you the job opportunity.

And, as always, practice is key.

Tech Skills

Commonly tested technical skills are

general rendering logic: e.g. functional components, rendering JSX
state management: e.g. local state with useState, global or shared state with Context
connecting to an API: e.g. with useEffect or a library like react-query, handling loading and error state
debugging: navigating in and understanding an existing codebase, using debugging tools like Chrome dev tools
styling (not to forget): common CSS features like flexbox.

Basically, you’re tested if you can write React components, handle (simple) real-world scenarios like data fetching, and work with CSS.

Common Tasks

Interview challenges mostly aren’t too hard. At least if you would work on them in your usual environment. But in a stressful situation like a pair-programming interview, even simple tasks can turn very difficult.

So it can be helpful to know about common challenges and practice them upfront. This way you will have a general solution in mind already (and maybe even some pitfalls that you can discuss upfront).

Here are a few challenges that are common from my experience and what I read in different communities:

Building a dynamic feature: e.g. a form, a modal that opens via a button.
Fetching and rendering data (from an API): e.g. a list of products and rendering them into a list or grid.
Fixing bugs in a small project.
Implementing a simple design.

All these challenges test a variety of skills like CSS, state management, common JS array functions, API connections, and debugging.

While you practice these tasks don’t forget to practice the soft skills as well. Talk out loud while you’re coding and apply the framework in the previous section (clarification, planning, implementation, transparent communication when the time runs out).

I prepared a few React coding challenges that you can use for your interview preparation

Styling a header based on designs.
Building a modal component that opens when a button is clicked.
Fetching data from an API and rendering it.
Fixing a bug in an existing codebase.

Testing React Apps With Cypress: An In-Depth Guide For Beginners

Johannes Kettmann — Fri, 23 Sep 2022 11:30:40 +0000

You know that you should write tests for your React applications.

But reality shows that most Junior developers never have written a test. And to be honest, it doesn’t feel easy to start. You have to decide between a gazillion tools. Writing tests feels very different than writing your normal frontend code. It’s awkward. And frustrating. Strange errors everywhere that you don’t know how to debug.

But once you get used to it you won’t wanna miss it. You’ll feel much safer because code changes won’t break your app. No need for endless manual tests anymore. Not only that: Writing tests is best practice in many companies and lets you stand out as a candidate if you’re looking for your first developer job.

And turns out, it doesn’t have to be that hard. If you pick the right tools to start with and get a bit of guidance.

On this page, you can find exactly that:

We cover why Cypress is a great tool (especially for developers who are new to testing).
We start by writing a few simple UI tests.
We move on to more complex tests involving data from API requests.
Finally we learn how to debug our way through problems.

But hold on. This is not a theoretical lesson where you simply lean back and enjoy the content. I prepared a project that you can use to follow along. It’s a Next.js app that needs some testing love. We’ll write a few tests together but in the end, I’ll leave a few test cases for you to implement on your own.

The goal is that you leave this tutorial with the skills to start testing your own applications. This is your chance to get hands-on testing experience! I hope you’re thrilled.

Introduction
1. Why Cypress
2. The Project Used In This Tutorial
3. What To Test
Testing Navigation Links
1. Opening A URL With Cypress
2. Accessing An Element Globally
3. Switching Viewports
4. Accessing A Specific Element By Text
5. Interacting With Elements - Clicking
6. Cypress Helps With Debugging
7. Accessing The URL
8. Exercise
Testing That The Navigation Is Collapsible
1. Clicking A Button
2. What To Test
3. Testing The Links
4. Testing That Elements Are Hidden
Testing Pages With API Requests
1. What To Test
2. Accessing Elements Within A Parent
3. Iterating Over A List Of Elements
4. Detour: Different Types Of Testing
5. Mocking Requests/Responses With Cypress
6. Asserting Against The Mock Data
Debugging Broken Tests
1. Using Chrome Dev Tools
2. Setting Breakpoints
3. Inpsecting Variables
4. Inspecting DOM Elements
Your Turn - More Exercises

Introduction

Why Cypress

As with everything JavaScript, there are tons of testing tools in the React and web dev ecosystem. Some are outdated (like Enzyme). Some are super popular but somewhat hard on beginners (like React Testing Library). And one testing tool is popular in real-world projects AND has a relatively low learning curve:

Cypress

The big advantage and reason why I recommend it to beginners is the level of visual feedback and interactivity.

The problem with other testing frameworks like RTL is that

Writing tests feels different from your usual frontend code.
All the output is in the terminal while you’re used to looking at the browser for feedback.
The debugging experience is vastly different. More like debugging Node.js servers than React apps.

With Cypress, you only have the first point.

Once you get used to writing tests you can transfer this knowledge to other frameworks like RTL and get comfortable with the debugging experience there. And that’s surely a good idea since most tests are likely written with React Testing Library nowadays.

But one step at a time. Let me show you why Cypress is so powerful. On your local machine, it has a separate UI where all the tests are run. Next to a browser window where you can watch your tests step by step!

You can click on each step of the tests and get some additional information. You can even open the Chrome dev tools in the browser, read the console output, inspect elements, and use the debugger.

I hope the advantages are clear. You’re likely used to a lot of this stuff already. So it’s mostly Cypress and its API that you have to get used to. On top of that Cypress is super easy to set up. In your project you can simply run

npm install --save-dev cypress

That's it.

The Project Used In This Tutorial

As I mentioned, I created a Next.js app that we'll use as an existing codebase to cover with tests on this page. It's an error tracking tool similar to Sentry or Rollbar. You can find the running app here.

The app belongs to the React Job Simulator program where you can learn and apply professional React dev skills like testing.

I personally am a learning-by-doing type. So I highly recommend following along with this tutorial. From my experience just reading only gets you this far. But applying the newly gained knowledge will make it stick. To get the source code drop your email below.

What To Test

In this tutorial we will test two things: The navigation bar (see screenshot below) and a list of issues that you can see here.

Let’s start with the navigation bar.

With Cypress (as well as React Testing Library) we typically test an application the same way a user would interact with it. For example, we click on an element and see if the browser shows the correct result.

The purpose of a test is to ensure that a feature works correctly. Not that a component gets the right props or a certain callback was run. That’s not what the user sees or is interested in. Shortly it’s irrelevant.

There are lots of things that we could potentially test. But it’s a good idea to focus on the important parts of a feature’s functionality.

In this case, the sidebar navigation serves its purpose if

the links send the user to the correct page
the navigation bar is collapsible.

These are relatively simple UI tests that we'll implement in the following two sections. Testing the issues page is a bit more complex as it involves API requests. We'll have a look at that in the 4th section.

Testing Navigation Links

First, let's focus on the links in the navigation. Here is one way of testing them:

We get the links in the navigation.
We click each link.
We check the URL to ensure that the correct page has opened.

Opening A URL With Cypress

First, we need to do some setting up. Before each test, we need to open the application from within Cypress (here the home page works well). This is done via the cy.visit() command.

Open the file cypress/integration/navigation.spec.ts and add the following code:

describe("Sidebar Navigation", () => {
  beforeEach(() => {
    cy.visit("http://localhost:3000/dashboard");
  });
});

But how do we get the links? First, it’s a good idea to get an overview of the navigation DOM structure. In our normal browser, we can open the dev tools and inspect the navigation.

Accessing An Element Globally

All the links are grouped in a nav tag.

Since there are other links on the page it’s smart to start with that group. We can access an element with the cy.get() command. This command accepts a selector as a parameter (the tag nav here) and returns all corresponding elements on the website.

describe("Sidebar Navigation", () => {
  beforeEach(() => {
    cy.visit("http://localhost:3000/dashboard");
  });

  it("links are working", () => {
    cy.get("nav");
  });
});

Easy. Now let’s double-check that everything’s working fine.

In the Cypress UI, we click on navigation.spec.ts. This should run the tests which looks like this:

If Cypress doesn’t find the element in question it throws an error. But the test passes so everything is alright. Accessing the nav element via cy.get("nav") worked.

Switching Viewports

But wait. Where is the navigation bar?

Have a close look at the Cypress browser. This is the mobile view. And on mobile the navigation is hidden.

That means we first need to set the viewport to desktop. That can be done with the cy.viewport() command.

describe("Sidebar Navigation", () => {
  beforeEach(() => {
    cy.viewport(1025, 900);
    cy.visit("http://localhost:3000/dashboard");
  });

  it("links are working", () => {
    cy.get("nav");
  });
});

When you save the file the test should automatically re-run. Now our Cypress UI should show this:

Accessing A Specific Element By Text

Now let’s test the first link. Since the “Projects” link points to the route / (which is the current route) we test the “Issues” link first.

The problem is that there are multiple links in the navigation. The cy.get() command that we used before doesn't work well in this case. It would get all links on the whole page. But we want a specific one. The one inside the navigation that says “Issues”.

To get an element by its text content we can use the contains() command. To make it even more specific we can chain it with the get() command.

it("links are working", () => {
  // check that issues link leads to the right page
  cy.get("nav").contains("Issues");
});

Interacting With Elements - Clicking

Now we should have access to the "Issues" link and can interact with it. To click the link we can simply use the click() command.

it("links are working", () => {
  // check that issues link leads to the right page
  cy.get("nav").contains("Issues").click();
});

The test should run again and hopefully pass.

Cypress Helps With Debugging

It’s time for some Cypress magic. In the screenshot above do you see what happens when you hover over the “click” step on the left? It highlights the element that was clicked in the browser.

This is super helpful to understand what’s going on and debug issues.

Accessing The URL

OK, looks like everything is fine for now.

The last step to test the link is to check that the correct page is opened. As mentioned above we can simply check the URL. We can use the cy.url() command and test its value with the should() command.

it("links are working", () => {
  // check that issues link leads to the right page
  cy.get("nav").contains("Issues").click();
  cy.url().should("eq", "http://localhost:3000/dashboard/issues");
});

The test passes. Everything is as expected, yay!

Exercise

Now is your chance to get your hands dirty. We created a test for the first link here. But there are a few links that need to be tested as well:

Projects
Alerts
Users
Settings

Note: You can add all these tests to the same it("links are working", ...) test case.

Testing That The Navigation Is Collapsible

Now let’s test a dynamic part of the sidebar navigation. When you click the”Collapse” button at the bottom left (either on your local machine or here) you should see the navigation bar collapse.

Clicking A Button

We start with another it(...) wrapper. Same as in the tests before we get the nav element and find the “Collapse” button inside using cy.get() and cy.contains(). Finally we click it.

it("is collapsible", () => {
  // collapse navigation
  cy.get("nav").contains("Collapse").click();
});

When you check the Cypress UI the test passes and the navigation is collapsed. Everything seems to work fine. Again you can hover on each of the steps on the left to see what happened in the UI.

What To Test

Now how do we test that the navigation is collapsed and ensure that it works? There are two things that seem sufficient to me:

Check that all links are rendered and work correctly.
Check that the text next to the icon is hidden.

Testing The Links

Let’s start with the links. Since we tested each link’s target in the previous test I don’t think we need to do that again. Instead we can check that the correct number of links is rendered and that any of these is works correctly.

To get all links, we can use the cy.find() command.

it("is collapsible", () => {
  // collapse navigation
  cy.get("nav").contains("Collapse").click();

  // check that links still exist
  cy.get("nav").find("a").should("have.length", 5);
});

Now we can take any one of these links and check that it still leads the user to the correct page. To access a specific element from an array Cypress provides the first(), eq(), or last() commands.

cy.first() doesn’t work in our case since that would be the “Projects” link which is the current page. The test would pass even if the link didn’t do anything. cy.last() seems a bit more fragile. It would break if we’d add another link to the navigation.

So let’s settle for cy.eq(). This would still break if we change the order of the links but seems like the least fragile option.

it("is collapsible", () => {
  // collapse navigation
  cy.get("nav").contains("Collapse").click();

  // check that links still exist and are functional
  cy.get("nav").find("a").should("have.length", 5).eq(1).click();
  cy.url().should("eq", "http://localhost:3000/dashboard/issues");
});

Testing That Elements Are Hidden

Finally, let’s check that the user only sees the icons and not the text next to them. Testing one link should be the same as they’re handled by a single component. So let’s use the “Issues” link.

it("is collapsible", () => {
  // collapse navigation
  cy.get("nav").contains("Collapse").click();

  // check that links still exist and are functional
  cy.get("nav").find("a").should("have.length", 5).eq(1).click();
  cy.url().should("eq", "http://localhost:3000/dashboard/issues");

  // check that text is not rendered
  cy.get("nav").contains("Issues").should("not.exist");
});

Great, we added our first simple UI tests. There are other things that we could test (like the navigation on mobile devices). But more on that later. Let’s continue with testing data-driven components.

Testing Pages With API Requests

If you visit the app’s projects page and look carefully (or with a sufficiently slow internet connection) you can see this loading state. This indicates that the page loads data from an API.

To be fair, this is not the best loading indicator but that’s a task for the React Job Simulator.

Once the data is loaded we see the projects rendered on the page.

What To Test

Now, how do we test this data?

Again like a user would use the app. We get the elements on the page (here the project cards) and check that the correct values are rendered.

First, let's again get an overview of the DOM structure. When you inspect the first project card in your dev tools you’ll see this:

We can see that each project card is wrapped in a li tag. This seems like a good selector for our tests.

Accessing Elements Within A Parent

The problem is that we know from the previous tests that there are li elements in the navigation bar as well. So when we try to access the project cards we need to be careful not to grab the navigation links.

The easiest way to prevent this is to identify a suitable parent element of the project cards and access this first. Here the main element seems like a good fit since the navigation is rendered outside of it.

That’s enough information for now. Open the file cypress/integration/project-list.spec.ts and add the following code.

describe("Project List", () => {
  beforeEach(() => {
    cy.viewport(1025, 900);
    cy.visit("http://localhost:3000/dashboard");
  });

  it("renders the projects", () => {
    // get all project cards
    cy.get("main")
      .find("li")
  });
});

Iterating Over A List Of Elements

Now we can make use of the each($el ⇒ …) command to iterate through this list. The first parameter $el of the callback function allows us to access each element.

So to test that e.g. the first card contains the project title “Frontend - Web” it makes sense to simply try to write $el.contains("Frontend - Web"). Unfortunately, this gives us an error.

The type of the parameter $el is JQuery<HTMLElement>. And this doesn’t support the Cypress commands like contains().

Looking at the docs there is a simple solution though: we can just wrap $el with cy.wrap() and access all Cypress commands as we’re used to.

So let’s test the first project card. For now, we simply hard-code the expected values.

describe("Project List", () => {
  beforeEach(() => {
    cy.viewport(1025, 900);
    cy.visit("http://localhost:3000/dashboard");
  });

  it("renders the projects", () => {
    // get all project cards
    cy.get("main")
      .find("li")
      .each(($el, index) => {
          // only test the first project card
          if (index === 0) {
            cy.wrap($el).contains("Frontend - Web");
            cy.wrap($el).contains("React");
            cy.wrap($el).contains("73");
            cy.wrap($el).contains("12");
            cy.wrap($el).contains("Error");
            cy.wrap($el).find("a").should("have.attr", "href", "/issues");
          }
      });
  });
});

Ok, all tests pass. That tells us that the overall approach works. But obviously hard-coding the expected data and wrapping it in an if clause isn’t really an option. There are two problems:

The tests would get unnecessarily long.
What happens when the data returned by the server changes? The tests would fail.

Detour: Different Types Of Testing

In order to make these tests pass reliably, we need to always have the same data. There are two ways of achieving that

we have a server that always delivers the expected data
we mock the responses

In larger projects, you often find test environments that include databases, servers, and so on. This is a great way to test the application from the database to the frontend. These tests are also called “end-to-end test”.

Here we don’t have such a test server so we’ll mock the responses. This way we only test the frontend isolated from the rest of the system. This is called an integration test.

If you want to read more about the different types of testing and their advantages read this awesome blog post by Kent C. Dodds. As a summary, he argues that integration tests usually get you the most bang for the buck. They are relatively performant (better than end-to-end tests but worse than unit tests) and give you good confidence that your application is functioning (less than e2e but more than unit tests).

Note that Cypress is probably not the best tool to use for perfomant tests. That would rather be Jest + React Testing Library. But as I said earlier, it’s a better option for beginners due to the easy setup and visual feedback.

Mocking Requests/Responses With Cypress

So we decided to write integration tests by mocking out our API requests. The first step is preparing our mock data. There are a few options:

Write the data by hand.
Use a tool to create random data from a schema.
Use existing API data.

In our case, we already have a working API. So we can simply copy our mock data from one of the requests. The easiest way to access this data is via the browser’s dev tools:

To get data from any request in Chrome simply follow these steps:

Open the “Network” tab.
Filter the requests by “Fetch/XHR”.
Click on the “project” request.
Open the “Preview” tab.
Right-click below the data and click “Copy object”.

Cypress has a separate folder for mock data at cypress/fixtures. A fixture in our case is simply the mock data that makes our tests repeatable. Create a file in that folder called projects.json and paste the data you copied above there.

Mocking the response to this request is now simple with the cy.intercept() command. You can get the URL of the API endpoint again from the network tab in the browser’s dev tools.

beforeEach(() => {
  // setup request mock
  cy.intercept("GET", "https://prolog-api.profy.dev/project", {
    fixture: "projects.json",
  }).as("getProjects");

  // set desktop viewport
  cy.viewport(1025, 900);
  cy.visit("http://localhost:3000/dashboard");

  // wait for the projects response
  cy.wait("@getProjects");
});

In the above code we also use the as() command to create an alias. We can use this alias to wait for the response before the tests start. This is useful to prevent the tests from randomly failing due to timing issues (aka making them less “flaky”).

When you re-run the test now you should receive the mock data. You can double-check that the test doesn’t send real requests either by

changing something inside the mock data or
checking the request in the Cypress UI (as shown in the screenshot below).

Asserting Against The Mock Data

Remember that we hard-coded the expected data for the first project card in the test? Now we can replace it with the data from our fixture.

import capitalize from "lodash/capitalize";
import mockProjects from "../fixtures/projects.json";
import { ProjectLanguage } from "features/projects/types/project.types";

describe("Project List", () => {
  beforeEach(() => {
    // setup request mock
    cy.intercept("GET", "https://prolog-api.profy.dev/project", {
      fixture: "projects.json",
    }).as("getProjects");

    cy.viewport(1025, 900);
    cy.visit("http://localhost:3000/dashboard");
    cy.wait("@getProjects");
  });

  it("renders the projects", () => {
    const languageNames = {
      [ProjectLanguage.react]: "React",
      [ProjectLanguage.node]: "Node.js",
      [ProjectLanguage.python]: "Python",
    };

    // get all project cards
    cy.get("main")
      .find("li")
      .each(($el, index) => {
        const projectLanguage = mockProjects[index].language as ProjectLanguage;
        // check that project data is rendered
        cy.wrap($el).contains(mockProjects[index].name);
        cy.wrap($el).contains(languageNames[projectLanguage]);
        cy.wrap($el).contains(mockProjects[index].numIssues);
        cy.wrap($el).contains(mockProjects[index].numEvents24h);
        cy.wrap($el).contains(capitalize(mockProjects[index].status));
        cy.wrap($el).find("a").should("have.attr", "href", "/issues");
      });
  });
});

Note that we need to add some additional logic. The reason is that in some cases, the data is changed by the frontend before displaying it to the user. For example, the project language can be node in the response data but will be displayed as Node.js.

Debugging Broken Tests

When you write your own tests you will run into problems at some point. So it’s important that you know how to debug your tests.

I prepared an example for a failing test in the file cypress/integration/issue-list.spec.ts for us to debug together.

it("renders the issues", () => {
  cy.get("main")
    .find("tr")
    .each(($el, index) => {
      const issue = mockIssues1.items[index];
      const firstLineOfStackTrace = issue.stack.split("\n")[1].trim();
      cy.wrap($el).contains(issue.name);
      cy.wrap($el).contains(issue.message);
      cy.wrap($el).contains(issue.numEvents);
      cy.wrap($el).contains(firstLineOfStackTrace);
    });
});

This looks pretty similar to the test for the project pages. It’s supposed to check that the data inside the issues table is rendered correctly.

But when you run it you’ll see that there’s an error:

Note: you can tell Cypress to only run a certain test or set of tests by appending .only to describe or it. This way you don’t have to wait for all tests to run while you’re working on a single test. In our case, we can write it.only("renders the issues", () => {.

The error above looks strange: Cannot read properties of undefined (reading 'stack'). It’s not immediately clear what that means.

So let’s dig deeper. But how to debug your tests?

Using Chrome Dev Tools

The answer is simple: You can do the same things that you can do in your normal Chrome browser as well. For example:

Inspect DOM elements
Print out variables with console.log() from either your code or your tests
Add breakpoints to stop code execution

In our case, we can start by investigating the test file. We could add console.log() statements in the code. But let’s be a bit more professional and use the debugger.

Setting Breakpoints

First, open the dev tools inside your Cypress UI. You can do that either with your usual key combination or by right-clicking somewhere in the browser window and clicking “Inspect”

Next click on the “Sources” tab. You should see a hint on how to open a file (in my case ⌘ + P).

Now you start typing the file name you want to investigate. In this case, “issue-list” should be sufficient to get the correct results.

Note that you can also open the React component (”issue-list.tsx”) which means you can also debug your application code

Once you opened the file you can add a breakpoint. The error message at the left of the Cypress UI tells us that something is wrong in the .each loop. So let’s start there:

Note that I only added one breakpoint. The second appeared by itself. I guess that’s because internally we debug a JS file that is mapped back to its original TS source.

Now we can re-run the test by pressing the refresh button inside the top bar. The code execution should stop within the .each() loop.

Inpsecting Variables

Now isn’t this magic?

We can inspect the variables (specifically $el ) in the right-side menu. We can already see from the class name that this is the header row of the table. But when we hover over the class name it even highlights the element in the UI above. 🤯

The problem is clear now (at least to me since I wrote the test): We wanted to test that the data inside the table is rendered correctly. But the first item we get is the header row which doesn’t contain any data.

Inspecting DOM Elements

As we’ve done before we need to narrow down the search for the correct elements. Let’s look at the DOM structure again to see our options. When you inspect the table with your dev tools you can see this:

The table rows that contain the data are wrapped in a <tbody> tag. So we can use this information to filter out the table header row from our test:

it("renders the issues", () => {
  cy.get("main")
    .find("tbody")
    .find("tr")
    .each(($el, index) => {
      const issue = mockIssues1.items[index];
      const firstLineOfStackTrace = issue.stack.split("\n")[1].trim();
      cy.wrap($el).contains(issue.name);
      cy.wrap($el).contains(issue.message);
      cy.wrap($el).contains(issue.numEvents);
      cy.wrap($el).contains(firstLineOfStackTrace);
    });
});

The test should pass now.

Your Turn - More Exercises

If your fingers are itchy and you want to try this stuff out yourself here is the good news: There are a few test cases left that you can implement yourself.

The issue list has a pagination at the bottom. You can test that the buttons are working correctly and that the right data is rendered.
The page number of this pagination should persist after a refresh.
On mobile devices, the sidebar navigation should not be visible initially and be toggled by the menu button in the header.

Note that the last test is a bit more complex. Cypress doesn’t have a native way to test if an element is outside the viewport. I found this GitHub issue to be helpful.

If you want to try these exercises you can either implement the tests against the deployed version of the app that I shared at the beginning of the page. Or you drop you email below to get access to the source code. There you can also find my implementations of these tests.

How To Debug React Apps With VS Code - Boost Your Debugging Productivity

Johannes Kettmann — Fri, 16 Sep 2022 12:09:50 +0000

Debugging a React app can be a slow and painful process. Adding a console.log() statement here and there until you’re finally in the right spot. Or a more advanced version: Jumping around between setting breakpoints in the Chrome dev tools and editing code in your IDE until the bug is fixed.

But with the right tools and a strategic approach debugging can become much easier. Maybe even fun?!

Turns out much beloved VS Code makes it very simple to debug a React app directly from the IDE. The result: Super easy setup and a more productive debugging workflow.

On this page, you can see how to set up VS Code as a debugger for your React app and see it in action. We’ll debug a small problem with a Next.js application and use (conditional) breakpoints, step into functions, and inspect and edit variables directly from the VS Code. All of this paired with a structured debugging approach and the bug is fixed in no time.

Here’s a short video showing how to set up and use the VS Code debugger. Alternatively, you can find a detailed step-by-step tutorial with screenshots on this page.

Launch Chrome via VS Code
Using The VS Code Debugger
The VS Code Debugger In Action
1. Using Breakpoints in VS Code
2. Conditional Breakpoints To The Rescue
3. Finding The Root Cause
4. Inspect And Edit Variables In The Debugger
5. Step Into A Function

Launch Chrome via VS Code

Starting to debug your React app with the VS Code debugger is surprisingly simple. You let VS Code create a launch.json config for you and slightly adjust it. You can find the file in the .vsocde folder in your repository.

Depending on your app you need to

adjust the url field (here I change the port to 3000)
adjust the webRoot entry (e.g. if your code is in the src folder like create-react-app apps you change ${workspaceFolder} to ${workspaceFolder}/src)

Now you can hit the play button ▶️ to start a Chrome browser in debug mode. The VS Code debugger is automatically attached to this browser.

Note: You could run Chrome in debug mode manually and use the “attach” launch config to attach the VS Code debugger. But I don’t see a reason to overcomplicate things.

If you already have a launch.json file or want to add another config to it you can simply use Intellisense (e.g. by pressing cmd + space on Mac) and get suggestions.

Here is my launch.json file:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Run Chrome",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000",
      "webRoot": "${workspaceFolder}"
    }
  ]
}

Using The VS Code Debugger

Two use the debugger you need two things:

Run your React app (e.g. by running npm start).
Start Chrome via VS Code by pressing the play button ▶️.

You can now use the debugger as you would in the Chrome dev tools. If you’re not familiar with that you can see an example below.

The VS Code Debugger In Action

Let’s imagine the following situation: We’re a developer working on a Next.js app that is in production. Real users, nothing should break.

One of the most important pages used to look like this (you can see a deployed version of it here):

But suddenly we get reports that something is broken (here a deployed version):

Damn, how did this bug make it into production? Our customers are upset. They’re paying good money and rely on our app. Obviously, our managers are going crazy as well.

But we as the developers stay calm. With the right debugging approach we can probably fix this bug in no time.

The error message in production doesn’t tell us a lot. So first we run the app on our local machine.

Since we know that we need to debug the code we use the VS Code debugger to start a Chrome instance.

This opens the browser at localhost:3000 as defined in launch.json.

Now when we navigate to the problematic page we see this error.

Using Breakpoints in VS Code

This error is much better than what we see on the production website. It provides us with two important pieces of information:

The error message “Cannot read properties of null”.
The name of the file and the line where the error occurred: line 49 in issue-row.tsx.

Opening the file in VS Code is really simple. The file path in the error message is in fact a link:

When we click it, the file issue-row.tsx opens in VS Code. Magic.

The error message tells us that the issue prop is likely null at some point. Let’s verify that by adding a breakpoint. Simply click inside the empty space next to the line number.

Once you press the green “Restart” button ↻ the page refreshes.

To speed up the process you can also use a key combination (Cmd + Shift + F5 in my case). You can hover over the button to find out yours.

The code execution stops at the breakpoint. At the same time, the website freezes in its loading state.

As you can see in the screenshot above the issue prop is defined during the first render.

So we press the “Continue” button ⏯️ or F5 a couple of times. The problem is that there are quite a few IssueRow components being rendered. So hitting “Continue” until we find the right issue becomes quickly annoying.

Conditional Breakpoints To The Rescue

Instead of hitting “Continue” all the time, we’d like to skip all the issues that are defined and only stop at the nullish one.

The easiest way to do that is by adding a condition to the breakpoint. Right-click on the breakpoint and select “Edit Breakpoint”.

Now we can enter a JavaScript expression. In our case, we want to stop at issue === null.

We hit enter and continue code execution. And voila we can confirm that at least one issue is null.

To be honest, this isn’t exactly news to us as we already knew this from the error message. But at least we were able to confirm the problem.

Finding The Root Cause

So let’s dig a bit deeper. In a simple JavaScript program, we could just follow the call stack or press the “Step Out” button (⬆️) to find the root cause of the problem.

But with React (and other frameworks) it’s not that easy:

Except the IssueRow we can’t see any of our code files in the “Call Stack” panel. Everything else is internal React files.

This doesn’t help us much.

So, unfortunately, we need to find out where the IssueRow component is rendered manually. The global search function of VS Code is our best friend here.

We open the file and add another breakpoint just before the return statement of the component.

Then hit the refresh button ↻ in the debug controls or F5.

Great, now we see that one item in the items array is indeed null.

Inspect And Edit Variables In The Debugger

Our assumption is that this null value causes the bug. But before we start messing around with our code we can easily verify this assumption by editing the variable inside the debugger.

When we continue the code execution now we can see that the error disappears on the website. The 7th and 8th items in the issue list are now duplicates as expected.

This verifies our assumption that the null value in the data array is the problem.

That makes the solution to our bug simple: we can just filter out all null values from the data to fix the bug. Of course, we could implement the filter function in the component. But maybe a place closer to the data source would be more suitable. This way other (future) components could potentially benefit from the same fix.

Step Into A Function

To dig a bit deeper we have a look at the beginning of the component. The items array with the null value comes from the issuePage variable. And that one comes from a hook.

So let’s set another breakpoint there and hit the refresh button again. Code execution stops at the breakpoint.

Now we can use the “Step Into” button ⬇️ to investigate that hook. The first file that opens is again some internal React file.

But this time we’re better off. After hitting the “Step Into” button a couple of times we end up in the useIssues hook.

Having a closer look the getIssues function seems like a good candidate to filter the data.

Unfortunately, for some reason, we neither can step into the getIssues function nor does code execution stop at a breakpoint inside. If you have a bit of debugging experience you know that there are inconveniences like this from time to time.

Anyway, let’s not allow that to hold us back. We add a bit of code to filter the issues.

Once we hit return we can confirm that the bug is fixed.

Commit, push, deploy. Everyone’s happy.

Codebase Tour Through An Advanced React Project - How The Pieces Fit Together (incl video)

Johannes Kettmann — Fri, 09 Sep 2022 11:58:56 +0000

Have you tried looking at a professionally set up codebase?

Just the appearance of it can be confusing. There are lots of folders and .whatever files that you've never seen. You may have a folder structure that feels uncomfortably different from your typical create-react-app folders.

└── src/
    ├── components/
    ├── contexts/
    └── hooks/

On top of that, there’s usually a lot going on behind the scenes. For example, you have tools that help you

keep your code consistent
detect potential bugs while you write the code
test your app automatically to warn you when a feature is broken
prevent merging broken code in the main branch.

This can be confusing as heck. It's hard to grasp how different parts of the codebase are intertwined and how a developer gets code from their local machine to production. It's like a puzzle of a 1000 pieces that you have to assemble in your mind.

Obviously, it would be great if you had a guide. Somebody with experience who explained to you how things work. And that's typically what you get when you start a developer job (at least if you're lucky). But before that you're on your own. Struggling to fit the pieces together. Or simply giving up.

Good news though: For the past months, I’ve been working on such an advanced project for a training program. And you can get a tour through that codebase right now. To start with here is the source code.

I created this project based on my experiences from real-world projects as well as community recommendations. The project is built with:

Feature-driven folder structure inspired by Bulletproof React
ESLint for static code checks
Prettier for consistent code formatting
TypeScript for type checking
Husky & lint-staged for pre-commit hooks
Cypress for integration testing
Jest for unit testing
Storybook for component documentation
styled-components for styling
GitHub Actions for Continuous Integration

You might be used to or have heard of some of this. Some things might be completely new to you.

In any case, this tour through the codebase helps you fit the pieces together. I explain the folder structure and the tools used in this project with examples of how they work in action.

React Coding Challenge Wednesday - Build A Pixel-Perfect Header (Incl Screencast)

Johannes Kettmann — Wed, 07 Sep 2022 10:27:40 +0000

Every Wednesday for the next few weeks I'll share a new React coding challenge with increasing difficulty.

Many new developers struggle with CSS. Understandably they rather use UI frameworks. But for a frontend developer working with designs and writing custom CSS is an important skill. Especially when they work on customer-facing products that don't use any of the polished UI libraries.

So today, let's practice our CSS skills with a simple challenge. This (and all following challenges) are based on this professionally created project on GitHub and these designs on Figma:

The Challenge: Make A Header Pixel-Perfect

This challenge is a simple UI task: You build the header component for the application's landing page based on Figma designs.

Here is the current state of the website and below is the design.

Skills tested: CSS
Difficulty: Easy

Tasks

Implement the header based on the designs.
The navigation links should point to /, /products, /documentation, and /pricing.
The "Open Dashboard" link already exists but needs to be adjusted to match the designs.

Resources

To run the app on your local machine use the following commands:

git clone https://github.com/profydev/prolog-app.git
cd prolog-app
npm install
npm run dev

Hints

The file you need to edit is pages/index.jsx inside the repository.
Currently, styled-components is used for the CSS. I’d recommend using it as well for your code, but alternatively, you can use CSS modules or inline styles. The library doesn’t matter much here.
The project itself is written in TypeScript but the file for this challenge is plain JSX. Feel free to change the file type to .tsx if you’re comfortable with that.
If you need help because you’ve never worked with designs or you want to make them pixel-perfect, you can get additional resources when you drop your email in the form at the bottom of the page.

If you want a tougher challenge you can try to

Integrate your code into the existing codebase.
Add a Cypress test for the header to the existing test suite.

Solution

Here is the solution to this first task. This is basically what I'd expect a Junior candidate to build for such a challenge (maybe without making the CSS pixel-perfect). All the code is in a single file and not divided into separate components.

Advanced Solution

Here you can watch me refactor the above solution to fit into the existing codebase. It uses the feature-based folder structure, the existing styled-components theme, and adds a Cypress test for the header.

I wouldn't expect this of a Junior candidate. Especially not in an unknown codebase. Still, it might be interesting to watch.

Real-World React Coding Challenges For Your Interview Preparation

Johannes Kettmann — Fri, 02 Sep 2022 12:50:41 +0000

Working through coding challenges is part of the interview process. Especially if you don’t have a lot of professional experience as a React dev yet.

But just for these developers coding assignments pose the biggest problem: there are so few job opportunities for entry-level devs that bombing a coding test really hurts. It’s demotivating. Even humiliating.

So if you’re lucky enough to get a code challenge it’s good to be prepared. And this article is here to help you with that. On this page you can find:

4 realistic React coding challenges that test skills like CSS, simple state management, working with API data, and debugging an existing codebase.
Information about the goal of a coding challenge from an employer’s perspective.
Tips on how to approach a coding challenge during the interview process.

React Code Challenges
1. Style A Header Based On Designs
2. Toggle A Modal
3. Render Elements Based On API Data From A CMS
4. Find The Bug
The (Lesser Known) Purpose Of Coding Challenges In The Interview Process
6 Tips For Coding Challenges In Job Interviews
1. Ask For Clarification
2. Talk While You’re Coding (For Live Challenges)
3. Clean Code Format
4. Use TypeScript And Write Tests If You Can
5. Add A README With Clear Instructions
6. Be Prepared For Questions

React Code Challenges

I recommend you read the whole article before you begin working on the challenges. Nevertheless, let’s start with the most interesting part. Here are a few coding challenges that you could find in a job interview process in your day-to-day work as a developer.

The challenges are based on the codebase and the designs of the React Job Simulator. You can find the source code here on GitHub. They differ in difficulty and test a variety of skills.

Let’s start with a simple task.

1. Style A Header Based On Designs

This challenge is a simple UI task: You build the header component for the application's landing page based on Figma designs.

Here is the current state of the website and below is the design.

Skills tested: CSS

Difficulty: Easy

Tasks:

Implement the header based on the designs.
The navigation links should point to /, /products, /documentation, and /pricing.
The "Open Dashboard" link already exists but needs to be adjusted to match the designs.

Hints:

The file you need to edit is pages/index.jsx inside the repository.
Currently, styled-components is used for the CSS. I’d recommend using it as well for your code, but alternatively, you can use CSS modules or inline styles. The library doesn’t matter much here.
The project itself is written in TypeScript but the file for this challenge is plain JSX. Feel free to change the file type to .tsx if you’re comfortable with that.
If you need help because you’ve never worked with designs or you want to make them pixel-perfect, you can get additional resources when you drop your email below.

Here is the solution to this first task. It's not the cleanest code. I didn't separate the header in a new component file. I didn't use TypeScript or write any tests. But for this challenge it's sufficient.

2. Toggle A Modal

The first challenge was a simple static styling exercise. This one will be a bit more dynamic.

When a user clicks the contact button in the bottom right corner a modal should open to display some contact information. Again, here is the current state of the website.

And here are the designs:

Skills tested: CSS, simple state management, overall React APIs

Difficulty: Easy - Medium

Tasks:

Implement the modal UI.
The "Cancel" button should close the modal and the "Open Email App" should open the user's email client.
The modal should open when the user clicks the contact button.
Don’t use a modal library.

Hints:

The file you need to edit is again pages/index.jsx inside the repository.
It's OK to add all the code to the file mentioned above.
There are two ways of implementing the modal: a simple and a more advanced one that not many Juniors know about. Hence one of the skills tested is “overall React APIs”. If you want to see both solutions drop your email in the form below.

If you want a tougher challenge you can try to:

Integrate your code into the existing codebase.
Add a Cypress test for this challenge to the existing test suite.
Add a Storybook story for the modal component.

Unfortunately, that’s beyond the scope of this blog post. If you're interested in this check out the React Job Simulator.

3. Render Elements Based On API Data From A CMS

This challenge is a bit more advanced. The goal is to connect our website to a Content Management System (CMS). A CMS is like a database & editor for website content. Good examples are Contentful or Strapi.

A CMS is often used by marketing departments to easily create content like landing pages or blog posts. The editor enters text, images, and whatever they need. The CMS stores this data and the application (e.g. our website) can access it via an API.

This way a marketer can easily adjust the text on the website or create completely new pages without asking the developers for help.

In this challenge, you’ll create the following content element that is controlled by data from an API.

Skills tested: Working with API data, CSS

Difficulty: Medium

Tasks:

Load data from the endpoint [https://prolog-api.profy.dev/content-page/home](https://prolog-api.profy.dev/content-page/home) where the last parameter in the URL (home) is called a "slug" that identifies the page.
Render the hero section (the part highlighted in the design) based on that data.
The hero section should match the design.

Hints:

You can fetch the data however you like.
It's OK to add all the code to the file pages/index.jsx.
You can find the Swagger documentation for our API here. (Drop your email below to get more information on that)

If you want a tougher challenge you can try to:

Integrate your code into the existing codebase.
Add a Cypress test for this challenge to the existing test suite.
Add a Storybook story for the modal component.

Unfortunately, that’s beyond the scope of this blog post. If you're interested in this check out the React Job Simulator.

4. Find The Bug

The previous challenges were all about writing code. This one is a bit different. After all, one of the most important skills of a developer besides building features with code is debugging. So I took a little bug from the React Job Simulator and made it freely available for this challenge.

When you open the application's issue page you can see that either the "Events" or the "Users" column doesn't show the right data.

Skills tested: Debugging an existing codebase

Difficulty: Medium

Tasks:

Find out what causes the bug.
Fix it.

Hints:

Think of a structured approach instead of diving into the codebase heads-first. Rather use your browser’s debugging tools than randomly poking around in the code.

The (Lesser Known) Purpose Of Coding Challenges In The Interview Process

Sure, it's a great idea to practice your skills with as many code challenges as you can. But if you want to pass the interview process it's equally important to understand what an interviewer is looking for.

No employer wants to buy a pig in a poke. Hiring someone without any proof of their skills is a big risk. Wasted time and money spent on hiring and training. And the emotional burden of having to let someone go.

One way to test a candidate’s skills is by sending them a coding challenge. This brings its own problems for both sides. But hey, it’s what you often have to deal with if you want the job.

Obviously, coding challenges test your technical skills (e.g. if you know HTML, CSS, JS, or React).

But many Junior devs focus too much on these technical skills. Keep in mind that your soft skills are a very important factor as well. And coding challenges can be a great way to prove that you can communicate or solve problems. An interviewer can ideally follow your thought process and see your attitude towards critique.

This is especially true for live coding challenges or if the interviewers discuss your take-home assignment in a follow-up interview. So be prepared for questions.

6 Tips For Coding Challenges In Job Interviews

Coding challenges can be stressful. Especially if it’s a live assignment where you have to code together with or next to the interviewer.

Here are a few tips on how to approach them.

Ask For Clarification

One of the biggest mistakes (especially made by Juniors) is to jump right into the task. Time is limited and you want to spend it coding, right?

Wrong. The first step of any coding task is to gather all requirements. Re-read the assignment and if you don’t understand something ask for clarification.

This is not a weakness. Imagine you’re on the job and start building a solution without clearly defining the problem first. You may walk in the wrong direction and possibly waste tons of time. Actually, that happens quite a lot.

So for an employer it can be a very important signal if you ask clarifying questions. It shows that you have a clear mind and a structured approach.

Talk While You’re Coding (For Live Challenges)

Live coding challenges can be nerve-wracking. But they are also an opportunity that you don’t have with take-home assignments:

You have a chance to show the interviewer your thought process by talking out loud while you write the code. And being able to explain what you’re doing is a great sign for communication skills.

Unfortunately, that’s easier said than done. Thinking and talking at the same time isn’t for everyone. So practice this upfront. Like rubber duck debugging. Simply explain what you’re planning to do while you work on a small task. The code challenges earlier on this page are a great opportunity to practice.

Clean Code Format

For many inexperienced developers, a clean code format doesn’t seem to be a big concern. Inconsistencies in indentation, use of semicolons, or variable naming are very common.

As a Senior developer (aka a potential interviewer) on the other hand, your eyes have practiced seeing these inconsistencies for years. You can spot them right away and they hurt your eyes.

There’s a simple solution though: Use a code formatter like Prettier for your (take-home) coding assignments.

Use TypeScript And Write Tests If You Can

Experienced developers appreciate the safety they get from using TypeScript or writing automated tests. So if you’re somewhat comfortable with it use types for your code and add tests. The tool doesn’t matter. You can use Jest, React Testing Library, or Cypress. It doesn’t have to be a lot either. One or two tests should be enough to show your professionalism.

Add A README With Clear Instructions

Your interviewers probably won’t run your code on their local machine. But if they do you don’t want to leave them confused.

Add clear instructions on how to install and run your code. And by the way, double-check that your code is working.

If you have some time left you can also add some additional information to the README. Like

How and why you solved the assignment as you did.
What assumptions you made.
What you would improve if you had more time.

Be Prepared For Questions

Adding the information described above to your README will also prepare you for the next step: A discussion with your interviewer about your code.

If you have the chance (e.g. with a take-home test) let the code rest for a bit after you submitted your solution. If you’re invited to a follow-up interview have a close look at your code again.

What seems strange from hindsight?
Are there parts that are particularly hard to understand?
How could you improve or refactor your code?
Anything you would have differently now?

Rethinking your code can help you prepare for the next stage of the interview process. After all, it’s very likely that you’ll get questions about your code assignment.

Experienced Programmers Struggle As Well: Ease Your Imposter Syndrome As A Junior Developer

Johannes Kettmann — Fri, 12 Aug 2022 12:13:39 +0000

At the beginning of their career, most developers feel inadequate. They don’t have anyone to compare themselves to. They don’t know what’s expected of them on the job. And many tutorials or screencasts seem to be created by geniuses.

All this leads to the all-to-common imposter syndrome among programmers.

Unfortunately, there’s no easy way around this. Even experienced developers know this feeling of inadequacy. But one of my former team leads suggested how Senior developers can help Junior devs to ease the pain:

Part of overcoming imposter syndrome is the understanding that everyone puts on their pants one leg at a time. Watching experienced developers making mistakes, running in the wrong direction, or searching on Google can be very helpful for a Junior developer. There's no magic. Most developers aren't geniuses. And over time, you can get to their level too.

Obviously, it’s hard to get this pair-programming experience before you find a job with a good and caring team. So I thought I could expose myself a bit here.

I recorded more than 20 hours of screencasts of me building a React application as a preparation for my upcoming React Job Simulator. You can see what kind of tools I use including Next.js, TypeScript, Storybook, and GitHub Actions. But more importantly, you can see that I make mistakes and run into problems all the time (despite a decade of professional experience as a developer).

So let me expose myself. Here are a few takeaways that might ease your imposter syndrome.

Things take way longer in reality than in “scripted” videos
Experienced developers search on Google all the time
We all struggle with simple problems at times
Takeaways

Things take way longer in reality than in “scripted” videos

When you watch React videos you might have the impression that developers work super fast. But more often than not these developers have built the application already before. They have run into most issues before and know how to overcome them.

This makes the videos easy to watch but might skew expectations towards yourself. But let me tell you that reality is often very different.

Another example: it takes me 10 hours (starting with this video) to build a simple collapsible sidebar navigation. I would have estimated it at 2 hours tops. But again and again, I'm thrown off track because I run into issues with the application and testing setup (e.g. TypeScript, Storybook, Cypress & Jest).

It takes me more than 20 min to render a simple SVG icon inside my Next.js app and Storybook.
It takes me 30 min to set up path aliases with TypeScript (and Storybook). I run into lots of problems and fix them not by a sophisticated debugging approach but by trial and error.

From my experience, progressing this slowly is common especially when you create a new project or start working on an existing codebase. At some point when you know how things are done and where they belong your writing code starts to flow more and more. Until you hit the next brick wall of course.

Experienced developers search on Google all the time

You might think that Senior developers know it all by heart. They can create a component/context/portal/reducer with one brush and along the way add typings and tests without a second thought.

But no, even experienced devs can’t remember loads of stuff. You don’t use everything on a daily basis. So you forget things. And sometimes it just doesn’t stick even if you Google it over and over again.

Here are a few examples from my screencasts:

Here I need to look up how React context works. I don’t use it that often so I just forget. Instead of Googling I also like to simply copy & paste from another file in the project.
Here I’m stuck on a simple TypeScript configuration problem. The solution was actually simple (just disable the isolatedModules flag in the tsconfig file). But I couldn’t see the forest for the trees. Instead of simply looking at the docs (one of the top results on Google) I randomly open tutorials and StackOverflow questions only to settle on a hacky workaround.

We all struggle with simple problems at times

You might think: “Sure also experienced developers struggle. But the problems they struggle with are much tougher!”

And yeah, that’s true. But even with years of experience, you’ll have a sufficient number of face-palm moments. You might work on something for days only to find out that you built an inferior version of an existing npm package. You might Google for hours for a solution to your broken CSS only to find out you forgot to import the stylesheet.

Here are a few examples of my screencasts:

Here I’m surprised that an element is wider than in the designs. I settle on a weird workaround using CSS calc(width - padding) only to find this comment later:

Here I’m wondering what’s the best approach to keeping a navigation bar collapsed while navigating to another route. It takes me a while to understand that I need to switch from local state to global state with context.

Takeaways

Hopefully, these examples were enough to convince you that (most) developers are only humans. But obviously, there are also lots of things that you learn over time. Here is a short list of some of the most important things I do differently now compared to myself early in my career:

Read error messages carefully. Often the solution to your problem lies within.
Google is your friend but use the docs as a starting point instead of searching for tutorials right away.
If you get stuck take a step away, go for a walk, take a nap, or do whatever you like. The solution to your problem often comes while your brain rests.
Review your own code after taking some time off. You gain a new perspective on your code and can detect problems easier.
Debug problems systematically and not by changing random code all over the place.

How Professional (React) Developer Teams Plan & Estimate Features (incl screencast)

Johannes Kettmann — Fri, 01 Apr 2022 12:41:07 +0000

To plan their features professional teams use processes with multiple roles involved. They ideate, design, plan, estimate, and prioritize features before they start the implementation. They split large features into small chunks that can be tackled by multiple devs in parallel.

Sounds reasonable. But without job experience, you probably don’t have a clue what that looks like in real life. The goal of this article is to expose you to a typical feature planning process. One that you’ll likely encounter on your first job.

First, we’ll cover a bit of theory about a typical product team and the planning process.
Later we’ll apply the learnings to two examples. At least the parts that you’ll likely be involved in as a Junior developer.

The examples are based on user stories and designs. This way you can see the process applied in a realistic scenario and practice it yourself.

My advice is to read at least the theory part on this page before watching the video below. The explanations here are admittedly better than in the video.

If you want to get hands-on practice in a professional environment sign up for the upcoming React Job Simulator.

A Typical Product Team
The Feature Planning Process
- Feature Requests, Stories & Designs
- Refinement
- Estimations
- Technical Planning
- Implementation, QA & Deployment
- The Board
Example 1: Planning a simple Sidebar Navigation
- User Story
- Refinement
- Estimation
- Technical Planning
Example 2: Planning a complex interactive page
- User Story
- Refinement
- Estimation
- Technical Planning

Note: The descriptions here are based on my experience working with a handful of teams. The exact process and responsibilities differ from team to team. But the overall picture should be similar in many companies.

A Typical Product Team

Before we dive into the planning process we should understand what a typical product team looks like. What kind of roles are involved? What are their responsibilities?

These are the people that a frontend developer works with on a daily basis:

Note: this is written from the perspective of a developer. Some things are simplified and technically not accurate (e.g. Product Manager and Product Owner may not be the same role). There might also be other roles involved like QA engineers. Still this should paint a similar picture to what a new developer encounters in their first job.

The Product Manager (or Product Owner in Scrum terminology): there’s typically one PM for a team of developers. They basically ensure that the devs have something to work on (apart from refactoring the codebase).

They gather feature requests and requirements.
They write tasks in the form of user stories (more on that later).
They prioritize features and tasks together with upper management.

In essence, Product Managers are the bridge between the outer world (e.g. upper management or other departments) and the developers.

The Designer: there’s typically one designer for a team of developers. Often they even work with multiple teams. Their responsibilities are creating UI designs (obviously) but they might also be involved in user research (e.g. as UX designers).

The Developers: for every Product Manager or Designer there are typically multiple developers. In most cases, the development is the bottleneck of building a product. Their responsibility is to implement new features, fix bugs, maintain and improve the system, but also to participate in plannings and estimations of upcoming features.

Which leads us to the next chapter.

The Feature Planning Process

Here is a bit of background information about how a feature makes its way from ideation to being deployed to production. This is a bit theoretical but we’ll see two hands-on examples later on.

Feature Requests, Stories & Designs

The whole process starts with a request for a new feature. This request might come from within the team, the business people, another department (like the marketing department), or the company’s users.

The Product Manager gathers the requirements for the feature, works with the designer to create the UI, and writes user stories. Often one or more developers are also involved in this process to understand technical feasibility early on.

A User Story is a type of task that describes (part of a) feature from the perspective of a user. It doesn’t contain much technical information but explains the purpose of the ticket. Multiple stories might be grouped together as an Epic which describes the complete feature.

A common template for a user story is this: “As a ... I want ... so that ...”

An example: “As a user I want to use a navigation bar so that I can easily visit all the important parts of the application”.

Refinement

Once the Product Manager decides that the feature and user stories are in a presentable state they discuss them with the developers in a so-called backlog refinement or backlog grooming.

This is a meeting where the whole team meets and everyone has a chance to ask questions and raise concerns about potential implementation issues. For example, a part of the feature might look simple but could be very complicated to implement. Often the PM and designer aren’t aware of that. The team can discuss the issue and either find a simpler solution or split the story into smaller chunks.

Once all questions are cleared it’s time to estimate the effort.

Estimations

Management needs to make projections. When will a feature be ready? When should our customers expect it? What does our roadmap look like? Usually, estimations are used to make these projections. And the easiest and most obvious way to estimate is to ask a developer: “How long does it take to build this?”

Nothing a developer hates more...

Experience shows, that this leads to vastly underestimated timelines. So smart people tried to decouple estimates from time by assigning complexity points to stories. Developers basically say: “This task sounds complicated. I give it an 8.” or “This is simple. It’s a 1”.

These numbers are called Storypoints.

They don’t have any inherent meaning but over time the team usually aligns on what each number represents.

The idea is that you can observe how many points a team can accomplish in a certain timeframe (often a 2-week Sprint). This is called velocity. And the average velocity over a couple of Sprints can then be used by management to get a time estimate for a feature.

Many teams use numbers from the Fibonacci series (1, 2, 3, 5, 8, 13, 21...). The theory is that the more complex a task the more inaccurate its estimate. The increasing gaps between the Storypoints represent this inaccuracy.

Now, this sounds all great in theory. But the numeric nature of Storypoints often leads to misuse. Typical signs are:

The Storypoint estimate is transformed into a time estimate. Example: “This story has 1 point so it should take half a day.”
Storypoint estimates are turned against the dev team: “You gave this feature 60 points in total so you have a deadline of 4 weeks” or “This team needs to increase its velocity.” or worse “Team A is much more performant than Team B because of its higher velocity.”

Most importantly though, research shows that you can simply count the number of stories instead of the Storypoints and basically get the same estimate. So the whole estimation effort might be a waste of time.

Nevertheless, most teams make use of Storypoint estimations. So if you want to start a career as a developer you’re likely to encounter them sooner rather than later.

Technical Planning

This meeting is optional. It might also take place before the estimations.

Once the user stories are estimated the developers gather again to discuss the technical details. Remember, a user story is written from the user’s perspective and typically doesn’t contain a lot of technical information.

Much of the technical discussion should already have happened before the estimation. So if required the devs simply break each user story into multiple technical tasks that make sense from their perspective. These could include things like adding a column to a Database table, updating the API, or adding a component to the UI library.

Implementation, QA & Deployment

At this point, the user stories are ready for development. The developers pick them up one by one and implement them. Somebody tests the implementation. Ideally, the feature is covered with automated tests to prevent future regressions. And finally, the feature is deployed to production so the users can benefit from it.

We won’t go into details here since this article focuses on the planning process.

The Board

All the tasks are visualized on a board. Below is an example of a Kanban-style board with multiple columns. The user stories start at the very left in the backlog. Once they are refined and estimated they can be moved to the Todo column. Now developers can pick a task and move it to the next columns depending on its implementation status.

Example 1: Planning a simple Sidebar Navigation

All this theory can be a bit boring and hard to understand. So let’s continue with two hands-on examples. We’ll start with a simple component.

I don't usually suggest to view the blog on my website. But if you want to practice the process you will have a better experience there since the solutions are hidden initially. Click here to jump to this section on my website.

User Story

The first user story of the upcoming React Job Simulator is the sidebar navigation. Here is a screenshot of the ticket from the board above:

You can see the actual User Story, the design, and a list of Acceptance Criteria (also AC). The exact ticket format varies from team to team. The AC don’t include many technical details but describe the functionality from the perspective of a user. Here they basically describe the behavior of the design in words.

Refinement

During the refinement session, the team goes through the User Story, the design, and the proposed Acceptance Criteria.

Please have a look yourself. Are there inconsistencies in the design? Anything unclear from the ticket description? Anything wrong or missing from the AC? Anything you’d like to change?

Here is what I found:

...

The refinement of this ticket reveals two smaller problems:

The last acceptance criterion contains a mistake: the navigation bar shouldn’t slide out to the right but to the left.
The current page is highlighted in the menu (the “Issues” page in the design). This is missing from the acceptance criteria.

The Product Manager agrees and updates the AC:

Estimation

The user story is pretty clear so we move on to estimate the user story. As a reminder, every developer picks a number of the Fibonacci series (1, 2, 3, 5, 8, 13, 21) where 1 is a very simple task. Let’s say changing a text or color could be a 1.

Here is a chance for you to practice: Think of a number that represents the complexity of this user story before you read on. No worries, there’s no right or wrong at this point.

My estimate and explanation:

...

As I said, there’s no right or wrong in this answer. Over time our understanding of these estimates would more and more align.

Assuming that you said something different we could agree on one of the estimates (often the higher one just to be safe). Or we discuss our reasons. This can be very valuable when there are big differences in estimates because it often shows a need for clarification of the user story.

So let me explain why I picked a 3: The sidebar navigation doesn’t look overly complex. It’s a simple UI component without API calls or so involved. But there is a bit of interactivity:

The sidebar on desktop is collapsible so we need some kind of state.
The current element is highlighted. This shouldn’t be hard using the URL but it adds some complexity.
The mobile design behaves differently from the desktop version.

Technical Planning

From my perspective, we don’t need to split this user story into multiple technical tasks. We might create a task each for desktop and mobile design due to the different behavior. But I’d leave it as a single user story.

Example 2: Planning a complex interactive page

The sidebar navigation was pretty straightforward. Now let’s have a look at a more complex user story from my upcoming React Job Simulator. Here is a screenshot of the issues page design:

Alright, there are a lot more complex components and interactive elements in this design. A look at the board shows that the Product Manager created two user stories:

Let’s take the “Issue List” as an example here.

User Story

Here is a screenshot of the user story:

Refinement

Again, please have a look yourself. Are there inconsistencies in the design? Anything unclear from the ticket description? Anything wrong or missing from the AC? Anything you’d like to change?

Here is what I found:

...

You can see the complexity of this user story from the acceptance criteria alone. When we have a closer look there are a few things to note:

The name of the column “Level” in the original design is “Status” in the user story. The design in the user story is just a screenshot of the real design in Figma. And it seems outdated. So never rely on the screenshots in the description of a task.
The pagination buttons don’t behave as expected in the design. On the first page, the “Previous” button should be disabled. On the last page, the “Next” button should be disabled. This should also be reflected in the AC.
A large chunk of the acceptance criteria is about the checkboxes and the related “Resolve selected issues” button on top of the table. While it might make sense to include this in the story from the Product Manager’s perspective, we as developers know that there’s a lot going on behind the scenes. The behavior of the checkboxes is already somewhat complex. And a click on the button triggers an API request which includes error handling and the update of the issue list. The suggestion here is to move this to a separate user story “Resolve Issues”.

Luckily, the Product Manager doesn’t put up a fight. They create a separate user story (we’ll ignore that here) and update the AC according to our feedback:

As you can see, the refinement session helped to keep the user story concise and uncovered some cases that weren’t yet mentioned in the acceptance criteria. Especially getting the input of multiple developers can be illuminating here.

Estimation

It’s time for the estimation. Pick a Storypoint (1, 2, 3, 5, 8, 13, or 21) where 1 is a simple task like changing a text or color.

Here is mine:

...

Again, it’s expected that we picked different Storypoints. No right or wrong here. But let me explain my decision:

The table row itself is pretty straightforward (assuming that we get a list of issues with the required data). But the graph could become a bit more complex. We probably should use a chart library and need to compare different options. There’s always a risk that the library doesn’t really fit all requirements like the rounded bars or the gap between bars.
The pagination adds some complexity. I’m assuming here that the API supports proper pagination. In any case, we need to trigger new API calls whenever one of the buttons is clicked and handle the state of the buttons according to the current page.
Remember the original design? On desktop, we have a table. On mobile, each issue is rendered as a card though. I’m not sure how complicated this will be from the top of my head. I guess it should be possible with a CSS grid or so. Still, from my perspective, this adds to the story’s complexity.

Technical Planning

This user story is obviously a bit more complex. I’d say it makes sense to split it into multiple tasks for the developers. There are some advantages to having multiple smaller tasks:

The Pull Requests don’t become that big and thus are easier to review.
Multiple developers can start implementing the feature in parallel (if the tasks don’t depend on each other too much).

So let’s start breaking the user story up. As a reminder here are the design and the acceptance criteria from the story:

Think about the different tasks that you would create. How can you split the story into small self-contained tasks? How can you allow multiple devs to work in parallel?

Here are the tasks that I created

...

The “Create Issue Row” task is a simple UI component excluding the graph. We can build this with the help of Storybook. This should be tackled first.
The “Create Table Task” contains the API call and rendering of the items in a table. It depends on the “Create Issue Row” task but a developer could start already to implement the API call.
The “Create Mobile Design” task can be started as soon as the first task is done. I’m honestly not sure if this should be a separate task or not. Making this a separate task could lead the developer to forget about the differences between the desktop and mobile design. But that would make a great exercise for the React Job Simulator.
The “Implement Pagination” task can be started as soon as the “Create Issue Table” task is done. It’s very independent of the other tasks otherwise.
Finally, the “Create Graph” task is about the column showing the graph. Since this adds a bit of complexity to the user story it makes sense to extract it into a separate task. This way the Product Manager can de-prioritize the graph if there’s a pressing deadline or the team concludes that the effort is not justifiable at this moment.

Continuous Integration Pipelines with GitHub Actions for (React) Developers (incl screencast)

Johannes Kettmann — Sat, 19 Mar 2022 12:18:12 +0000

If you don’t have experience working with a professional dev team yet, you probably don’t know how collaboration among developers typically works. One of the most important parts is the Git workflow.

A very common workflow among professional teams is Trunk-Based Development. In a nutshell, it works like this:

You work on a separate Git branch and push it to GitHub.
You create a Pull Request where automated scripts check your code and your teammates review it.
You merge the Pull Request to the main branch once it’s approved.

We covered this workflow in detail in a previous article. So if anything is unclear, I’d recommend reading it first (or have a look at my free course where you can learn and practice this workflow).

On this page, we’ll focus on the automated scripts in the second step. This is called the Continuous Integration pipeline and typically runs tools like a linter (e.g. ESLint), code formatter (e.g. Prettier), or tests.

If this is all sounds like Gibberish, no worries. Have a look at my free course where you can learn and practice this workflow.

In the video below I walk through the setup of a GitHub repository for a Next.js app that I created in a previous blog post. You can find a summary below the video. In a nutshell, you’ll learn

How to set up a Continuous Integration pipeline with GitHub Actions to automatically run ESLint, Prettier, and tests in each Pull Request.
How to prevent code from being merged to the main branch if it doesn’t pass the pipeline.
How to use pre-commit hooks to run checks even before you can create a commit.

The application is part of the upcoming React Job Simulator where you can work on an existing codebase using this and other professional workflows and tools. Just like you would in a real job.

Continuous Integration with GitHub Actions
Status Checks: Prevent merges of Pull Requests that don’t pass the CI pipeline
Pre-commit hooks: validate your code before a commit

Continuous Integration with GitHub Actions

In the previous article, we set up the GitHub repository to use branch protection. This way we can enforce branches can only be merged to the main branch via a Pull Request that is approved by another teammate.

The approval process can be very valuable. But especially code reviews are also time-consuming. You don’t want to waste time complaining about details like code formatting. On top of that, it’s not feasible to test all the code by hand to ensure that the rest of the application still works as expected.

As you know, we have tools to assist us: TypeScript and ESLint to catch bugs, Prettier to format our code, and tests to make sure that our app works.

With the help of a Continuous Integration pipeline, we can run all these tools within our Pull Requests. This way we decrease the effort spent on code reviews and reduce the risk of introducing bugs. And that again helps to merge Pull Requests frequently (which is the whole meaning of Continuous Integration by the way).

There are many tools to build CI pipelines. The simplest option for repositories on GitHub is probably GitHub Actions. It’s as easy as creating a file called .github/workflows/main.yml in your repo.

For my project, the file looks like this:

name: CI

on:
  # runs on pushes to the main branch
  push:
    branches: [main]
  # also runs inside pull requests that target the main branch
  pull_request:
    branches: [main]

jobs:
  build:
    # uses a Ubuntu Docker image (like a virtual machine)
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: "14"
          cache: "npm"
      # install dependencies
      - run: npm ci
      # run ESLint & Prettier
      - run: npm run lint
      - run: npm run prettier
      # verify that there are no build errors
      - run: npm run build
      # run tests with Cypress
      - name: Cypress run
        uses: cypress-io/github-action@v2
        with:
          start: npm start

The following happens whenever a commit is pushed to the main branch or to a pull request that targets the main branch:

A Ubuntu machine is spun up, the code from the repo checked out, and Node.js installed.
ESLint and Prettier are run to check for bugs and correct code format.
The project is built to verify that there are no TypeScript and build errors.
The Cypress tests are run to verify that the app behaves as expected.

In our Pull Request, we now have status checks (one to be precise).

In case something goes wrong and the CI pipeline fails we can inspect the details. You just click on the “Details” link at the very right of the status check.

Here is an example where I committed code that wasn’t formatted correctly. This looks just like the output of a normal terminal.

Status Checks: Prevent merges of Pull Requests that don’t pass the CI pipeline

At this point, we force everyone on the team to use Pull Requests and we have a CI pipeline that automatically checks our code. Unfortunately, a developer can still decide to merge a PR even though it didn’t pass the CI pipeline. Wouldn’t it be awesome if we could prevent that?

That’s where our branch protection rules from the previous article come in again. You can find an option “Require status checks to pass before merging” that we didn’t select before. Once our CI pipeline has run at least one time we can enable it and select the required CI jobs.

You simply edit the existing rules for the main branch, check the option, and select the job from the workflow file (in this case “build”).

Now the merge button inside a Pull Request is disabled whenever the CI pipeline fails.

Pre-commit hooks: validate your code before a commit

Once you start working with CI pipelines you realize that it takes a while to run them. It can be annoying to come back to a Pull Request after a few minutes only to realize that the CI failed because of a dumb ESLint error.

This is where pre-commit hooks come in handy. They allow you to automatically run scripts when you create a commit. If one of the scripts fails the commit is stopped.

Since the goal is to commit frequently I wouldn’t recommend running complex tasks in pre-commit hooks. For example, running a whole test suite on every commit quickly gets annoying. Pre-commit hooks are best suited for fast scripts like npm run lint or npm run prettier. Especially when they only check the staged files and not the whole repository.

The easiest way to set up pre-commit hooks that only run on staged files is by using lint-staged.

npx mrm@2 lint-staged

This will install Husky under the hood and set up some scripts to run before a commit. You can find them in the lint-staged section in your package.json file.

This is the package.json file for my project. I already adapted it to run on JavaScript and TypeScript files.

{
  "scripts": { ... },
  "dependencies": { ... },
  "devDependencies": { ... },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": "eslint --cache --fix",
    "*.{js,jsx,ts,tsx,css,md}": "prettier --write"
  }
}

When you try to commit code that contains an ESLint error the pre-commit hook will complain now.

Note that it’s easy to skip the pre-commit hooks by using the git commit --no-verify option. So you can compare our setup to form validation in web apps:

The pre-commit hooks are the validation on the frontend. They give quick feedback but you can easily hack them.
The CI pipeline is the backend validation: It takes a bit longer to realize that something went wrong but you can’t simply work around them.

Professional Git Workflow & GitHub Setup for (React) Developers (incl screencast)

Johannes Kettmann — Fri, 18 Mar 2022 12:31:58 +0000

If you’re a solo developer working on your own projects your Git workflow is usually simple: You work on the main (or master) branch all day every day.

You probably know that professional developer teams don't work like this. Multiple devs all committing to the main branch can quickly become chaotic. And it’s likely that unreviewed or untested code makes it into production eventually. Danger!

Professional teams use processes and workflows to prevent this from happening. And the most common Git workflow used in developer teams (at least from my experience):

Trunk-Based Development (or more correctly Scaled Trunk-Based Development).

If your goal is to find a job as a professional developer I highly recommend getting used to this workflow upfront. The more you know how to work like a professional the less you’ll be overwhelmed on your first job.

I promise: it’s not very difficult if you know the basics of Git. But there is a lot of glossary around it that might confuse you at first.

Watch the video below to see me walk through one cycle of the workflow. Below the video you can find instruction on how to set up branch protection in your GitHub repository to enforce this workflow and a detailed walkthrough based on screenshots.

This series of articles and the application I'm building are part of my upcoming React Job Simulator. Build a project hands-on like a professional team and gain job-like experience.

Trunk-Based Development in a Nutshell
Branch Protection: Enforce usage of Pull Requests
A tour through the Trunk-Based Development workflow
1. Open a Pull Request
2. Continuous Integration Pipeline
3. Code Reviews
4. Handling Review Comments
5. Approving a Pull Request
6. Merging the Pull Request
7. The history of the main branch
8. Updating the local main branch
Summary

Trunk-Based Development in a Nutshell

You check out a new branch from the main branch.
You commit your code on this branch and push it to the GitHub repo.
You open a Pull Request (or Merge Request as GitLab calls it).
Automated tests verify that the application behaves as expected.
A teammate reviews your code and you adjust it according to the feedback.
You merge your branch into the main branch via the Pull Request (short PR).

If this is all sounds like Gibberish, no worries. Have a look at my free course where you can learn and practice this workflow.

What the heck is a Pull Request?

I always found the name Pull Request on GitHub confusing. GitLab calls it a Merge Request which is much more descriptive. Basically, a Pull Request is a way to ask for permission to merge your code into the main branch:

“Hey team, can somebody have a look at this code and tell me if it’s any good? I’d like to get it into the main branch so our users can benefit from it.”

You can think of a Pull Request as a feature on top of a Git branch that allows you to get feedback from your teammates. And as mentioned it also allows you to automatically run checks and tests on your code changes before they go to the main branch.

To summarize, Pull Requests are

a mechanism to gather feedback and thus increase code quality
a tool to run automation (e.g. tests) on your code to decrease the risk of introducing bugs into production code.

Branch Protection: Enforce usage of Pull Requests

Processes and workflows are great. But people are lazy and look for workarounds. So ideally we want to force everyone on the team to use Pull Requests instead of committing directly to the main branch.

Luckily GitHub has our back with a feature called “branch protection”. To protect the main branch open your repository’s settings on GitHub, select “Branches” in the left menu, and click on the “Add rule” button.

A few notes about the selected rules:

In a team of developers the option “Require a Pull Request before merge” → “Require approvals” is mostly activated. This way we can enforce that developers review and approve each other’s code. That is one safeguard against new bugs and ideally increases code quality and coherence.
The option “Require linear history” is not necessary but from my experience many teams use it nowadays. It prevents merge commits on the respective branch. Instead you have to either “Squash and merge” a Pull Request or “Rebase” it. You can see the “Squash and merge” in action including an explanation here in the video.
The “Include administrators” option is important if you want to enforce the workflow for yourself in your own repositories. Since you’re the administrator the rules wouldn’t apply to you otherwise.

If a developer now creates a commit on the main branch and tries to push it they will see an error message.

A tour through the Trunk-Based Development workflow

Open a Pull Request

git checkout -b migrate-to-styled-components

Now we write our code, commit and push it to the remote repository on GitHub.

git commit -m "Migrate home page to styled-components"
git push origin migrate-to-styled-components

On GitHub, you should now see a banner to create a Pull Request.

Once you click the button you see a form where you can enter a title and description. Next click the “Create Pull Request” button.

Congrats, you opened your first Pull Request! This is what you should see now:

Continuous Integration Pipeline

Did you note the status checks at the bottom of the PR?

This is a really handy feature. You can run scripts like npm run lint or npm run test within your Pull Requests to decrease the risk of introducing bugs. This is called a Continuous Integration pipeline. I’ll leave it as a cliffhanger for tomorrow’s article. If you can’t wait you can already watch me set it up in the video.

Code Reviews

In a real-world team, your code is typically reviewed by at least one teammate. This again prevents bugs and helps keep the codebase clean and consistent. A Pull Request is also a great way of discussing your code in case you’re stuck.

So let’s switch to another account with access to the repository. Here is how our imaginary teammate would review your code.

Our teammate can add comments to the code.

Finally, they submit the review.

As the author of the Pull Request, we can now see the comments.

Handling Review Comments

We have two options now: we can update our code according to the comments or start a discussion.

To adjust our code we simply head back to our local machine, change the code, commit and push it. You can see the new commit below the review comments. You can also add a comment and resolve the conversation.

Finally, you can request a new review:

Approving a Pull Request

Once your teammate is pleased they can approve your Pull Request by submitting a review. They might add a useless yet affirmative emoji comment to make you happy.

Merging the Pull Request

Finally, it’s time to merge our Pull Request. Now our code changes will be added to the main branch.

Remember that we set the “Require linear history” option in our branch protection rules? That’s why we see a “Squash and merge” button instead of a simple “Merge” button by default.

Let’s see what happens when we push the button:

And once we press the confirmation button we’re all set.

The history of the main branch

I didn’t explain yet what the “Squash and merge” button does, right? The Pull Request (or our Git branch) contained multiple commits:

When we look at the commit history of our main branch we don’t see these commits anymore. Instead, there’s only a single commit that points to the Pull Request (via the link #6):

All the commits of our original branch have been squashed into a single commit. The benefit here is that you don’t need to keep the commits in the Pull Request super tidy. For example, commits that are simple fixes during the review process like “Remove unused class name” don’t really need to show up in the history of the main branch.

Updating the local main branch

As the last step (that’s easy to forget) we sync our local main branch with the remote repository. Since the merge happened on GitHub our local machine doesn’t know about these changes in the main branch yet.

git pull origin main

When we work in a team of developers we should actually do this every time we start working on a new branch.

Summary

In this article you learned how to set up a GitHub repository with branch protection to enforce a popular Git workflow called Trunk-Based Development. By now, I hope you're less intimidated by Git & GitHub thanks to the detailed walkthrough.

How to set up a professional React project (including screencast)

Johannes Kettmann — Fri, 11 Mar 2022 11:49:10 +0000

When you start a new React app you might wonder how to set it up in a professional way. What tools should you use? What libraries do you need from the start?

Based on the most popular React tech stack this article will guide you through the setup of a new application using

Next.js
Typescript
ESLint
Prettier
styled-components
Cypress
Storybook

The video below shows how I set up the app for my upcoming Bootcamp for Self-Taught React Devs with exactly this tech stack. The screencast is nearly unedited to show the whole process and not only the polished outcome. If you're looking for a quick guide you can find all steps for the setup on this page.

Next.js & TypeScript

Next.js is the go-to React framework. It has a lot of neat features like server-side-rendering that are important for many professional apps. Many developers tend to use it for any new React project.

This command creates a new Next.js application using TypeScript. (Feel free to remove the --typescript option if you already have too much to learn.)



npx create-next-app@latest --typescript

You'll be prompted for a project name and the package manager of your choice. I simply went with npm.

Note: if you plan to host the project on GitHub you might want to rename the master branch to main with this command: git branch -m master main

ESLint

The Next.js app is already set up with ESLint which is used to detect bugs by statically analyzing your code.

For my taste, the default rules that come with Next.js are not strict enough though. For example, unused variables don't cause an error. A standard set of rules found in the ESLint docs is eslint:recommended. We can extend it in the eslintrc.json config file.



{
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended"
  ]
}

Prettier

Prettier is used to automatically format your code according to a standard. That makes your code more readable and saves you a lot of manual effort.

You can use a Prettier plugin for your IDE. I use VS Code and its Prettier extension with the following settings to auto-format when I save a file.

To integrate Prettier with ESLint you can use the eslint-config-prettier and add it to your eslintrc.json config. This way you don't get conflicts between Prettier and ESLint.



npm install --save-dev eslint-config-prettier



{
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "prettier"
  ]
}

The Next.js app doesn’t use the Prettier format by default. Run npx prettier --write to format all files.

styled-components

styled-components is a very popular library for writing custom CSS. Next.js doesn’t support it out of the box, but this official example repo shows us how to set it up. First, we install the library.



npm install styled-components

Then we add styledComponents: true to the compiler option in the next.config.js file.



const nextConfig = {
  reactStrictMode: true,
  compiler: {
    styledComponents: true,
  },
};

Additionally, we need to create the pages/_document.tsx file to avoid a "flash of unstyled content" on the initial page load according to the example repo.



import Document from "next/document";
import { ServerStyleSheet } from "styled-components";
import type { DocumentContext } from "next/document";

export default class MyDocument extends Document {
  static async getInitialProps(ctx: DocumentContext) {
    const sheet = new ServerStyleSheet();
    const originalRenderPage = ctx.renderPage;

    try {
      ctx.renderPage = () =>
        originalRenderPage({
          enhanceApp: (App) => (props) =>
            sheet.collectStyles(<App {...props} />),
        });

      const initialProps = await Document.getInitialProps(ctx);
      return {
        ...initialProps,
        styles: (
          <>
            {initialProps.styles}
            {sheet.getStyleElement()}
          </>
        ),
      };
    } finally {
      sheet.seal();
    }
  }
}

That's it. To use global styles or the ThemeProvider you need to edit the file pages/_app.tsx as shown here.

Cypress

Cypress is a tool that’s commonly used to write end-to-end tests (meaning it tests the whole system from frontend to database just like a real user).

For the setup, the Next.js docs are again very helpful. First, we install Cypress.



npm install --save-dev cypress

Then we add "cypress": "cypress open" to the scripts section in our package.json file.



{
  ...
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "cypress": "cypress open"
  },

Finally, run npm run cypress to initialize the project. This creates a few folders and demo tests in your repository. Then the Cypress UI opens where you can run the demo tests.

When you open the test files you'll realize that ESLint complains that global functions like describe or it don't exist. To get rid of these errors we can install an ESLint plugin and adjust the eslintsrc.json config file.



npm install eslint-plugin-cypress --save-dev



{
  "extends": [
    "next/core-web-vitals",
    "eslint:recommended",
    "prettier"
  ],
  "plugins": ["cypress"],
  "env": {
    "cypress/globals": true
  }
}

Storybook

Storybook is a tool widely used to document and visually test UI components. According to the docs we first need to initialize or project.



npx sb init

Then run Storybook. This will open a new browser tab where you can play around with some demo components.



npm run storybook

Forem: Profy.dev

REST APIs - How To Connect Your React App Like The Pros (Incl Detailed Example)

Table Of Contents

The Project

React Frontend

REST API

The “Simple” Approach With useEffect

The Code

The Problems

The Effective Approach With react-query

The Advantages

Setup

A Simple Implementation

Advanced Features For Free

Custom Hook As Best Practice

Usage With TypeScript

Advanced Example: A Paginated List Component With Great UX

Simple Pagination

Prefetching The Next Page

Reducing The Number Of Requests By Adjusting The Stale Time

Summary

How To Approach A React Pair Programming Interview (Not Only The Tech Skills Count)

Table Of Contents

Soft Skills Are Important

How To Approach A Pair Programming Interview

Clarification

Planning

Implementation

Transparent Communication When The Time Runs Out

How To Practice For A Pair Programming Interview

Tech Skills

Common Tasks

Testing React Apps With Cypress: An In-Depth Guide For Beginners

Introduction

Why Cypress

The Project Used In This Tutorial

What To Test

Testing Navigation Links

Opening A URL With Cypress

Accessing An Element Globally

Switching Viewports

Accessing A Specific Element By Text

Interacting With Elements - Clicking

Cypress Helps With Debugging

Accessing The URL

Exercise

Testing That The Navigation Is Collapsible

Clicking A Button

What To Test

Testing The Links

Testing That Elements Are Hidden

Testing Pages With API Requests

What To Test

Accessing Elements Within A Parent

Iterating Over A List Of Elements

Detour: Different Types Of Testing

Mocking Requests/Responses With Cypress

Asserting Against The Mock Data

Debugging Broken Tests

Using Chrome Dev Tools

Setting Breakpoints

Inpsecting Variables

Inspecting DOM Elements

Your Turn - More Exercises

How To Debug React Apps With VS Code - Boost Your Debugging Productivity

Table Of Contents

Launch Chrome via VS Code

Using The VS Code Debugger

The VS Code Debugger In Action

Using Breakpoints in VS Code

Conditional Breakpoints To The Rescue

Finding The Root Cause

Inspect And Edit Variables In The Debugger

Step Into A Function

Codebase Tour Through An Advanced React Project - How The Pieces Fit Together (incl video)

React Coding Challenge Wednesday - Build A Pixel-Perfect Header (Incl Screencast)

The Challenge: Make A Header Pixel-Perfect

Tasks

Resources

Hints