Storing State in an Angular Service

In the last lesson, we set up a form component that would emit an event that includes the data that the user entered into the form. We are using that form component in our HomeComponent now, but all we are doing is logged out the value from the form.

Now we actually need to do something with it. This is going to be our first experience with dealing with state in the application. We have an entire module dedicated to state coming up soon. Of course, we are going to discuss what state is and what it looks like in detail in that module, but it is useful to have a basic idea now.

A Quick Intro to State

Let’s use a real analogy. Consider a hammer, a hammer does not have state (we probably could consider a hammer to have state, but let’s keep things simple). Consider a light bulb, a light bulb does have state - it can be in the on state or the off state.

When we first load our application it is in its default state. At the moment, that is the only state our application can be in because there isn’t anything that modifies our applications state yet (without getting too technical). A user enters some data into a form, submits it, but nothing happens. However, we do want something to happen. We want to add a feature so that the data the user enters is remembered and displayed in the form of a todo in a list. When we do this, the applications state will have changed because now we have some data in memory. When thinking of state, think of a lightbulb, or a traffic light, or a computer. In what ways can our application be interacted with (internally or externally) to change the way it behaves/what it stores in memory? Generally, the state of an Angular application refers to the data that is being stored in memory (i.e. the stuff that will be lost when the application is refreshed).

Storing State in a Service

We have some todo data that we are handling, and we want that as part of our applications state somehow. Specifically, we want to store the data in memory and use that data to display a list of all the todos that have been added.

This is where we will reach for a service (i.e. an @Injectable() class). If you remember from the basics section, a service can be shared with out entire application. It’s a great way to share data between components, and store data that we want to persist throughout the life of the application.

This service is going to have a publicly exposed observable stream. We can then subscribe to that observable stream from anywhere in the application, and can react any time it emits new data. We will use this stream in the service to emit our todos whenever a new one is added.

This stream will only be active for as long as the app runs. As soon as we refresh the application our service is going to be destroyed along with any data in memory. If we want to persist data in memory, we will need to use some kind of external storage mechanism and then re-initialise our state upon loading the application. This is a challenge we will tackle in our “real” application walkthrough later.

Create the following service at shared/data-access/todo.service.ts:

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
import { Todo } from '../interfaces/todo';

@Injectable({
  providedIn: 'root',
})
export class TodoService {
  todos$ = new BehaviorSubject<Todo[]>([]);

  addTodo(todo: Todo) {
    const newTodos = [...this.todos$.value, todo];
    this.todos$.next(newTodos);
  }
}

The todos$ stream is what will be responsible for storing the state in our application for now. I keep dancing around observable streams because I am trying to keep things basic until we get to our module on reactive programming. So, we aren’t going to deep dive into what a BehaviorSubject is here, but the basic idea is that a BehaviorSubject will: