Getting Better All the Time - Tutorial

by Josh Justice

An extended version of the code exercise presented at React Native EU 2022.

The code for this tutorial is available in a GitHub repo if you'd like to follow along or play with it yourself.

The Story​

Say we have this screen that displays a list of restaurants from a server, and allows us to add a new restaurant to the list:

The server is a bit slow. When we add a restaurant, the Add button is visibly deactivated, showing us that the add is in progress:

But there is no corresponding loading state for the Delete buttons; while they run, they are still active.

Let's take a look at the code we have to work with. This'll take a little scrolling:

import {useState} from 'react';
import {
  FlatList,
  Pressable,
  StyleSheet,
  Text,
  TextInput,
  View,
} from 'react-native';
import api from './api';

export default function RestaurantList({
  restaurants,
  loading,
  loadError,
  reloadRestaurants,
}) {
  const [name, setName] = useState('');
  const [adding, setAdding] = useState(false);
  const [updateErrorMessage, setUpdateErrorMessage] = useState(null);

  if (loading) {
    return <Text style={styles.message}>Loading…</Text>;
  }

  if (loadError) {
    return (
      <Text style={[styles.message, styles.error]}>
        An error occurred while loading the restaurants
      </Text>
    );
  }

  return (
    <View style={styles.container}>
      <View style={styles.addRow}>
        <TextInput
          placeholder="New restaurant name"
          value={name}
          onChangeText={setName}
          style={styles.newRestaurantNameField}
        />
        <Pressable
          testID="add-button"
          disabled={adding}
          style={[styles.button, styles.addButton]}
          onPress={() => {
            setAdding(true);
            api
              .post('/restaurants', {name})
              .then(() => reloadRestaurants())
              .then(() => {
                setName('');
                setAdding(false);
              })
              .catch(() =>
                setUpdateErrorMessage(
                  'An error occurred adding the restaurant',
                ),
              );
          }}
        >
          <Text style={adding && styles.buttonTextDisabled}>
            {adding ? 'Adding…' : 'Add'}
          </Text>
        </Pressable>
      </View>
      {updateErrorMessage && (
        <Text style={[styles.message, styles.error]}>{updateErrorMessage}</Text>
      )}
      <FlatList
        data={restaurants}
        keyExtractor={item => item.id}
        renderItem={({item}) => (
          <View style={styles.restaurantRow}>
            <Text style={styles.restaurantName}>{item.name}</Text>
            <Pressable
              style={styles.button}
              onPress={() =>
                api
                  .delete(`/restaurants/${item.id}`)
                  .then(() => reloadRestaurants())
                  .catch(() =>
                    setUpdateErrorMessage(
                      'An error occurred deleting the restaurant',
                    ),
                  )
              }
            >
              <Text>Delete</Text>
            </Pressable>
          </View>
        )}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  button: {
    borderWidth: 1,
    borderColor: '#ccc',
    borderRadius: 6,
    alignItems: 'center',
    justifyContent: 'center',
    paddingHorizontal: 8,
    paddingVertical: 4,
    backgroundColor: '#eee',
  },
  buttonTextDisabled: {
    color: '#999',
  },
  container: {
    flex: 1,
  },
  addRow: {
    flexDirection: 'row',
    padding: 8,
  },
  newRestaurantNameField: {
    flex: 1,
    borderWidth: 1,
    borderColor: '#ccc',
    padding: 4,
  },
  addButton: {
    marginLeft: 8,
  },
  message: {
    fontSize: 18,
    padding: 8,
  },
  error: {
    color: 'red',
    fontSize: 18,
    padding: 8,
  },
  restaurantRow: {
    flexDirection: 'row',
    alignItems: 'center',
    borderBottomWidth: 1,
    borderColor: '#ccc',
    padding: 8,
  },
  restaurantName: {
    flex: 1,
    fontSize: 18,
  },
});

What do we think of this code? Here are some of my thoughts:

• There's a state item called name, but what name is that? We could guess it's the state of the new restaurant name text field but it's not obvious from the variable name.
• There's an updateErrorMessage state item, but it's not clear what it refers to. This screen doesn't really do any "updating", just "adding" and "deleting".
• The JSX structure is nested pretty deeply. Everything is using low-level RN core components, so you can't get a sense of higher-level concepts, even under the FlatList's inline renderItem prop function.
• There are multi-line logic functions directly in the JSX, including nontrivial Promise chains. This means that presentation and asynchronous business logic are mixed in one place, making it hard to parse. And let's assume my team has standardized on using async/await over Promise chains when possible; this makes it even less familiar for us.
• The FlatList's keyExtractor and renderItem functions both use item as an argument name, but it's not clear what an "item" is.
• There's a nontrivial amount of StyleSheet styles, because all of this screen's JSX tree is in this one file. This increases the effort it takes to find the styles that apply to a given component.

Now, we chose a file that is 150 lines long to make it manageable for a blog post. (it was already pretty long to scroll through!) A file of that length is probably manageable to figure out and work with it. But even in a file this short there are already all of the above problems. Think about when you've seen problems like these in files much longer. They can make the code very hard to work with, even to the point that you despair of ever fully understanding it.

Luckily, this screen is thoroughly covered by tests. That means we can make small changes to the code to make it better and easier to work with for our current story.

Refactoring​

The biggest thing that makes it hard for me to follow the logic of this component is the complex promise chains in the event handler props. Let's extract those arrow functions to variables.

We'll do one at a time. First, we'll copy the Add button function and assign it to a handleAdd variable declared inside the render function, then replace the prop with the handleAdd variable:

 export default function RestaurantList(...) {
...
+  const handleAdd = () => {
+    setAdding(true);
+    api
+      .post('/restaurants', {name})
+      .then(() => reloadRestaurants())
+      .then(() => {
+        setName('');
+        setAdding(false);
+      })
+      .catch(() =>
+        setUpdateErrorMessage(
+          'An error occurred adding the restaurant',
+        ),
+      );
+  }
...
   return (
...
     <Pressable
       testID="add-button"
       disabled={adding}
       style={[styles.button, styles.addButton]}
+      onPress={handleAdd}
-      onPress={() => {
-        setAdding(true);
-        api
-          .post('/restaurants', {name})
-          .then(() => reloadRestaurants())
-          .then(() => {
-            setName('');
-            setAdding(false);
-          })
-          .catch(() =>
-            setUpdateErrorMessage(
-              'An error occurred adding the restaurant',
-            ),
-          );
-        }}
       >
...
   );
 }

We save and the tests pass, giving us confidence we haven't broken anything.

Next, let's extract a handleDelete variable in the same way:

   const handleAdd = () => {
...
   };

+  const handleDelete = () =>
+    api
+      .delete(`/restaurants/${item.id}`)
+      .then(() => reloadRestaurants())
+      .catch(() =>
+        setUpdateErrorMessage(
+          'An error occurred deleting the restaurant',
+        ),
+      );
...
   return (
...
     <Pressable
       style={styles.button}
+      onPress={handleDelete}
-      onPress={() =>
-        api
-          .delete(`/restaurants/${item.id}`)
-          .then(() => reloadRestaurants())
-          .catch(() =>
-            setUpdateErrorMessage(
-              'An error occurred deleting the restaurant',
-            ),
-          )
-      }
    >
...
   );

When we save, both ESLint and our tests give us an error:

item is not defined

The reason for this is that item is a named argument passed to the renderItem callback passed to FlatList, and it doesn't exist at the top level of our render function. We can fix this quickly by explicitly passing item when we call handleDelete:

-  const handleDelete = () =>
+  const handleDelete = item =>
     api
       .delete(`/restaurants/${item.id}`)
...
   <Pressable
     style={styles.button}
-    onPress={handleDelete}
+    onPress={() => handleDelete(item)}
   >

We save, and the tests are back to passing again.

Next, say our team has standardized on using function-keyword functions instead of assigning arrow functions to constants. At first we assigned the arrow functions to constants because it was the smallest step we could take. And now we can change them to function declarations instead:

-const handleAdd = () => {
+function handleAdd() {}
   setAdding(true);
...
-};
+}
...
-const handleDelete = item =>
+function handleDelete(item) {
   api
     .delete(`/restaurants/${item.id}`)
...
+}

Again, we save after this small change and ensure the tests still pass. For the rest of this section of the tutorial, assume we save and rerun the tests after every change.

Say our team also has a convention of using async/await functions instead of Promise chains. These can be error-prone to rewrite, but with our test coverage we can do it safely. We'll change one at a time. First, handleAdd. The Promise implementation is:

function handleAdd() {
  setAdding(true);
  api
    .post('/restaurants', {name})
    .then(() => reloadRestaurants())
    .then(() => {
      setName('');
      setAdding(false);
    })
    .catch(() =>
      setUpdateErrorMessage('An error occurred adding the restaurant'),
    );
}

We replace it with this async/await implementation:

async function handleAdd() {
  try {
    setAdding(true);
    await api.post('/restaurants', {name});
    await reloadRestaurants();
    setName('');
    setAdding(false);
  } catch {
    setUpdateErrorMessage('An error occurred adding the restaurant');
  }
}

Next, handleDelete. We replace:

function handleDelete(item) {
  api
    .delete(`/restaurants/${item.id}`)
    .then(() => reloadRestaurants())
    .catch(() =>
      setUpdateErrorMessage('An error occurred deleting the restaurant'),
    );
}

with:

async function handleDelete(item) {
  try {
    await api.delete(`/restaurants/${item.id}`);
    await reloadRestaurants();
  } catch {
    setUpdateErrorMessage('An error occurred deleting the restaurant');
  }
}

Now, looking at handleDelete, I see another problem: the item variable name. What's an "item"? This screen doesn't work with "items"; it works with restaurants. We can rename that variable for clarity:

-async function handleDelete(item) {
+async function handleDelete(restaurant) {
   try {
-    await api.delete(`/restaurants/${item.id}`);
+    await api.delete(`/restaurants/${restaurant.id}`);
     await reloadRestaurants();
   } catch {
     setUpdateErrorMessage('An error occurred deleting the restaurant');
   }
 }

We can do the same for the keyExtractor and renderItem callbacks passed to the FlatList. Note that the argument passed to the latter is a named argument, which is probably where the name item came from, but we can still rename it:

 <FlatList
   data={restaurants}
-  keyExtractor={item => item.id}
-  renderItem={({item}) => (
+  keyExtractor={restaurant => restaurant.id}
+  renderItem={({item: restaurant}) => (
    <View style={styles.restaurantRow}>

Now, what other changes will help prepare us to add the loading state for the Delete button?

Right now, it's hard to add state for each Delete button, because each row is just some inline JSX in the renderItem callback. If we had a function for each row, that would give us a place to add the state.

Let's extract a new component for each row; we'll call it RestaurantRow. For convenience, we can declare it in the same file for now, underneath RestaurantList. We'll start by copying and pasting the JSX and letting ESLint tell us what props we need:

function RestaurantRow() {
  return (
    <View style={styles.restaurantRow}>
      <Text style={styles.restaurantName}>{restaurant.name}</Text>
      <Pressable style={styles.button} onPress={() => handleDelete(restaurant)}>
        <Text>Delete</Text>
      </Pressable>
    </View>
  );
}

The first prop we need is the restaurant, and that's easy to add:

-function RestaurantRow() {
+function RestaurantRow({restaurant}) {
   return (
...
   );
 }

The other variable that's missing is handleDelete. But let's think about the design of this component. Does it seem typical to pass a restaurant to the component, and also a function that receives that restaurant unchanged? No, it's more typical to have a function that is called without any arguments. Let's call it onDelete:

-function RestaurantRow({restaurant}) {
+function RestaurantRow({restaurant, onDelete}) {
   return (
...
-      <Pressable style={styles.button} onPress={() => handleDelete(restaurant)}>
+      <Pressable style={styles.button} onPress={onDelete}>
         <Text>Delete</Text>
       </Pressable>
...
   );
 }

That addresses all the undefined variables. Now we can replace the inline JSX with a call to the RestaurantRow component:

 <FlatList
   data={restaurants}
   keyExtractor={restaurant => restaurant.id}
   renderItem={({item: restaurant}) => (
+    <RestaurantRow
+      restaurant={restaurant}
+      onDelete={() => handleDelete(restaurant)}
+    />
-    <View style={styles.restaurantRow}>
-      <Text style={styles.restaurantName}>{restaurant.name}</Text>
-      <Pressable
-        style={styles.button}
-        onPress={() => handleDelete(restaurant)}
-      >
-        <Text>Delete</Text>
-      </Pressable>
-    </View>
   )}
 />

We've finished extracting the RestaurantRow component. This removes some low-level details from RestaurantList and lets it operate at a higher level of abstraction. But it still has some other low-level details: the "add restaurant" row. Should we extract that into a NewRestaurantForm child component now?

We can, but we don't have to. If it would help us now, we have the test coverage to extract that child component safely. Or if it's not too much work, we could go ahead and do it to simplify the code. But we don't directly need that component extracted for the feature we're working on right now. We could defer it until later; a future developer will have the same test coverage to use to extract it at that time. Something might even change by then that would affect exactly what we extract. So there are benefits to waiting to make changes until they're needed for our current story.

Back to our RestaurantRow component. Now that we have it, we have a convenient place to add a state indicating that a delete operation is in progress.

 function RestaurantRow({restaurant, onDelete}) {
+  const [deleting, setDeleting] = useState(false);
+
   return (
...
   );
 }

Now we can set the deleting state in a handleDelete function, and call that instead of calling onDelete directly:

 function RestaurantRow({restaurant, onDelete}) {
   const [deleting, setDeleting] = useState(false);

+  async function handleDelete() {
+    setDeleting(true);
+    await onDelete();
+    setDeleting(false);
+  }
+
   return (
...
-    <Pressable style={styles.button} onPress={onDelete}>
+    <Pressable style={styles.button} onPress={handleDelete}>
...
   );
 }

With this, we have a deleting boolean we can use to implement the deleting state of the Delete button. We'll do three things:

• Set the Pressable to disabled,
• Style the button's text to be grayed out, and
• Change the button's text to say "Deleting…"

 return (
   <View style={styles.restaurantRow}>
     <Text style={styles.restaurantName}>{restaurant.name}</Text>
-    <Pressable style={styles.button} onPress={handleDelete}>
+    <Pressable
+      disabled={deleting}
+      style={styles.button}
+      onPress={handleDelete}
+    >
-      <Text>Delete</Text>
+      <Text style={deleting && styles.buttonTextDisabled}>
+        {deleting ? 'Deleting…' : 'Delete'}
+      </Text>
     </Pressable>
   </View>
 );

With this, we should have our deleting button working. Let's try it in the simulator:

The deleting state looks great, but after the delete completes we get a warning:

Can't perform a React state update on an unmounted component.

This is caused by our call to setDeleting(false). This happens after the row has been deleted—but when it's deleted the row is removed. So we don't need to set deleting to false when the delete succeeds, but only when it fails. Let's do so:

 async function handleDelete() {
+  try {
     setDeleting(true);
     await onDelete();
+  } catch {
     setDeleting(false);
+  }
 }

With this, the warning goes away and the deleting state works great.

We were able to make these changes in small steps because we had good test coverage that gave us confidence to make those changes. But how can we get test coverage like that? Test-driven development.

Let's go back in time to before this screen was written and walk through the process of test-driving the functionality to get a test suite that thoroughly covers its functionality.

Test-Driving the Screen​

Let's say we're starting out with an empty RestaurantList component:

export default function RestaurantList() {
  return null;
}

We also have an empty test for the component:

describe('RestaurantList', () => {});

Now, what functionality do we need the component to have? Well, the main thing is displaying the passed-in restaurants. Let's write a test for that:

const restaurants = [
  {id: 1, name: 'Pizza Place'},
  {id: 2, name: 'Salad Place'},
];

describe('when restaurants are available', () => {
  it('displays the restaurant names', () => {
    render(<RestaurantList restaurants={restaurants} />);

    expect(screen.queryByText(restaurants[0].name)).toBeTruthy();
    expect(screen.queryByText(restaurants[1].name)).toBeTruthy();
  });
});

We set up some test restaurant data, then render the RestaurantList component, passing the restaurants to it. Then we check to make sure that each restaurant's name appears in the component tree.

We save the test and it fails, as we expect:

 FAIL  src/RestaurantList.spec.js
  RestaurantList
    when restaurants are available
      ✕ displays the restaurant names (179 ms)

  ● RestaurantList › when restaurants are available › displays the restaurant names

    expect(received).toBeTruthy()

    Received: null

      12 |       render(<RestaurantList restaurants={restaurants} />);
      13 |
    > 14 |       expect(screen.queryByText(restaurants[0].name)).toBeTruthy();
         |                                                       ^

To make this test pass, let's output the restaurant names. Now, the simplest way we could implement this would be plain Text elements. But because this is React Native, we know we're going to be using a FlatList or something like it. We can go ahead and use the FlatList now; even if we change our minds later, our tests will support us as we change the implementation:

+import {FlatList, Text} from 'react-native';
+
-export default function RestaurantList() {
+export default function RestaurantList({restaurants}) {
-  return null;
+  return (
+    <FlatList
+      data={restaurants}
+      keyExtractor={item => item.id}
+      renderItem={({item}) => <Text>{item.name}</Text>}
+    />
+  );
 }

Save and the tests pass.

At this point we could refactor by styling the component, but let's hold off on doing so until we have more functionality.

What's a good next bit of functionality to add? The error message would be a good choice. Let's add a test for that. Add the following inside describe('RestaurantList', …), after the "when restaurants are available" block:

describe('when there is a load error', () => {
  it('displays an error message', () => {
    render(<RestaurantList loadError />);

    expect(
      screen.queryByText('An error occurred while loading the restaurants'),
    ).toBeTruthy();
  });
});

We pass a loadError prop; because we don't give it a value it will set the prop to true. We decide on the error message we want to see, and we look for it.

The test fails. Now, what's the simplest way we can make it pass? We can add the text directly into the rendered JSX:

 return (
+  <>
+    <Text>An error occurred while loading the restaurants</Text>
     <FlatList
       data={restaurants}
       keyExtractor={restaurant => restaurant.id}
       renderItem={({item: restaurant}) => <Text>{restaurant.name}</Text>}
     />
+  </>
 );

Save and the tests pass.

Now, this may be frustrating to you to see this. It may be obvious to you that we don't want to unconditionally show the error message, so why would we write it this way?

Yes, we want to conditionally hide the error message, but we also want tests that force us to do so. So rather than adding that logic right away, we'll add a test that forces us to implement the logic we want to have. What test will do that? When do we not want the error message to display?

We don't want the error message to display when the restaurants are successfully loaded. So let's add an assertion to the "when restaurants are available" test:

 describe('when restaurants are available', () => {
   it('displays the restaurant names', () => {
     render(<RestaurantList restaurants={restaurants} />);

     expect(screen.queryByText(restaurants[0].name)).toBeTruthy();
     expect(screen.queryByText(restaurants[1].name)).toBeTruthy();
+
+    expect(
+      screen.queryByText('An error occurred while loading the restaurants'),
+    ).toBeNull();
   });
 });

The test fails; now we will need to implement the logic to hide the error message to make it pass:

-export default function RestaurantList({restaurants}) {
+export default function RestaurantList({restaurants, loadError}) {
+  if (loadError) {
+    return <Text>An error occurred while loading the restaurants</Text>;
+  }
+
  return (
    <>
-     <Text>An error occurred while loading the restaurants</Text>
      <FlatList
        data={restaurants}
        keyExtractor={restaurant => restaurant.id}
        renderItem={({item: restaurant}) => <Text>{restaurant.name}</Text>}
      />
    </>
  );
}

So far we haven't done the "refactoring" step of red-green-refactor, but now something is jumping out at me: the duplicated error message string in the two tests. I'm worried that the two tests might get out of sync and lead to false positives or false negatives. For example, say I changed the error message to "LOAD ERROR!!!" but I only updated it in the error-state test. The test "when restaurants are available" would still be checking for the old error message, and it would still pass, but for the wrong reason: it would pass because that message is never shown. This means it wouldn't actually be protecting us: if we accidentally did show the error message in that case, the test would still pass, giving us a false positive.

How can we prevent these tests from getting out of sync? We can refactor by extracting the error message string to a constant:

 describe('RestaurantList', () => {
   const restaurants = [
     {id: 1, name: 'Pizza Place'},
     {id: 2, name: 'Salad Place'},
   ];
+  const loadErrorMessage = 'An error occurred while loading the restaurants';

   describe('when restaurants are available', () => {
...
-     expect(
-       screen.queryByText('An error occurred while loading the restaurants'),
-     ).toBeNull();
+     expect(screen.queryByText(loadErrorMessage)).toBeNull();
...
  });

  describe('when there is a load error', () => {
...
-     expect(
-       screen.queryByText('An error occurred while loading the restaurants'),
-     ).toBeTruthy();
+     expect(screen.queryByText(loadErrorMessage)).toBeTruthy();
...
  });

Save and the tests will still pass. But now they should be more robust against future change.

What is a good next bit of functionality to add? The loading message. Now, in your app you might use an animated loading indicator of some type, which you could look up in the test via an accessibility label. But for simplicity in this tutorial we'll use another textual message.

Let's start with a test for when the loading message should appear. Since we extracted the error message to a constant, we can foresee that we'll need to reuse the loading message too, so we can go ahead and define it in a constant:

const loadingMessage = 'Loading…';

describe('while loading', () => {
  it('displays a loading indicator', () => {
    render(<RestaurantList loading />);

    expect(screen.queryByText(loadingMessage)).toBeTruthy();
  });
});

Make this test pass in the simplest way possible by adding the loading message unconditionally to the default returned JSX:

 return (
   <>
+    <Text>Loading…</Text>
     <FlatList
       data={restaurants}
       keyExtractor={restaurant => restaurant.id}
       renderItem={({item: restaurant}) => <Text>{restaurant.name}</Text>}
     />
   </>
 );

Now, in what scenarios would we not want to display the loading indicator? For one, once the restaurants have successfully been loaded. Let's add an assertion that will fail to that test:

 describe('when restaurants are available', () => {
   it('displays the restaurant names', () => {
     render(<RestaurantList restaurants={restaurants} />);

     expect(screen.queryByText(restaurants[0].name)).toBeTruthy();
     expect(screen.queryByText(restaurants[1].name)).toBeTruthy();

+    expect(screen.queryByText(loadingMessage)).toBeNull();
     expect(screen.queryByText(loadErrorMessage)).toBeNull();
   });
 });

We can make this test pass by moving the loading message to an early return, like we did with the error message:

-export default function RestaurantList({restaurants, loadError}) {
+export default function RestaurantList({restaurants, loading, loadError}) {
+  if (loading) {
+    return <Text>Loading…</Text>;
+  }
+
   if (loadError) {
     return <Text>An error occurred while loading the restaurants</Text>;
   }

   return (
     <>
-      <Text>Loading…</Text>
       <FlatList

Looking at our test file, we see we also have a test for when there is a load error. That's another scenario when we don't want to display the loading error message. Let's add an assertion to that effect:

 describe('when there is a load error', () => {
   it('displays an error message', () => {
     render(<RestaurantList loadError />);

     expect(screen.queryByText(loadErrorMessage)).toBeTruthy();
+
+    expect(screen.queryByText(loadingMessage)).toBeNull();
   });
 });

This test actually passes right away, because the conditional logic we added already handles this scenario. So this step wasn't actually test-driven development: we did not first add a failing test. That's okay, though: this is still valuable to add specification of the functionality of the component, to ensure we don't break it in the future.

Let's take a break from test-driving to run our app in the simulator. The loading indicator works and the data is displayed. It could really use some styling, though. As a refactoring step, let's add some styling. Add the following StyleSheet to the bottom of the file:

const styles = StyleSheet.create({
  message: {
    fontSize: 18,
    padding: 8,
  },
  error: {
    color: 'red',
    fontSize: 18,
    padding: 8,
  },
  restaurantRow: {
    borderBottomWidth: 1,
    borderColor: '#ccc',
    padding: 8,
  },
  restaurantName: {
    fontSize: 18,
  },
});

Then add these styles to components throughout your JSX:

-import {FlatList, Text} from 'react-native';
+import {FlatList, Text, StyleSheet, View} from 'react-native';

 export default function RestaurantList({restaurants, loading, loadError}) {
   if (loading) {
-    return <Text>Loading…</Text>;
+    return <Text style={styles.message}>Loading…</Text>;
   }

   if (loadError) {
-    return <Text>An error occurred while loading the restaurants</Text>;
+    return (
+      <Text style={[styles.message, styles.error]}>
+        An error occurred while loading the restaurants
+      </Text>
+    );
   }

   return (
     <FlatList
       data={restaurants}
       keyExtractor={restaurant => restaurant.id}
-      renderItem={({item: restaurant}) => <Text>{restaurant.name}</Text>}
+      renderItem={({item: restaurant}) => (
+        <View style={styles.restaurantRow}>
+          <Text style={styles.restaurantName}>{restaurant.name}</Text>
+        </View>
+      )}
     />
    </View>
   );
 }

Check your updates in the simulator; it's nothing fancy but it looks usable at least. And you can always change the styling later with the tests giving you confidence that you haven't broken anything.

Now let's move on to test-driving the ability to add a restaurant. Let's start by adding the steps to add the restaurant and get the test passing, then after that we'll figure out what assertions to add:

describe('when adding a restaurant succeeds', () => {
  const name = 'Burger Place';

  it('TBD', () => {
    render(<RestaurantList restaurants={[]} />);

    fireEvent.changeText(
      screen.getByPlaceholderText('New restaurant name'),
      name,
    );
    fireEvent.press(screen.getByText('Add'));
  });
});

Because we're using fireEvent for the first time, we need to import it:

-import {render, screen} from '@testing-library/react-native';
+import {fireEvent, render, screen} from '@testing-library/react-native';
 import RestaurantList from './RestaurantList';

We render the RestaurantList component. We want it to be in the state where the restaurants have already been loaded, but we don't need any restaurants to be present, so we can just pass an empty array as the restaurants prop.

Next, we fill in a text field with the new restaurant name. We find the text field by the placeholder that will display for the user.

Finally, we press/tap a button labeled "Add".

Save, and we get a failure:

Unable to find an element with placeholder: New restaurant name

We make just enough of a change to the production code to get past the current error or failure. In this case, we add a TextInput with the expected placeholder:

-import {FlatList, StyleSheet, Text, View} from 'react-native';
+import {FlatList, StyleSheet, Text, TextInput, View} from 'react-native';
...
 return (
   <>
+    <TextInput placeholder="New restaurant name" />
     <FlatList

Save, and we get a different test failure:

Unable to find an element with text: Add

Add an "Add" button:

-import {FlatList, StyleSheet, Text, TextInput, View} from 'react-native';
+import {
+  FlatList,
+  Pressable,
+  StyleSheet,
+  Text,
+  TextInput,
+  View,
+} from 'react-native';
...
 return (
   <>
     <TextInput placeholder="New restaurant name" />
+    <Pressable>
+      <Text>Add</Text>
+    </Pressable>
     <FlatList

Save and the tests pass. Note that we aren't hooking up the TextInput to state storage or the Pressable to a press handler yet: we'll wait for the test to drive us to implement that.

We're now doing all the interactions that should be necessary to add a restaurant. What expectations do we want to make about the result?

The most important thing we want to confirm is that the request is made to the server to add the restaurant. We have an api module that handles calls to the server, and we want to make that call directly in the component. We can assert that api.post() is called using Jest module mocking:

 import RestaurantList from './RestaurantList';
+import api from './api';
+
+jest.mock('./api');

 describe('RestaurantList', () => {
...
   describe('when adding a restaurant succeeds', () => {
     const name = 'Burger Place';

-    it('TBD', () => {
+    it('saves the restaurant to the server', () => {
       render(<RestaurantList restaurants={[]} />);

       fireEvent.changeText(
         screen.getByPlaceholderText('New restaurant name'),
         name,
       );
       fireEvent.press(screen.getByText('Add'));
+
+      expect(api.post).toHaveBeenCalledWith('/restaurants', {name});
     });
   });

To pass the test, we need to store the value of the TextInput in state so it's available to pass to the api.post() method:

+import {useState} from 'react';
 import {
   FlatList,
   Pressable,
   StyleSheet,
   Text,
   TextInput,
   View,
 } from 'react-native';
+import api from './api';

 export default function RestaurantList({restaurants, loading, loadError}) {
+  const [name, setName] = useState('');

   if (loading) {
...
   return (
     <>
-     <TextInput placeholder="New restaurant name" />
+     <TextInput
+       placeholder="New restaurant name"
+       value={name}
+       onChangeText={setName}
+     />
-     <Pressable>
+     <Pressable onPress={() => api.post('/restaurants', {name})}>
        <Text>Add</Text>
      </Pressable>

What else do we want to happen when we add a restaurant? Well, the way our app is implemented, instead of manually adding the restaurant to a locally-cached restaurant list, we reload the full restaurant list from the server, using a function passed in from the parent component. Let's assert that now. Because we will not reload until after the save to the server completes, we will need to change our test to an async test:

-import {fireEvent, render, screen, waitFor} from '@testing-library/react-native';
+import {
+  fireEvent,
+  render,
+  screen,
+  waitFor,
+} from '@testing-library/react-native';
...
-it('saves the restaurant to the server', () => {
-  render(<RestaurantList restaurants={[]} />);
+it('saves the restaurant to the server', async () => {
+  const reloadRestaurants = jest.fn().mockName('reloadRestaurants');
+
+  render(
+    <RestaurantList
+      restaurants={[]}
+      reloadRestaurants={reloadRestaurants}
+    />,
+  );

   fireEvent.changeText(
     screen.getByPlaceholderText('New restaurant name'),
     name,
   );
   fireEvent.press(screen.getByText('Add'));

   expect(api.post).toHaveBeenCalledWith('/restaurants', {name});
+
+  await waitFor(() => expect(reloadRestaurants).toHaveBeenCalledWith());
 });

We create a Jest mock function called reloadRestaurants, then we pass it as a prop to the RestaurantList. Then, after we confirm the restaurant has been added to the server, we confirm that reloadRestaurants has been called. This won't happen right away, but only after the call to the server returns. So we need to wrap this assertion in a call to waitFor(), which will retry the check repeatedly over the range of a few seconds. Also, we use the more specific .toHaveBeenCalledWith() method, not passing any arguments, to confirm that reloadRestaurants is called with no arguments. This ensures we don't accidentally pass it some data that could be confusing to future developers.

We should be able to get the test to pass by taking in the reloadRestaurants prop and calling it in a .then() callback:

-export default function RestaurantList({restaurants, loading, loadError}) {
+export default function RestaurantList({
+  restaurants,
+  loading,
+  loadError,
+  reloadRestaurants,
+}) {
   const [name, setName] = useState('');
...
-      <Pressable onPress={() => api.post('/restaurants', {name})}>
+      <Pressable
+        onPress={() =>
+          api.post('/restaurants', {name}).then(() => reloadRestaurants())
+        }
+      >
         <Text>Add</Text>
       </Pressable>

Save the file, but we get a surprising error in the production code:

TypeError: Cannot read properties of undefined (reading 'then')

  39 |       <Pressable
  40 |         onPress={() =>
> 41 |           api.post('/restaurants', {name}).then(() => reloadRestaurants())
     |           ^

Because we mocked the api module, api.post() returns a value of undefined by default. To get it to simulate a successful web service call, we need to configure it to return a Promise that resolves. Jest mocks have a simple API for this:

 it('saves the restaurant to the server', async () => {
+  api.post.mockResolvedValue();
+
   const reloadRestaurants = jest.fn().mockName('reloadRestaurants');

Save and the test passes.

Now, in a typical TDD process, you might identify that the promise chain in the onPress prop is getting complex, and would be good to refactor out into a standalone function. But remember that we're traveling back through time, and we don't want to change the future. Let's leave the code as-is, assuming that we didn't think to do this refactoring right now.

OK so, when we add a restaurant, the restaurant is sent to the server and the list is reloaded. Is there anything else we want to happen? Well, after all this succeeds, it would be good to clear out the TextInput so it's ready to add the next restaurant. Let's add an assertion to that effect:

 it('saves the restaurant to the server', async () => {
   api.post.mockResolvedValue();

   const reloadRestaurants = jest
     .fn()
-    .mockName('reloadRestaurants');
+    .mockName('reloadRestaurants')
+    .mockResolvedValue();
...
   await waitFor(() => expect(reloadRestaurants).toHaveBeenCalledWith());
+
+  expect(screen.getByPlaceholderText('New restaurant name')).toHaveProp(
+    'value',
+    '',
+  );
 });

We ensure reloadRestaurants returns a Promise that resolves, so that the result will be executed asynchronously. This makes our test more realistic to what will really happen. Then we assert that the TextInput should have a value of empty string, showing that its text was cleared.

We should be able to get this to pass by clearing the name in another .then() callback:

 <Pressable
   onPress={() =>
-    api.post('/restaurants', {name}).then(() => reloadRestaurants())
+    api
+      .post('/restaurants', {name})
+      .then(() => reloadRestaurants())
+      .then(() => setName(''))
   }
 >

Save and the test passes.

Next, let's test-drive the case when adding a restaurant fails. In that case, we want to show an error message:

describe('when adding a restaurant fails', () => {
  it('shows an error message', async () => {
    api.post.mockRejectedValue();

    render(<RestaurantList restaurants={[]} />);

    fireEvent.changeText(
      screen.getByPlaceholderText('New restaurant name'),
      'Burger Place',
    );
    fireEvent.press(screen.getByText('Add'));

    await screen.findByText('An error occurred adding the restaurant');
  });
});

We configure the api.post method to return a Promise that rejects by calling .mockRejectedValue(); this simulates a server failure. After we go through the steps to add the restaurant, we wait for an error message to appear on the screen.

Save and we get the error:

thrown: undefined

To do the minimum to get past the current error, let's just catch that thrown error:

 <Pressable
   onPress={() =>
     api
       .post('/restaurants', {name})
       .then(() => reloadRestaurants())
       .then(() => setName(''))
+      .catch(() => {})
   }
 >

Save and now we get an assertion failure:

Unable to find an element with text: An error occurred adding the restaurant

To implement this, we can add a state variable storing the error. Thinking ahead to the fact that we will need to report delete errors too, let's have a single updateErrorMessage field that stores the error message for either update action:

 export default function RestaurantList({
   restaurants,
   loading,
   loadError,
   reloadRestaurants,
 }) {
   const [name, setName] = useState('');
+  const [updateErrorMessage, setUpdateErrorMessage] = useState(null);

   if (loading) {
...
       <Pressable
         onPress={() =>
           api
             .post('/restaurants', {name})
             .then(() => reloadRestaurants())
             .then(() => setName(''))
-            .catch(() => {})
+            .catch(() =>
+              setUpdateErrorMessage('An error occurred adding the restaurant'),
+            )
         }
       >
...
       <Text>Add</Text>
     </Pressable>
+    {updateErrorMessage && <Text>{updateErrorMessage}</Text>}
     <FlatList

Save and the test passes.

We need to add the disabled Add button state, but before we do so, let's go on to add the Delete functionality. We can circle back to the more sophisticated disabled button state afterward.

Deleting is fairly similar to adding, so we can write the test all in one go:

describe('when deleting a restaurant succeeds', () => {
  it('deletes the restaurant from the server', async () => {
    api.delete.mockResolvedValue();

    const reloadRestaurants = jest.fn().mockName('reloadRestaurants');

    render(
      <RestaurantList
        restaurants={restaurants}
        reloadRestaurants={reloadRestaurants}
      />,
    );

    fireEvent.press(screen.getAllByText('Delete')[0]);

    expect(api.delete).toHaveBeenCalledWith(
      `/restaurants/${restaurants[0].id}`,
    );

    await waitFor(() => expect(reloadRestaurants).toHaveBeenCalledWith());
  });
});

We will be calling the api.delete() method to make the call to the server, so we mock it to resolve. We set up a reloadRestaurants mock function again. Then we render RestaurantList. This time we need to pass some restaurants so we have one available to delete. We tap the first Delete button we see, then confirm that a request was made to the server to delete the correct restaurant, and then that the restaurants are reloaded.

Let's continue to follow the practice of fixing one test failure at a time. First we have:

Unable to find an element with text: Delete

We fix this by adding a Pressable labeled "Delete" in the restaurant row:

 <View style={styles.restaurantRow}>
   <Text style={styles.restaurantName}>{restaurant.name}</Text>
+  <Pressable>
+    <Text>Delete</Text>
+  </Pressable>
 </View>

Next we get a failure saying that api.delete was not called. This is easy enough to fix:

-<Pressable>
+<Pressable
+  onPress={() => api.delete(`/restaurants/${restaurant.id}`)}
+>
   <Text>Delete</Text>
 </Pressable>

The next failure we get is that reloadRestaurants was not called. We can chain that again:

 <Pressable
-  onPress={() => api.delete(`/restaurants/${restaurant.id}`)}
+  onPress={() =>
+    api
+      .delete(`/restaurants/${restaurant.id}`)
+      .then(() => reloadRestaurants())
+  }
 >

Save and the test passes.

Now, let's test deletion failure:

describe('when deleting a restaurant fails', () => {
  it('shows an error message', async () => {
    api.delete.mockRejectedValue();

    render(<RestaurantList restaurants={restaurants} />);

    fireEvent.press(screen.getAllByText('Delete')[0]);

    await screen.findByText('An error occurred deleting the restaurant');
  });
});

The first error we get is thrown: undefined again, so let's catch it:

 <Pressable
   onPress={() =>
     api
       .delete(`/restaurants/${restaurant.id}`)
       .then(() => reloadRestaurants())
+      .catch(() => {})
   }
 >

Next we get a failure that the error message isn't shown. That's easy to add with our updateErrorMessage state:

 onPress={() =>
   api
     .delete(`/restaurants/${restaurant.id}`)
     .then(() => reloadRestaurants())
-    .catch(() => {})
+    .catch(() =>
+      setUpdateErrorMessage('An error occurred deleting the restaurant'),
+     )
 }

With deleting handled, let's circle back to adding the loading state to the Add button. What do we want to assert about it? We shouldn't assert on visual styling in our tests, but we can confirm that the button's label is changed to "Adding…" and that it is disabled:

 describe('when adding a restaurant succeeds', () => {
   const name = 'Burger Place';
+  const addingLabel = 'Adding…';

   it('saves the restaurant to the server', async () => {
     api.post.mockResolvedValue();

     const reloadRestaurants = jest
       .fn()
       .mockName('reloadRestaurants')
       .mockResolvedValue();

     render(
       <RestaurantList
         restaurants={[]}
         reloadRestaurants={reloadRestaurants}
       />,
     );

     fireEvent.changeText(
       screen.getByPlaceholderText('New restaurant name'),
       name,
     );
     fireEvent.press(screen.getByText('Add'));

+    expect(screen.queryByText(addingLabel)).toBeTruthy();
+    expect(screen.getByTestId('add-button')).toHaveProp(
+      'accessibilityState',
+      {disabled: true},
+    );

     expect(api.post).toHaveBeenCalledWith('/restaurants', {name});

     await waitFor(() => expect(reloadRestaurants).toHaveBeenCalledWith());

     expect(screen.getByPlaceholderText('New restaurant  name')).toHaveProp(
       'value',
       '',
     );
+    expect(screen.queryByText(addingLabel)).toBeNull();
+    expect(screen.getByTestId('add-button')).toHaveProp(
+      'accessibilityState',
+      {disabled: false},
+    );
   });
 });

We put the "Adding…" label into a variable because we'll be checking for it several times. The first failure we get is that the adding label wasn't found. We can fix this with an adding state value that we set to true when adding begins:

 const [name, setName] = useState('');
+const [adding, setAdding] = useState(false);
 const [updateErrorMessage, setUpdateErrorMessage] = useState(null);
...
     <Pressable
-      onPress={() =>
+      onPress={() => {
+        setAdding(true);
         api
           .post('/restaurants', {name})
           .then(() => reloadRestaurants())
           .then(() => setName(''))
           .catch(() =>
             setUpdateError('An error occurred adding the restaurant'),
-          )
-      }
+          );
+      }}
     >
-      <Text>Add</Text>
+      <Text>{adding ? 'Adding…' : 'Add'}</Text>
     </Pressable>

Save and we get a new error: we can't find an element with test ID add-button. Because we need to look up the Pressable itself instead of text on it, we need a test ID to reference it directly. Fix just this error by adding that test ID:

 <Pressable
+  testID="add-button"
   onPress={() => {

Save and we get the failure:

Expected the element to have prop:
  accessibilityState={"disabled": true}
Received:
  null

You might think that the simplest way to fix this failure is to hard-code the disabled prop. But this won't actually work in this case because RNTL won't call the onPress function for a disabled button. So we need to go ahead and implement the disabled prop conditionally:

 <Pressable
   testID="add-button"
+  disabled={adding}
   onPress={() => {
 }

Now we get a failure on the expectation:

expect(screen.queryByText(addingLabel)).toBeNull();

To get the "Adding…" label to disappear, set adding back to false after success:

 api
   .post('/restaurants', {name})
   .then(() => reloadRestaurants())
-  .then(() => setName(''))
+  .then(() => {
+    setAdding(false);
+    setName('');
+   })
   .catch(() =>
     setUpdateError('An error occurred adding the restaurant'),
   );

Now the test passes. The check to confirm that disabled is false passes because setting adding to false is already configured to affect not only the label but also the disabled state.

Now that we've finished all this functionality, let's check it out in the simulator again. We could once again use some more styling. Let's add more styles:

 const styles = StyleSheet.create({
+  button: {
+    borderWidth: 1,
+    borderColor: '#ccc',
+    borderRadius: 6,
+    alignItems: 'center',
+    justifyContent: 'center',
+    paddingHorizontal: 8,
+    paddingVertical: 4,
+    backgroundColor: '#eee',
+  },
+  buttonTextDisabled: {
+    color: '#999',
+  },
+  container: {
+    flex: 1,
+  },
+  addRow: {
+    flexDirection: 'row',
+    padding: 8,
+  },
+  newRestaurantNameField: {
+    flex: 1,
+    borderWidth: 1,
+    borderColor: '#ccc',
+    padding: 4,
+  },
+  addButton: {
+    marginLeft: 8,
+  },
   message: {

Then update the JSX to use them:

 return (
-  <>
+  <View style={styles.container}>
+    <View style={styles.addRow}>
       <TextInput
         placeholder="New restaurant name"
         value={name}
         onChangeText={setName}
+        style={styles.newRestaurantNameField}
       />
       <Pressable
         testID="add-button"
         disabled={adding}
+        style={[styles.button, styles.addButton]}
         onPress={() => {
           setAdding(true);
           api
             .post('/restaurants', {name})
             .then(() => reloadRestaurants())
             .then(() => {
               setAdding(false);
               setName('');
             })
             .catch(() =>
               setUpdateErrorMessage(
                 'An error occurred adding the restaurant',
               ),
             );
         }}
       >
-       <Text>{adding ? 'Adding…' : 'Add'}</RestaurantList>Text>
+       <Text style={adding && styles.buttonTextDisabled}>
+          {adding ? 'Adding…' : 'Add'}
+        </Text>
       </Pressable>
+    </View>
-    {updateErrorMessage && <Text>{updateErrorMessage}</Text>}
+    {updateErrorMessage && (
+      <Text style={[styles.message, styles.error]}>{updateErrorMessage}</Text>
+    )}
     <FlatList
       data={restaurants}
       keyExtractor={restaurant => restaurant.id}
       renderItem={({item: restaurant}) => (
         <View style={styles.restaurantRow}>
           <Text style={styles.restaurantName}>{restaurant.name}</Text>
           <Pressable
+            style={styles.button}
             onPress={() =>
               api
                 .delete(`/restaurants/${restaurant.id}`)
                 .then(() => reloadRestaurants())
                 .catch(() =>
                   setUpdateErrorMessage(
                     'An error occurred deleting the restaurant',
                   ),
                 )
             }
           >
             <Text>Delete</Text>
           </Pressable>
         </View>
       )}
     />
-  </>
+  </View>
 );

More Test Coverage​

Now that we've seen the benefits of refactoring and how to TDD to get there, let's explore this codebase a bit more.

First, let's add a test for that new Delete loading state we just added.

Like with our Add test, after we click the button we'll confirm that it is disabled and gets the new loading-state label:

 describe('when deleting a restaurant succeeds', () => {
   it('deletes the restaurant from the server', async () => {
...
     fireEvent.press(screen.getAllByText('Delete')[0]);

+    expect(screen.queryByText('Deleting…')).toBeTruthy();
+    expect(screen.getAllByTestId('delete-button')[0]).toHaveProp(
+      'accessibilityState',
+      {disabled: true},
+    );

     expect(api.delete).toHaveBeenCalledWith(
       `/restaurants/${restaurants[0].id}`,
     );

Unlike with our Add test, though, we won't test for the state to change back after success; we removed that functionality when we saw it wasn't needed and caused an error updating an unmounted component.

Save and the test fails because there is no JSX element with test ID delete-button. Add that to the delete Pressable:

 <Pressable
+  testID="delete-button"
   disabled={deleting}
   style={styles.button}
   onPress={handleDelete}
 >

Save and the test passes.

Now let's test the loading state for delete failure. In this case we do need to confirm that the button is reactivated:

 describe('when deleting a restaurant fails', () => {
   it('shows an error message', async () => {
...
     fireEvent.press(screen.getAllByText('Delete')[0]);

+    expect(screen.queryByText('Deleting…')).toBeTruthy();
+    expect(screen.getAllByTestId('delete-button')[0]).toHaveProp(
+      'accessibilityState',
+      {disabled: true},
+    );

     await screen.findByText('An error occurred deleting the restaurant');

+    expect(screen.queryByText('Deleting…')).toBeNull();
+    expect(screen.getAllByTestId('delete-button')[0]).toHaveProp(
+      'accessibilityState',
+      {disabled: false},
+    );
   });
 });