As users interact with web applications, they trigger events like clicking buttons, submitting forms, or typing text that we need to respond to. Let’s explore a common example: searching.

<label>
  <input type="search" id="q" name="q" placeholder="Search term" /> 🔍
</label>

When a user types text into a search box, we want to capture their input and use it to filter and redisplay search results. This means the state of the application changes as the user types. We need to react to this change by updating the UI.

We’ll explore these ideas today. Code along with the examples in this lesson.

Let’s think through building this film search interface step-by-step. Write down your sequence of steps to build this interface.

Given a view of film cards and search box
When a user types in the search box
Then the view should update to show only matching films

graph LR
A[Render UI] --> B[User types]
B --> C[Capture event]
C --> D[Filter data]
D --> E[Update state]
E --> A

The key aspects we need to handle are capturing input and updating UI.

👂🏿 Capturing Input

We need to listen for the input event on the search box to react as the user types. When the event fires, we can read the updated string value from the search box input element.

🎬 Filtering Data

Once we have the latest search text, we can filter the list of films. We can use JavaScript array methods like .filter() to return films that match our search string.

🆕 Updating UI

With the latest filtered list of films in hand, we re-render these films to display the updated search results. We can clear the current film list and map over the filtered films to add updated DOM elements.

Thinking through these aspects separately helps frame the overall task. Next we can focus on each piece:

1. 👂🏿 Listening for input
2. 🎬 Filtering data
3. 🆕 Re-rendering UI with the films example.

💭 Why clear out the list and make new elements?

We could go through the existing elements, and change them. We could add a hidden CSS class to ones we want to hide, and remove a hidden CSS class from those we want to show.

But we prefer to clear out the list and make new elements. We do not want to change existing ones.

🧘🏽‍♂️ Do the simplest thing

It is simpler because we have fewer things to think about. With either approach, we need to solve the problem “which films do we want to show”. By clearing out elements, we then only have to solve the problem “how do I display a film?”. We don’t also need to think about “how do I hide a film?” or “how do I show a film that was hidden?”.

🍱 A place for everything

In our pattern we only deal with how we turn data into a card in one place. If we need to worry about changing how a card is displayed, that would have to happen somewhere else.

By making new cards, we avoid thinking about how cards change.

We can focus.

🕞 State: data which may change over time.

We store each piece of state in a variable. When we render in the UI, our code will look at the state in those variables. When the state changes, we render our UI again based on the new state.

“What the state used to be” or “How the state changed” isn’t something we pay attention to when we render. We always render based only on the current state.

We want to have as few pieces of state as possible. We want them to be fundamental.

Some guidelines for identifying the state for a problem:

✔️ If something can change it should be state.

In our film example, the search term can change, so it needs some state associated with it.

❌ But if something can be derived it should not be state.

In our film example, we would not store “is the search term empty” and “what is the search term” as separate pieces of state. We can work this answer out ourselves. This answer can be derived. We can answer the question “is the search term empty” by looking at the search term. We don’t need two variables: we can use one.

🖇️ If two things always change together, they should be one piece of state.

If our website had light mode and dark mode, we would not have one state for “is dark mode enabled” and one state for “is light mode enabled”. We would have one piece of state: a boolean 🧶 🧶 boolean true or false. On or off.

In our film example, we need two pieces of state:

1. Our list of all films
2. The search term

When we introduce filtering films based on the search term we will not introduce new state. Our filtered list of films can be derived from our existing state.

We are going to introduce a common pattern in writing UIs, which is to use a function called render.

Up until now, our film website has been static: it never changes. By introducing a search input, our website is becoming dynamic: it can change. This means that we may need to re-run the code which creates our UI elements.

So before we add the new functionality to our website, we are going to refactor 🧶 🧶 refactor Refactoring is when we change how our code is structured, without changing what it does. Even though we have changed our code, it does exactly the same thing it did before. . Find your code from last week that creates the film cards and adds them to the page. Move your code into a function called render:

const films = [
  // You have this array from last time.
];

function createFilmCard(filmData) {
  // You should have an implementation of this function from last time.
}

function render() {
  const filmCards = films.map(createFilmCard);
  document.body.append(...filmCards);
}

We’re missing one thing: We’re never calling our render function! Call your render function after you define it:

const films = [
  // You have this array from last week.
];

function createFilmCard(filmData) {
  // You should have an implementation of this function from last week.
}

function render() {
  const filmCards = films.map(createFilmCard);
  document.body.append(...filmCards);
}

render();

Your application should now work exactly the same as it did before. Because we moved our code into a function, this means we can call that function again if we need to, for instance when someone searches for something.

Storing our state somewhere

Up until now, we had a variable called films, and we created some cards based on that variable.

Let’s move this films variable inside an object called state, to make it clear to us what the state is in our application.

const state = {
  films: [
    {
      title: "Killing of Flower Moon",
      director: "Martin Scorsese",
      times: ["15:35"],
      certificate: "15",
      duration: 112,
    },
    {
      title: "Typist Artist Pirate King",
      director: "Carol Morley",
      times: ["15:00", "20:00"],
      certificate: "12A",
      duration: 108,
    },
  ],
};

Each time we need to store more information we should think: Is this a piece of state, or is this something we’re deriving from existing state? Whenever something in our state changes, we will tell our UI just to show “whatever is in the state” by calling the render function. In this way, we simplify our UI code by making it a function of the state.

This is another refactoring: we didn’t change what our application does, we just moved a variable.

We are introducing a new feature: being able to search for films. We have identified that this introduces one new element of state: the search term someone has asked for.

Let’s add it to our state object:

const state = {
  films: [
    {
      title: "Killing of Flower Moon",
      director: "Martin Scorsese",
      times: ["15:35"],
      certificate: "15",
      duration: 112,
    },
    {
      title: "Typist Artist Pirate King",
      director: "Carol Morley",
      times: ["15:00", "20:00"],
      certificate: "12A",
      duration: 108,
    },
  ],
  searchTerm: "",
};

We needed to pick an initial value for this state. We picked the empty string, because when someone first loads the page, they haven’t searched for anything. When someone types in the search box, we will change the value of this state, and re-render the page.

We could pick any initial value. This actually allows us to finish implementing our render function before we even introduce a search box into the page. In real life, our searchTerm state will be empty, but we can use different values to help us with development. We can make the page look like someone searched for “Pirate”, even before we introduce a search box.

This is because we have split up our problem into three parts:

1. 👩🏾‍🔬 Identify what state we have.
2. ✍🏿 Define how to render the page based on that state.
3. 🎱 Change state (perhaps in response to some user action).

Let’s try making our render function work for the search term “Pirate”. Change the initial value of the searchTerm field of the state object to “Pirate”:

const state = {
  films: [
    {
      title: "Killing of Flower Moon",
      director: "Martin Scorsese",
      times: ["15:35"],
      certificate: "15",
      duration: 112,
    },
    {
      title: "Typist Artist Pirate King",
      director: "Carol Morley",
      times: ["15:00", "20:00"],
      certificate: "12A",
      duration: 108,
    },
  ],
  searchTerm: "Pirate",
};

We expect, if someone is searching for “Pirate”, to only show films whose title contains the word Pirate.

For now, we have set the initial value of the searchTerm state to “Pirate”. This means that our render function should only create cards for films which contain the word “Pirate” in their title. But right now, our render function creates cards for all of the films.

In our render function, we must filter our list down to the films that match our search term. This does not require us to introduce new state. We can derive a filtered list from our existing state.

Filter function

We can use the higher order array function .filter() to return a new array of films that include the search term:

const filteredFilms = state.films.filter((film) =>
  film.title.includes(state.searchTerm)
);

We can change our render function to always do this. If searchTerm is empty, our filter function will return all the films:

function render() {
  const filteredFilms = state.films.filter((film) =>
    film.title.includes(state.searchTerm)
  );
  const filmCards = filteredFilms.map(createFilmCard);
  document.body.append(...filmCards);
}

We have now solved two of our three problems:

• Identify what state we have.
• Define how to render the page based on that state.
• Change state (perhaps in response to some user action).

Making our search more user friendly

One of the nice things about breaking down the problem like this is that it allows us to change rendering without needing to interact with the page.

If we want to improve our search functionality (e.g. to make it work if you searched for PIRATES in all-caps), we can set the initial value of state.searchTerm to "PIRATES" and make changes to our render function. Then every time we open the page, it will be like we searched for “PIRATES”.

This can be a lot quicker than having to refresh the page and type in “PIRATES” in the search box every time we make a change want to see if our search works.

We’ve introduced our state, and our render works for different values of that state. But users of our website can’t change the searchTerm state themselves. We need to introduce a way for them to change the searchTerm state via the UI.

To listen for the search input event, we can add an event listener 🧶 🧶 event listener An event listener waits for a specific event to occur. It runs in response to things like clicks, and key presses. We register listeners with addEventListener by passing the event name and a handling function.

const searchBox = document.getElementById("search");

searchBox.addEventListener("input", handleSearchInput);

function handleSearchInput(event) {
  // React to input event
}

When the “input” event fires, our handler function will run. Inside the handler we can access the updated input value: const searchTerm = event.target.value;

So our key steps are:

1. Add an input event listener to the search box
2. In the handler, get value of input element
3. Set the new state based on this value.

We will make sure this works before we try to change the UI. Why? If we try to add the event listener and something doesn’t work, we will only have a little bit of code to debug.

If we tried to solve the whole problem (updating the UI) and something didn’t work, we would have a lot of code to debug, which is harder!

We’ve now demonstrated that we can capture search text on every keystroke:

const searchBox = document.getElementById("search");

searchBox.addEventListener("input", handleSearchInput);

function handleSearchInput(event) {
  const searchTerm = event.target.value;
  console.log(searchTerm);
}

Now that we’ve shown we can log the search text, we can set the new value of the searchTerm state, and re-render the page.