Instructor: In this lesson, we are going to learn how to use strongly typed actions to our advantage.
One, by using typesafe actions, that we can move away from these generic object literals and create some type safety by not only controlling the type of action that goes through our system, but also being far more descriptive in terms of what is actually flowing through our application.
If we look at our reducer right now, we have select, create, update, and delete, but there's really no other information. What are we selecting, creating, updating, or deleting? Is it a project? Is it a customer? We do not know.
What I recommend is using typesafe or strongly typed action objects that are very descriptive about the action that you are performing in your application. Stepping into our actions file, let's go ahead and start to build this out.
Instead of using opaque actions with these generic titles, what we're going to do is create an enum that describes the type of actions that we want to make available in our application. We'll call this ProjectsActionTypes. Within here, we are going to define the possible actions that we can take.
We'll go ProjectSelected. The value that you assign to this can and should be very explicit. The convention that I like is I put the feature that I'm working on in brackets, such as Projects. Then, I'll state what I am doing. In this case, it's selecting. For AddProject, I would say "Projects Add Data." You can imagine update data, delete data.
Now, we're being very explicit about the type of action that we are performing, which gives far more actionable data inside of our dev tools as we are troubleshooting our application. Seeing something such as ProjectSelected or Projects Add Data, we know exactly what the action was that fired that.
Now that we've defined our action types enum, let's go ahead and define our action types. This is going to be a strongly typed action. What we're going to do is we're going to create an action that is going to implement the action interface.
We'll start with SelectProject. From here, we are going to give it a type property. If you look at the interface itself, it has one property on that. That is type. We'll set this to the enum of ProjectSelected.
Then, we will define our constructor. This is where we will define our payload as a parameter into our constructor. When you create or a concrete instance of this action, you pass that in. Not every action has a payload, but most of them do.
Let's go ahead and let's build out the rest of our action objects. I'm just going to copy this. I will paste it in. Just for the sake of time, I'm not going to manually type these all out, but rather just update these.
We'll do AddProject. We will update the type. We'll do UpdateProject. Update the type, as well as DeleteProject. Again, NgRx is very, very conventional. Once you understand the pattern in one place, you'll see that it carries over through the rest of the application.
Now that we have defined the actions that we want to use, we will make them available by exporting a union type of project actions. We will do SelectProject.
Using this pipe, we are going to then create a union type of AddProject, UpdateProject, or DeleteProject. This is just a convenient way to export all of these projects or make them available as a single property or a property type within our application.
Now that we have exposed our ProjectsActions as a union type, now, we need to update the rest of our application to move away from these opaque object literals to use the strongly typed action. Let's go ahead and let's import our action types into our projects reducer. Import ProjectsActionTypes.
Let's hop into our reducer. Instead of now listening for a string or evaluating to a string, we are going to update the switch statement to use the enum. This is much, much more descriptive. You're no longer using these magic strings to evaluate on or within our switch case.
We'll go ahead and work through and update the cases to use the enums. Now that we're done with that, let's go into our barrel roll here. We're just going to make these actions available to any outside application that wants to consume them.
What we're going to do is just export our ProjectsActions. Within that, then we will then add in the specific action types that we want to make available, or the specific actions rather.
Now that we've exported these, we can go into our ProjectsComponent. We can replace these loosely typed generic objects with strongly typed actions. Let's go here. We'll just replace this. We are going to go new AddProject. We're going to send in the project as the payload.
Let's do the same for UpdateProject, new UpdateProject. We are creating a concrete action instance, sending in the project as the payload. Let's do the same for the DeleteProject. We're going to new up the DeleteProject action, sending in project as the payload.
Now that we've done that, let's go ahead, hop into the app. Let's see this working. There we go. Project deleted. If we step into the dev tools, now, you can see that the information coming through is much more descriptive, which is exactly what you want to happen.
Let's do a quick recap. Let's go into the project actions. You can see that the first thing we did is created a ProjectsActions enum, defining our types. From here, we went into our reducer. We updated the reducer to evaluate on those types. We exported our individual actions that we created.
Within our ProjectsComponent, we went through and removed those generic object literals with concrete instances of the action objects that we created. This is how you use typesafe actions within your Angular application with NgRx.