DEV Community: Danijel Maksimovic

How to test React Router components?

Danijel Maksimovic — Tue, 07 Nov 2023 22:04:24 +0000

Every React app I had worked with used react-router. There isn't much sense in having an application without it. In this article, we will be looking at how to test the component that is doing the navigation and why mocking React Router's APIs isn't the optimal solution.

Component to test

Let's set an example of a component that navigates to another page on user action:

import { useNavigate } from 'react-router-dom'

export const BackButton: React.FC<{ to?: string }> = ({ to }) => {
  const navigate = useNavigate()

  return (
    <button onClick={navigate(to ?? -1)}>
      Go back
    </button>
  )
}

The component in our example is navigating the user back to the previous page or to the path provided as to prop. It's the usual stuff you see in almost every app.

The mocking approach

How do we test this component to ensure it navigates to the correct page upon clicking the button? Let's take a look at the approach with mocking:

import { useNavigate } from 'react-router-dom'
import { render, screen } from '@testing-library/react'
import { userEvent } from '@testing-library/user-event'

import { BackButton } from './BackButton'

jest.mock('react-router-dom', () => ({
  useNavigate: jest.fn(),
}));

const useNavigateMock = jest.mocked(useNavigate)

it('navigates back to the previous page if `to` prop is not passed', async () => {
  const navigateMock = jest.fn()

  useNavigateMock.mockReturnValue(navigateMock)

  render(<BackButton />)

  await userEvent.click(screen.getByRole('button', { text: /go back/i }))

  expect(navigateMock).toHaveBeenCalledTimes(1)
  expect(navigateMock).toHaveBeenCalledWith(-1)
})

it('navigates to the path provided as a prop', async () => {
  const navigateMock = jest.fn()

  useNavigateMock.mockReturnValue(navigateMock)

  render(<BackButton to='/about' />)

  await userEvent.click(screen.getByRole('button', { text: /go back/i }))

  expect(navigateMock).toHaveBeenCalledTimes(1)
  expect(navigateMock).toHaveBeenCalledWith('/about')
});

We are testing both use cases of the component, with and without to prop, by clicking on the button and asserting that the navigate function returned by useNavigate hook is called with the adequate arguments.

Let's imagine that we don't like how we are navigating in our BackButton component and would like to refactor it to navigate in a declarative way by using the Navigate component from the react-router-dom.

import { Navigate } from 'react-router-dom'
import { useState } from 'react'

export const BackButton: React.FC<{ to?: string }> = ({ to }) => {
  const [shouldNavigate, setShouldNavigate] = useState(false)  

  if (shouldNavigate) {
    return <Navigate to={to ?? -1} />
  } 

  return (
    <button onClick={() => setShouldNavigate(true)}>
      Go back
    </button>
  )
}

Notice our functionality didn't change. We are still navigating back to the previous location if to prop isn't passed and are navigating to to path if provided. Will our test still work?

Unfortunately, no 🫠 Since we are mocking react-router-dom the module in our tests, it will scream at us that there is no Navigation named export from the module and it will fail miserably. Of course, we could refactor the test as well and provide a mock Navigate component and thus fix the test, but the test should survive code refactoring if the behavior from a user perspective didn't change.

Tests should give developers confidence to freely refactor code knowing that they will still pass. 🎉

The reason our test failed is that we have intertwined an implementation detail of how we navigate from page to page with our test. In order to write a better, more stable test we should think of what actually happens when a user clicks on the button.

When a user clicks on the back button a user is taken to the previous page, meaning the URL changes. How can we test this side-effect of the user's action? 🤔

Writing a test without mocking

A while back while I was browsing react-router-dom docs I stumbled upon the MemoryRouter component. In the docs it says it stores its state internally in memory, making it perfect for environments where there is no history object, like tests. That sounds interesting, right?

Let's see how we can use the MemoryRouter to refactor our BackButton component test and make it more resilient:

import { MemoryRouter, Routes, Route } from 'react-router-dom'
import { render, screen, waitFor } from '@testing-library/react'
import { userEvent } from '@testing-library/user-event'

import { BackButton } from './BackButton'

it('navigates back to the previous page if `to` prop is not passed', async () => {
  render(
    <MemoryRouter initialEntries={['/first-page', '/current-page']}>
      <BackButton />
      <Routes>
        <Route path='/first-page' element={<p>first page</p>} />
        <Route path='/current-page' element={<p>current page</p>} />
      </Routes>
    </MemoryRouter>,
  )

  expect(screen.getByText(/current page/i)).toBeInDocument()

  await userEvent.click(screen.getByRole('button', { name: /go back/i }))

  await waitFor(() => {
    expect(screen.getByText(/first page/i)).toBeInDocument()
    expect(screen.queryByText(/current page/i).not.toBeInDocument()
  })
})

it('navigates to the path provided as a prop', async () => {
  render(
    <MemoryRouter initialEntries={['/']}>
      <BackButton to='/about' />
      <Routes>
        <Route path='/' element={<p>home</p>} />
        <Route path='/about' element={<p>about page</p>} />
      </Routes>
    </MemoryRouter>,
  )

  expect(screen.queryByText(/about/i)).not.toBeInDocument()

  await userEvent.click(screen.getByRole('button', { name: /go back/i }))

  await waitFor(() => {
    expect(screen.getByText(/about/i)).toBeInDocument()
  })
})

We need to wrap our BackButton component with a MemoryRouter so it can work with the react-router APIs and we need to set a realistic test environment, providing an array of paths in the history stack.

When a user clicks on the button we check if the correct component is being rendered based on the routing setup and the expected behavior. There is no mocking of the React Router module.

The test written in this way resembles the user behavior, making our test more resilient to code refactors and giving us more confidence in our test suite.

You should repeat yourself when writing tests

Danijel Maksimovic — Tue, 15 Aug 2023 15:51:12 +0000

How would you react if I would say you should duplicate code when writing tests? You would probably think I don't know what I'm talking about and that I will be breaking one of the most followed principles in software development, the DRY principle. Let me convince you that it's perfectly fine to do exactly that and it's the thing you should be doing more when writing tests.

The case for repeating code

Let's say we need to test a function called postStatus that accepts a post and returns the post status. Here's an implementation we need to test:

function postStatus(post: Post): PostStatusEnum {
  if (post.isDraft) {
    return PostStatusEnum.Draft
  }

  if (post.scheduledDate > Date.now()) {
     return PostStatusEnum.Scheduled
  }

  if (!post.authorId) {
    return PostStatusEnum.MissingAuthor
  }

  return PostStatusEnum.Published
}

And here's the test I see very often written by developers:

describe('postStatus()', () => {
   let postData: Post

   beforeEach(() => {
     postData = {
       isDraft: false,
       scheduledDate: null,
       authorId: null
     }
   })

  it(`returns ${PostStatusEnum.MissingAuthor} if post isn't scheduled, isn't draft but doesn't have an author assigned`, () => {
     expect(postStatus(postData)).toBe(PostStatusEnum.MissingAuthor)
  })

  it(`returns ${PostStatusEnum.Draft} if post is marked as draft`, () => {
    postData.isDraft = true

    expect(postStatus(postData)).toBe(PostStatusEnum.Draft)
  })

   // other test cases
})

On the first look, this test looks pretty good, right? What happens when the test breaks and you need to debug it? You skim the failing test case and wonder where does the postData comes from, where it's defined, and how it's connected to the failing test case? It's especially true for the first test case as there is only one line for the whole test suite and you have no idea why postData makes the function return PostStatusEnum.Draft status.

It might be obvious in this example but let's imagine a test case that has 200 lines of code and a dozen test cases and every test depends on multiple variables defined out of the test's scope. It would be very difficult to connect the dots and keep everything in your mental memory while debugging that kind of test.

This is how I would write that same test:

it(`returns ${PostStatusEnum.MissingAuthor} if post isn't scheduled, isn't draft but doesn't have an author assigned`, () => {
  const postData: Post = {
    isDraft: false,
    scheduledDate: null,
    authorId: null
  }

  expect(postStatus(postData)).toBe(PostStatusEnum.MissingAuthor)
})

it(`returns ${PostStatusEnum.Draft} if post is marked as draft`, () => {
  const postData: Post = {
    isDraft: true,
    scheduledDate: null,
    authorId: null
  }

  expect(postStatus(postData)).toBe(PostStatusEnum.Draft)
})

// other test cases

When a test fails in this scenario, everything a developer needs to understand why the test failed is contained within the test. The test is not relying on variables defined in the enclosing scope and it is easy to follow.

I'm repeating myself in every test case, and that is not what we should be doing, right? The testing code is a bit different than the production code. We want to be spending less time grasping the intent of the testing code, and we want to minimize the cognitive load of testing code so we can focus more on production code. Which test example is more difficult to understand, the one that's DRY or the one that repeats itself? In my experience, it's the latter that it's way easier to understand and maintain.

But I don't want to repeat myself?!

Worry not, as we are going to clear the last test example a bit while and still have a minimal cognitive load. Let's take a look at the alternative approach:

it(`returns ${PostStatusEnum.MissingAuthor} if post isn't scheduled, isn't draft but doesn't have an author assigned`, () => {
  const postData = buildPost({
    scheduledDate: null,
    isDraft: false,
    authorId: null
  })

  expect(postStatus(postData)).toBe(PostStatusEnum.MissingAuthor)
})

it(`returns ${PostStatusEnum.Draft} if post is marked as draft`, () => {
  const postData: Post = buildPost({ isDraft: false })

  expect(postStatus(postData)).toBe(PostStatusEnum.Draft)
})

function buildPost(overrides?: Partial<Post>): Post {
  return {
    isDraft: false,
    scheduledDate: null,
    authorId: null
  }
}

// other test cases

Now with this approach, we are not repeating ourselves and we are colocating our test data with our tests.

The bonus is that the test data is laser-focused on the scenario we are testing. In the draft status test case, we are only passing a single Post attribute as the test case concern is only that, to test the draft status. In this way, it's much easier and faster to understand what the test is actually testing, and what makes the difference in the function's output.

This approach can be used in every test scenario, be it a simple function test as we had in our example, a React component, a Fastify endpoint, or a full-blown E2E using Playwright or Cypress. Hope this helps a bit in writing more sane and maintainable tests 👋

TypeScript utility types I use the most

Danijel Maksimovic — Tue, 23 May 2023 20:35:00 +0000

TypeScript comes with a lot of built-in types that can be used for extracting, converting, or manipulating types in many ways. We are going to cover the ones I use the most and we will go through them in a Q&A fashion.

How do I pick a couple of properties of a type?

Let's say we have a type called Post that looks like this:

type Post = {
  title: string
  content: string
  tags: string[]
  slug: string
}

and we want to create a new post type that only has a title and content. We could create it from scratch and duplicate Post's properties, or we can pick the properties we want from the already created type. We don't want to repeat ourselves so we can do it like so:

type DraftPost = Pick<Post, 'title' | 'description'>

Pick utility types creates a new type from a given type by using only properties provided as a union.

How can I remove a property from a type?

In our previous example, we have chosen the properties we want to have in our new type. Let's now remove properties we don't want.

type DraftPost = Omit<Post, 'slug' | 'author'>

Pick and Omit are two sides of the same coin, they do opposite things that can achieve the same result.

How can I pick a value from an enum or a union type?

Let's say we have an enum of post categories:

enum PostCategories {
  React
  Agile
  Fastify
  GraphQL
  Postgres
}

and we would like to create a union of post categories that are only back-end1 related. We could try using Pick type that we saw earlier but it won't help much as Pick type works with object types. Instead, we could use Extract utility type:

type BackendCategories = Extract<PostCategories, 'Fastify' | 'GraphQL' | 'Postgres'>

Newly-created BackendCategories type would be a union PostCategory.Fastify | PostCategory.GraphQL | PostCategory.Postgres. Extract doesn't create a new union, it transforms it into a union.

How can I remove a property from a union or an enum?

In the same fashion as Extract, there is a Extract utility type that does a similar thing as the Omit type, but for union or enum types.

Let's say we want to remove Agile from post categories:

type TechCategories = Exclude<PostCategories, 'Agile'>

Newly-created TechCategories type would be a union of all enum values except Agile.

How do I make a type non-nullable?

Let's say we have a type that is a union of an object type and null, which is a common scenario when typing an API response:

type PostResponse = { data: Post | null }

and let's say we have a function that is transforming API response in some manner:

function transformResponse(apiResponse: PostResponse) {
  // implementation here
}

When trying to access the apiResponse.data properties TypeScript will error out as we are trying to access a property on a potentially nullable value. If we don't want to have the null check in our transform function we could utilize the NonNullable utility type:

function transformResponse(apiResponse: NonNullable<PostResponse>) {
  // implementation here
}

This will make sure apiResponse.data has a Post type as NonNullable utility will remove null and undefined from the union.

How can I make all properties of a type optional?

Sometimes we want to use the existing type but only provide a subset of its properties. For example, we might have a factory function that generates objects of a certain type but would like to provide a way for a user to override generated values:

function buildPost(overrides?: Partial<Post>): Post {
  return {
    id: randomUUID(),
    title: 'Just some title',
    content: 'Description of a post',
    tags: ['tag1'],
    slug: 'just-some-title',
    ...overrides
  }
}

buildPost({ title: 'My custom title' })

In our builder function, we are setting the overrides type to Partial of a post type, which makes all properties of a Post type optional, which gives us an option to only pass a subset of Post properties.

How can I make all properties of a type required?

Let's say we have a form to submit a new post, and we have a type to define the form's input:

type PostInput = {
  title?: string
  description?: string
  tags?: string[]
}

but we need a type when all fields are required, like in the submit handler function:

function submitPost(postInput: Required<PostInput>) {
  // submit a post
}

Required utility type is quite useful when we don't want to repeat ourselves just to make all properties of a type required.

How can I extract a return type of a function?

This one is quite useful when you want to get a type of what a function is returning but you don't have access to the type itself, e.g. when a third-party library exposes a typed function but it doesn't export the returned type. For example:

// third-party library
type Slug = // complex slug type that isn't exported

export function slugifyString(str: string): Slug

// your app
type Slug = ReturnType<typeof slugifyString>

type Post = {
  id: string
  title: string
  slug: Slug
}

In our example, we are using a function that returns some complicated type (Slug) but it isn't exporting it for our use. We want to reuse that value in our application but since it's not exported we should get it in some other way. ReturnType utility type extracts the type a function is returning so we can use it in our own application.

How can get a type wrapped in a Promise?

Let's say our previous example returns a Promise instead of an object type:

// third-party library
type Slug = // complex slug type that isn't exported

export function slugifyString(str: string): Promise<Slug>

type Slug = ReturnType<typeof slugifyString> // it's a Promise now

type Post = {
  id: string
  title: string
  slug: Slug // won't work anymore
}

Our type extraction would now return a Promise type as that's what the function is returning. We need to get to the type wrapped in a promise and we can do it like so:

type Slug = Awaited<ReturnType<typeof slugifyString>>

This might look like a bit too much generics nesting and if it is too much for you, you can split it like so:

type SlugifyStringPromise = ReturnType<typeof slugifyString>
type Slug = Awaited<SlugifyStringPromise>

How can I type an object literal?

Object literals are one of the most used data structures in JavaScript and rightfully so. But how do we type them?

const postsByCategories = {
  [PostCategory.React]: [post1, post2],
  [PostCategory.GraphQL]: [post3, post4]
  // ...
}

Let's say we would like to allow only post categories as keys and only an array of posts as values:

const postsByCategories: Record<PostCategory, Post[]> = {
  [PostCategory.React]: [post1, post2],
  [PostCategory.GraphQL]: [post3, post4]
  // ...
}

The only keys TypeScript would allow are values from PostCategory enum and only an array of Posts can be set as a value. The Record utility type is really useful when we have a map of set keys and values.

These are the utility types I use the most, although this isn't the complete list of available utility types. Had over to the TypeScript documentation to get familiar with even more utility types.

Thanks for reading!

Mock Service Worker is awesome

Danijel Maksimovic — Thu, 25 Aug 2022 05:46:00 +0000

One of the biggest hurdles for any kind of UX development is the data. We've all been there: we have design layed out, some features in the backlog and we are eager to start developing our new app. But we are depending on the data from the API.

The usual way to overcome this and not be completely blocked by this situation is to use some static mock data and create our components in some component development environment, e.g Storybook. Having static mock data would allow us to develop some presentational components, but the real meat and potato of our app would need to be developed only after we get the actual data.

The other way is to have the API return some mock data, which we will use in our app, and only when the back-end team provides us with some mock data they can start working on actual features. Again, this is sub-optimal: it slows down back-end team and it puts a lot more pressure on them to get the mock data first and postpone real feature development.

The workflow which would make both teams a lot happier could be to have an agreement on the API spec, which both teams can use as a guide when designing the data model, and to develop its set of features in the order that makes more sense for both sides.

From the front-end perspective, a tool that allows this kind of workflow is Mock Service Worker, or shorter msw and that is what we are going to talk about in this post.

Mock Service Worker (`msw`)

Simply put, msw is a tool for API mocking. It mocks API calls by installing a service worker for you which intercepts network calls to the API and calls your registered handler functions instead. You, as a developer, need to worry only about writing handler functions for endpoints your app is reaching to.

It supports both REST and GraphQL APIs, it can delay the response of mocked API endpoints so the endpoint feels more real-life, it has it's own in-memory database with @msw/data package for more complex querying (e.g, searching, sorting), it can also run mocks in NodeJS environment instead of Service Worker (really useful for testing). Next, let's take a look at which problems msw can solve and how.

Benefits of using `msw`

Testing

Imagine a React component that fetches some data from an API and than it renders that data on to the page. What are our testing options? We could mock the function or a library that is doing the fetching, we could mock the underlying fetch call or we could intercept the network call in some way (e.g, with msw).

The first approach would give us a confidence that our component is calling a function that should return us data, the second approach is giving us confidence that our component integrates properly with the fetching library (swr, react-query, plain fetch or axios) and the last approach is giving us confidence that we are making the right HTTP call.

The beauty of intercepting the network call with msw in our tests is that we are gaining a lot more coverage and thus confidence in our tests, that test reflects real-life way more and we are not coupling our tests with the fetching library. Imagine we needed to change a library we use for making network calls, e.g from swr to react-query. Since we are not actually mocking a fetching library in our tests we don't need to change them at all. In any other scenarios listed above, we would need to refactor our tests as well. Double win!

Independent FE development

My first experience with msw was on a project where I was the only FE developer and I had a BE team of two. We had a really short deadline (1 month) to deliver an app. Both FE and BE were starting from scratch, and the back-end needed to do some work on infrastructure, getting the data sources and writing migration scripts for that data, etc. The client wanted a demo every week to see how the app is coming along. I proposed msw as a way to unblock my development, we would just need to agree on the data models. As we had clear requirements about how the data should look, that part wasn't that difficult.

Using msw, we were able to conduct the demo every week with mocked endpoints that looked realistic. Endpoints had a delay of 500ms to return data, the data between pages was connected (clicking on a table row loads relevant details page), searching returns relevant data, etc.

Once the backend team had some endpoints done, I just removed msw handlers for those endpoints without making any changes to the underlying code. The side-effect is that I had tests that were using the same handlers for realistic tests. msw was a crucial organizational tool on that project that increased team's velocity and made the biggest impact on the project's success.

Debugging

Every once in a while there is a bug in our code that is happening only when a certain response is returned from an API. If you don't have control over the API (some other team is responsible for it, it's a vendor API) than it means that you would need to somehow change the HTTP response in troubling response. Traditional method in these kind of situations is using an OS proxy app like Charles Proxy or Wireshark, but they can be really difficult to setup and to run properly (you have to deal with certificates to see HTTPS calls, etc.).

Alternative is to spin up msw that mocks the endpoint that you need and to just return the data to stress the app with. It's way, way faster and simpler and you can also use that handler to write a test for that scenario (I'm repeating myself, I know).

Conclusion

In this post I've shared my experience using msw library in my own projects and what could be potential benefits for you and your projects. I hope you will give it a try. Let me what is your experience using msw in the comments.

Unit testing render prop component in React

Danijel Maksimovic — Fri, 07 Jun 2019 19:04:08 +0000

What is a render prop?

Render prop is a pattern that is widely used in React ecosystem. In a nutshell, render prop is a pattern in which you are passing a function as a prop, usually called render or more commonly as a children prop. For example:

import React from 'react';

const RenderPropComponent = ({children}) => {
  const [counter, setCounter] = React.useState(0)  

  return children({counter, setCounter});
};

// usage
const Usage = () => {
  return (
    <RenderPropComponent>
      {({counter}) => <p>Counter: {counter}</p>}
    </RenderPropComponent>
  );
};

If you want to read more extensively about render props pattern in React and their usage in React ecosystem check this post.

Test preparation

In order to test render prop component, we should first write one! Our component will fetch posts from an API and expose loading state and posts to a consumer component.

import React from 'react';
import PropTypes from 'prop-types';

import { fetchPosts } from './api';

export default class FetchPosts extends React.Component {
  static propTypes = {
    children: PropTypes.func.isRequired
  };

  state = { posts: [], loading: false };

  async componentDidMount() {
    this.setState({ loading: true });

    const posts = await fetchPosts();

    this.setState({ posts, loading: false });  
  }

  render() {
    return this.props.children({posts: this.state.posts, loading});
  }
}

Writing the test

We are going to write our test using jest and react-testing-library but the same principles apply if you use something else to write your tests.

import React from 'react';
import { render } from 'react-testing-library';

import FetchPosts from './FetchPosts';

const mockPosts = [{ id: 1, title: 'Title' }];

jest.mock('./fetchPosts', () => Promise.resolve(mockPosts));

describe('FetchPosts component test', () => {
  it('should expose loading and posts prop', () => {
    const postsCallbackMock = jest.fn();

    const { getByTestId } = render(
      <FetchPosts>{postsCallbackMock}</FetchPosts>
    );

    expect(postsCallbackMock).toHaveBeenCalledWith({
      loading: false,
      posts: mockPosts
    })
  });
});

This is one a bit simpler way to test render prop component. Another way is to write a consumer component which renders something on the page and then expect it matches with the data that you received. For example:

import React from 'react';
import { render } from 'react-testing-library';

import FetchPosts from './FetchPosts';

const mockPosts = [{ id: 1, title: 'Title' }];

jest.mock('./fetchPosts', () => {
  return new Promise(resolve => {
    setTimeout(() => resolve(mockPosts), 100);
  });
});

const FetchPostsConsumer = () => (
  <FetchPosts>
    {({loading, posts}) => {
      if(loading) return <span data-testid="loading"></span>;

      return posts.map(post => <p data-testid="post-title">{post.title}</p>)
    }}
  </FetchPosts>
);

describe('FetchPosts component test', done => {
  it('should return correct loading and posts props', () => {
    const postsCallbackMock = jest.fn();

    const { getByTestId } = render(
      <FetchPostsConsumer />
    );

    expect(getByTestId('loading').textContent).toBe('Loading');

    setTimeout(() => {
      expect(getByTestId('post-title').textContent).toBe('Title');
      done()
    })
  });
});

At the beginning of this test, we are declaring what our fetchPosts module is returning so we can have the same results on each test run (these tests are called deterministic). This mocked version of a function is resolving a promise but after some timeout, which gives us enough time to inspect the loading state later in our test.

Next, we are declaring a component that is using render prop component that we really want to test. After the component is rendered we are checking if loading text is present. After some time, we are checking if the correct post is being rendered as a result of render prop callback. This approach is a bit longer but in my opinion, it gives us a bit more user-oriented test which in the end is how users are going to use our component.

Conclusion

As you can see testing render prop component is not that difficult in the end. Since that kind of a component doesn't generate an output by itself we have to provide that missing part in our test and then do the assertions. A simpler way is to just provide a mock function and expect that it's called with correct parameters. Which approach do you like more? Share it in the comments below 👇

Render props pattern in React

Danijel Maksimovic — Mon, 10 Sep 2018 20:26:52 +0000

Render props is a pattern popularized by Michael Jackson of reacttraining.com and Kent C. Dodds of Paypal among others. We can see this pattern being used more and more in React itself and it's ecosystem (Context API, React Router, Apollo Client, react-motion, Downshift etc.).

When would you use this pattern?

This pattern should be used when you are building a component that it's not concerned with rendering but it has some important business logic to do for your app. In this way you can reuse this component for business logic (fetching data, doing calculations etc.).

Example

// component that implements render prop
import React from 'react';
import PropTypes from 'prop-types';

import { fetchPosts } from './api';

class FetchPosts extends React.Component {
  static propTypes = {
    children: PropTypes.func
  };

  state = { articles: [], loading: false };

  async componentDidMount() {
    this.setState({ loading: true });

    const articles = await fetchPosts();

    this.setState({ articles, loading: false });  
  }

  render() {
    return this.props.children({articles: this.state.articles});
  }
}

// component that is using render prop component
import React from 'react';

import FetchPosts from './FetchPosts';

const ArticleList = props => {
  return (
    <FetchPosts>
      {({ loading, articles }) => {
        if (loading) {
          return 'Loading...';
        }

        return articles.map(article => <ArticleListItem article />);
      }}
    </FetchPosts>
  );
};

In our example we have a component that is used only for fetching data and it leaves rendering to children passed as a prop (hence the name render props). ArticleList component is using that data to render a list of articles. We could have a different component to render a grid list of articles that gets data from our FetchPosts component.

Example from the community

React's Context API

Let's take a look at React's context API example:

import React from 'react';

const state = {
  counter: 0

const { Provider, Consumer } = React.createContext(state);

const App = props => {
  return (
    <Provider value={state}>
      <Counter />
    </Provider>
  );
}

export default App;
export { Consumer };

// Counter.js
import React from 'react';

import {Consumer} from './App';

const Counter = props => {
  return (
    // render props used here
    <Consumer>
      {state => (
        <p>{state.counter}</p>
      )}
    </Consumer>
  );
}

In our App component we are creating new context with React.createContext and we are passing default value for our context. Provider component is used to set the value which will be provided to a component that requests that value.

In our Counter component we are using Consumer component that was created as a result of createContext's invocation and that component is implementing render props pattern. Children of Consumer component is a function which is called with value that is provided as a prop to Provider component.

React router Route component

React router is one of the most commonly used packages from React community. It also implements render props pattern (it's not using children as a function but it's using render prop). Example incoming:

import React from 'react';
import {BrowserRouter as Router, Route} from 'react-router-dom';

const App = props => {
  return (
    <Router>
      <Route path='/posts' render={(props) => (// ...do something with props and render to UI)} />
    </Router>
  );
}

As you can see Route component accepts render props which is a function which gets props (history, location, match etc.)

Apollo client's Query component

Apollo client implementation for React uses render props in it's Query component. Example of usage:

import React from 'react';
import {Query} from 'react-apollo';

const App = props => {
  return (
    <Query query={POSTS_QUERY} variables={variables}>
      {({data, loading, error, fetchMore}) => {
        if (loading) {
          return 'Loading...';
        }

        if (error) {
          return error;
        }

        return <ArticleList data={data} />
      }}
    </Query>
  );
};

This example is a bit more complex regarding data that's returned from render prop. When Query component is rendering it's children it's passing an object that has decent number of properties that we can use. It's a general rule that your function accepts only one parameter and that you are destructuring properties when implementing function. But you don't have to do it, it's still a function and you can implement it however you want it.

Conclusion

In my opinion and experience using React every day I find that render props is greatly used pattern that suites React's component composition pattern perfectly. I encourage you to think about how you can use this pattern in your code to make it more readable and reusable. Also, please share your usages of this pattern in the comments 👇 Thanks for reading 😄

DEV Community: Danijel Maksimovic

How to test React Router components?

Component to test

The mocking approach

Writing a test without mocking

You should repeat yourself when writing tests

The case for repeating code

But I don't want to repeat myself?!

TypeScript utility types I use the most

How do I pick a couple of properties of a type?

How can I remove a property from a type?

How can I pick a value from an enum or a union type?

How can I remove a property from a union or an enum?

How do I make a type non-nullable?

How can I make all properties of a type optional?

How can I make all properties of a type required?

How can I extract a return type of a function?

How can get a type wrapped in a Promise?

How can I type an object literal?

Mock Service Worker is awesome

Mock Service Worker (msw)

Benefits of using msw

Testing

Independent FE development

Debugging

Conclusion

Unit testing render prop component in React

What is a render prop?

Test preparation

Writing the test

Conclusion

Render props pattern in React

When would you use this pattern?

Example

Example from the community

React's Context API

React router Route component

Apollo client's Query component

Conclusion

Mock Service Worker (`msw`)

Benefits of using `msw`