Filtering and Searching Data

In this chapter, we’ll continue applying the techniques we’ve already learned to another, more complex use case.

As we work through the chapter, we’ll learn how to adjust a component’s design using tests to show us where the design is lacking. Test-driven development really helps highlight design issues when the tests get knarly. Luckily, the tests we’ve already written give us the confidence to change course and completely reinvent our design. With each change, we simply run npm test and have our new implementation verified in a matter of seconds.

In the current workflow, users start by adding a new customer and then immediately book an appointment for that customer. Now, we’ll expand on that by allowing them to choose an existing customer before adding an appointment.

We want users to be able to quickly search through customers. There could be hundreds, maybe thousands, of customers registered with this...

Technical requirements

The code files for this chapter can be found here:

https://github.com/PacktPublishing/Mastering-React-Test-Driven-Development-Second-Edition/tree/main/Chapter10

Displaying tabular data fetched from an endpoint

In this section, we’ll get the basic form of the table in place, with an initial set of data retrieved from the server when the component is mounted.

The server application programming interface (API) supports GET requests to /customers. There is a searchTerm parameter that takes the string the user is searching for. There is also an after parameter that is used to retrieve the next page of results. The response is an array of customers, as shown here:

[{ id: 123, firstName: "Ashley"}, ... ]

Sending a request to /customers with no parameters will return the first 10 of our customers, in alphabetical order by first name.

This gives us a good place to start. When the component mounts, we’ll perform this basic search and display the results in a table.

Skipping the starting point

If you’re following along using the GitHub repository, be aware that this chapter starts with a barebones CustomerSearch...

Paging through a large dataset

By default, our endpoint returns 10 records. To get the next 10 records, we can page through the result set by using the after parameter, which represents the last customer identifier seen. The server will skip through results until it finds that ID and returns results from the next customer onward.

We’ll add Next and Previous buttons that will help us move between search results. Clicking Next will take the ID of the last customer record currently shown on the page and send it as the after parameter to the next search request.

To support Previous, we’ll need to maintain a stack of after IDs that we can pop each time the user clicks Previous.

Adding a button to move to the next page

Let’s start with the Next button, which the user can click to bring them to the next page of results. Since we’re going to be dealing with multiple buttons on the screens, we’ll build a new buttonWithLabel helper that will match...

Filtering data

In this section, we’ll add a textbox that the user can use to filter names. Each character that the user types into the search field will cause a new fetch request to be made to the server. That request will contain the new search term as provided by the search box.

The /customers endpoint supports a parameter named searchTerm that filters search results using those terms, as shown in the following code snippet:

GET /customers?searchTerm=Dan
[
  {
    firstName: "Daniel",
    ...
  }
  ...
]

Let’s start by adding a text field into which the user can input a search term, as follows:

1. Add the following test to the CustomerSearch test suite, just below the last test. It simply checks for a new field:

   it("renders a text field for a search term", async () => {
     await renderAndWait(<CustomerSearch />);
     expect(element("...

Performing actions with render props

Each row of the table will hold a Create appointment action button. When the user has found the customer that they are searching for, they can press this button to navigate to the AppointmentForm component, creating an appointment for that customer.

We’ll display these actions by using a render prop that is passed to CustomerSearch. The parent component—in our case, App—uses this to insert its own rendering logic into the child component. App will pass a function that displays a button that causes a view transition in App itself.

Render props are useful if the child component should be unaware of the context it’s operating in, such as the workflow that App provides.

Unnecessarily complex code alert!

The implementation you’re about to see could be considered more complex than it needs to be. There are other approaches to solving this problem: you could simply have CustomerSearch render AppointmentFormLoader...

Summary

This chapter has explored building out a component with some complex user interactions between the user interface and an API. You’ve created a new table component and integrated it into the existing application workflow.

You have seen how to make large changes to your component’s implementation, using your tests as a safety mechanism.

You have also seen how to test render props using an additional render root—a technique that I hope you don’t have to use too often!

In the next chapter, we’ll use tests to integrate React Router into our application. We’ll continue with the CustomerSearch component by adding the ability to use the browser location bar to specify search criteria. That will set us up nicely for introducing Redux and GraphQL later on.

Exercises

1. Disable the Previous button if the user is on the first page and disable the Next button if the current listing has fewer than 10 records on display.
2. Extract the searchParams function into a separate module that handles any number of parameters and uses the encodeURIComponent JavaScript function to ensure the values are encoded correctly.
3. The /customers endpoint supports a limit parameter that allows you to specify the maximum number of records that are returned. Provide a mechanism for the user to change the limit on each page.