[MUSIC] So you want to learn Angular,
and I can't blame you. Google ushered in a new paradigm for web
application development when it released the first version of Angular in 2012. And while yes,
that was a very long-time ago, especially considering how fast
things change in the web industry, Google continues to improve Angular
with new features and performance. Angular is a larger framework than React
and View, providing more features and capabilities out of the box, so it's
entirely understandable if you find it. Well, a little intimidating, but
you've come to the right place. I am Jeremy McPeak with Envato Tut+, and I invite you to spend the next
few hours with me as I walk you through the fundamentals you need to get
started writing applications with Angular. We'll start at the very beginning, you'll
install the Angular command line tools, and we'll create a new project together. You'll learn how to display data with
Angulars directives and templating syntax, as well as binding data to properties,
attributes, and handling events. We'll then dive into components, and you'll learn how to create components
that accept input and provide output. I'll also teach you how to
set up two-way binding and manipulate style within your component. Then, we'll look at some of the services
and concepts that Angular uses, such as dependency injection,
the HTTP module, and observables. You'll learn how to create and
use modules to organize your applications, handle and validate form input
with reactive forms, and build single-page applications
with Angular's router. Now, we have a lot of ground to cover,
but before we begin, be sure to subscribe to Envato Tuts+ for
more free courses and tutorials. Now, let's get started. I am a firm believer that jumping right in
and creating something is one of the best ways to learn a new technology, so
we are going to do just that with Angular. But first of all,
we need to go over what you need for Angular development, and
the first is node.js. Now, we aren't going to be actually
writing a node-based application instead, we install node in order to get
Node Package Manager or NPM. It's how we manage our dependencies
with modern development. And in the case of Angular, we use NPM
to get the Angular development tools. And so
when it comes to installing node.js, you essentially have the choice between
two versions, you have the LTS, which stands for long-term support,
and then you have the current version. Now, for our purposes, it really doesn't
matter which version you choose. I typically always reach for
the LTS because it's long-term support, it is the more stable version. But as I mentioned, for our purposes,
it really doesn't matter, so choose whichever one you want. The installation is very straightforward,
just take the defaults, and you will be good to go. You will also need a code editor. Now, technically, we are going to be
working with just normal text files, that's all code is, but logically,
code is specialized text, so it makes sense to have
a specialised text to editor. And when it comes to
working with JavaScript, Visual Studio Code is the best editor. Now, of course,
you can use whatever editor that you want. There is no requirement that you use
Visual Studio Code or anything else. Use what you like and if you don't know
what you like, there are many free options available to try, there's many
not free options that you can try. The point is to try a lot of them and
find the one that you like. Now, as far as
Visual Studio Code is concerned, there are distributions for
Mac OS Windows and Linux, so chances are you will be able
to run it on your machine. And, of course, you need a browser and
any modern browser is going to be fine, especially since most modern browsers
are now based upon Chromium. However, I will say that
browsers like Edge, Opera, Brave, all of those Chromium-based browsers,
while they work the majority of the time, there might be some specific things
that don't work quite right. So for me, I'm going to be using Chrome,
but again, feel free to use whichever
modern browser that you like. So after you have installed Node,
you will want to open up the command line, because NPM is a command line tool, and we
will use NPM to install the Angular CLI. The CLI is the command line interface. And really, it's just a tool set
that we can use to create projects, work with our projects,
and even run them as well. The command that we will use to install the Angular CLI is npm
install @angular/cli. Now, we want to follow this up with
the global flag, that's --global, and the reason is because if we install
this globally, this is going to give us a command called ng, and that command is
what we use to work with our projects. And we will be able to use
that ng command anywhere, regardless of what directory
we are currently in. If we installed the Angular CLI
without the global flag, then it would just install that within
whatever directory we are currently in, and we wouldn't have global access to it. When Angular is done installing,
we will use the ng new command, and then we just need
to create our project. Let's create a to-do application, but
let's not call it to-do because that's boring, let's make this a wish-list,
and then press Enter. Now, this is going to ask us some
questions for creating a project. And the first question is asking
if we gonna use angular routing, which we will talk about
routing later in this course. But for right now, we're going to
take the default and specify, no. Now, I do want to point out that
Angular is rather unique when compared to React and View, because the router
is built in to the Angular framework. With React and View,
you have to install the router separately. In fact, Angular gives us quite a few
features out of the box that other frameworks don't, but we will talk
about those whenever we need to. So I'm going to choose no for the routing. And then, we are going to be asked what
style sheet format we want to use for this project, and you can see that
there are several options here. I'm just going to choose just normal CSS,
and now that we have a project, I'm going to CD into that directory. It's simply the project
name that we chose, wish-list in this case, and
I'm going to fire up the code editor. Now, we can also run our application so that we can actually
see it in the browser. And the developer tools will also give us
the ability to develop our application and see the results in real time. So it's going to watch our files and
whenever we make changes, it's going to automatically rebuild our application
and load that into the browser, and so we can run our project in
a couple of different ways. We can go back to the command line and
simply type ng serve, and that's going to start up our
application in development mode, so that we get the benefit of the hot
reloading and things like that. Or we can use the built-in terminal
within visual studio code, which is what I'm going to opt to do,
and I'll pull that up, we'll type ng serve, and
then we're going to see, The Angular CLI go through
the process of building our project. It will tell us where we
can point our browser so that we can then view
that within the browser. We can see that our application
was compiled successfully, and it is going to be
at localhost port 4200. So let's go ahead and hop on over to
the browser so that we can view that. Now, if there were any errors as it
compiled our application, of course, we would see those errors in the output. But of course, there shouldn't be
since this is a brand new project. Now, in the browser, you're going
to see a full fledged web page. Of course, most of these things
point to the Angular website. But let's just take a moment and
see how we get what we see in the browser. So inside of our project,
we have this source folder, and this is the folder where our
application source code lives. So let's open this up. And we're going to see some more
folders and we will see this main.ts. If we open this up, this is the main
TypeScript file of our application, because Angular uses TypeScript. Now, if you're not
familiar with TypeScript, it's simply just a superset
of the JavaScript language. So perfectly valid JavaScript is
actually perfectly valid TypeScript. And so we're not going to dive into
the inner depths of TypeScript, we will be using it. And as some features pop up,
I'll of course mention them, we'll talk about them at that time. But for right now, we are just going to
treat this as just normal JavaScript. Well, until we don't. So here, we have main.ts. This is essentially the main
file of our application. There are four import statements, but the one that I want to talk about is
on line 4, where it is importing this AppModule from a file called
app.module inside of the app folder. So let's take a look at that. So here,
we have this app.module.ts file, and we can see that it is
importing this app component. Now, Angular is very similar to React and
View in that it is component-driven. We build applications
by building components. A components is just a building block. It contains certain functionality for
different pieces of the application. And over on the left-hand side if we look
more inside of the app folder you're going to see several files
that begin with app.component. So in this case,
we have a component called app, and it is made up of each one of these files. There's one for the CSS,
there's one for the HTML, which is essentially the template for
this component. This is what is actually
loaded into the browser. There's a spec file for tests,
and then there is the code file, or the TypeScript file for that component. So in this particular case,
it has four files. That doesn't always have to be the case,
but it's what we have for this app component. Let's take a look at the HTML file,
because this contains all of the markup that's actually loaded
inside of the browser. It's not all of the markup,
but it's quite a bit of it. The first [LAUGH], well,
two-thirds of it is just CSS. But if we take a look after the style,
we can start to see just normal HTML. We have a div with the class of toolbar,
the role is banner. There's some content inside of there. Then we have another div with a class
of content, the role is main. And once again, we have some content. But look line 344,
this doesn't look like HTML. We have a pair of curly braces, and
then inside of that we have title. So remember that I said
that this is a template. This is the HTML template for
the app component. And so what we see here is
just some template syntax. It is outputting the value that is
assigned to a variable called title. So then the question becomes
where is this title defined? Well, that is inside of
the TypeScript file, app.component.ts. Here, we can see that there's
a class called AppComponent. It has a title property,
it is set to wishlist. So if we take a look at
this in the browser, we can see at the top that there's
this wishlist app is running. That is the text that we
saw inside of the HTML. Except that we see title here, and the value assigned to title
as we saw is wishlist. So here is wishlist app is running. So if we change the title from
wishlist to simply my wishlist, then whenever we go to the browser,
it's gonna take it a second or so because it has to
recompile our application. But you can see that it automatically
updated, I did not have to refresh that. So that's now the title is my wish list,
and we see that reflected in the browser. Now, here we see something that looks a
little weird, especially whenever you just think in terms of JavaScript,
and that is this AppComponent. This is what we call a decorator. And the decorator gives us some
information about this particular component. This is a component called AppComponent,
but notice that there is this selector,
and it is app-root. Then there is a templateUrl. And then the HTML file, app.component.html
is set for the template. And then in styles is set for
the styles URL, which is inside of the app.component.css. So this component decorator
essentially tells Angular how this component is going to
be used with this selector. This is essentially a tag name,
where the template for this component is and
where the style is as well. And so finally,
let's open up the index.html file. This is directly inside
of the source folder, and it doesn't really look like much. But notice here on line 11,
we have app-root, that is, the selector that was defined
inside of the AppComponent. So selector is app-root. So here inside of index.html,
app-root is being used. So Angular knows that this is where it
is going to generate the template for the AppComponent and
inject that right here on line 11. So that whenever we are in the browser, we see the result of that
index file being loaded and then the content from the AppComponent
being rendered inside of it. And so if that is clear, don't worry because we're going to be
spending a lot of time with Angular. And in fact, in the next lesson, we will
start developing our wishlist application. When I start developing a new project,
I typically start with the data. Because, after all,
we write software to work with data. And if we don't have data, it makes
it very hard to develop our software. So in this lesson, we will begin
by writing a class that represents an individual wish, because after all,
this is a wish list. We're going to have a list of wishes. So the question becomes,
where do we define this class? Because we do have this source folder,
There's an app folder and then there's also some files
just directly inside of source. Well, there really are no hard and fast rules when it comes
to structuring our project. There are a lot of people that have a lot
of really good ideas, but I think for this application,
let's just keep things simple. A wish is something that's going to
be used throughout the application. It is a simple application, but
the idea is that this is a wish list. We might want to use the individual
wish items anywhere. So it would be something that would
be shared across the application. So inside of the source folder, I'm going
to create a new folder, called shared. And then inside of shared, I'll create
another folder called simply models. This really isn't keeping it simple,
is it? [LAUGH] But there is something to
say about keeping things organized. And I personally like
this organization here. So inside of modules,
we'll create a new file and this will be our class that
represents an individual wish. So we can call it wishListItem but
that's a mouthful, so let's just call it wishItem. And this is a TypeScript file,
so we'll use the TS extension. Now, let's zoom out just a little bit, because how we define this
class is very important. If we take a look inside of the app
folder, let's open up app.component, and we will see, of course, we import
component, which is that decorator that's used to tell Angular the meta
information about this component. But then we see the class definition,
but it is being exported. And that is because it needs to be
imported inside of this other file, app.module, here on line four. But then, again, if we take a look at this
file, there are some import statements. The NgModule decorator is used, but then there's a classified
that is also exported, and the reason is because it is
imported inside of main.ts. So the point that I'm trying to get across
is, regardless of if it's JavaScript or TypeScript, it needs to
be a module because we are essentially going to import it
somewhere within some other file. So whenever we create our WishItem class, we need to export it and
we'll call this class WishItem. And we are going to use a TypeScript
feature here that allows us to define a constructor. And it will also automatically create
the properties for this class, because we could explicitly define
those properties, but we can also do so as arguments to the constructor. So the first thing we are going to mark
is the accessibility of this property. We want this information to be public, so that we can access it from
outside of this class. And when it comes to a WishItem,
we essentially have two things, we have the wish itself,
which we can call wishText. I'm not exactly sure I'd like that,
but we'll run with it. And then we would need a Boolean value to
determine whether or not it is complete. Now, TypeScript is called TypeScript,
because it allows us to also specify the type of
the data that we are working with. You don't have to use the type syntax, but it is extremely helpful when
developing larger projects. So our wishText is of course text,
this is a string. And in TypeScript, we specify the type
after we define the variable or, in this case, the constructor parameter. So in this case, it is simply a string. The isComplete is a Boolean value,
so we will mark that as Boolean. And so whenever we create a new WishItem,
we will pass in the text for the wish, we will denote whether or
not it is completed. And behind the scenes, that's going to
automatically create two properties, one called wishText, which is a string,
one called isComplete, which is Boolean. We can also set a default value for
Boolean. We could say that by default,
isComplete is going to be false, so that then that gives us
the option of passing either just the wishText or
the wishText and the isComplete. So let's go to our app component,
and let's go ahead and let's import this because we
want to use this WishItem class. And Visual Studio Code is automatically
popping up with the correct file, so we can just click on that and
it has imported that. And so now inside of AppComponent,
we simply want some items, which we can initialize as an array. And let's pre-populate this
array with a few items. So we will call the WishItem constructor. The first wish could be To Learn Angular. And I want to point out
the tooltip that we see here. We can see that WishItem
accepts up to two arguments. The first is the wishText,
which is a string, the second Is optional, because of this question mark after
isComplete, and that is Boolean. This is one of the reasons why
TypeScript exists, it's for tooling and providing a better development experience,
so that as you are writing your code, your code editor can provide information
about the types that you are working with. In this case, that type is a WishItem. Let's add another wish,
one that we could go ahead and complete, and that is to have some coffee. So let's say Get Coffee, and
let's pass in true for that value. And then let's add one more item, and this is definitely going to be a wish,
but Find grass that cuts itself. So let's save this file,
let's pull up the console. Let's see if we get any errors
with the build process, and we don't, it was compiled successfully. And then we just need to display this
information in our template, because, of course, as it is right now,
we haven't changed our template, it is still as it was before. It's working with the same data,
which really the only data was that title. But we want to change what
is reflected here, and we will do that in the next lesson. In the previous lesson, we created a data model class
to represent an individual wish. We called it simply WishItem. And then inside of our AppComponent, we created an items array that
contains multiple WishItem objects. So, of course, we want to display
these items within our application. But, of course, right now, we have just
the default templates being used, but that's easy enough to change. Let's open up our template. And if you'll read the very top,
it says that this is only a placeholder. Delete the template below to
get started with your project. All right, so
we'll just delete everything. And let's also pull in some CSS
because it would be useful to have something other than just
the default browser stylesheet. Now, it's common to find
Angular applications using the material UI library. If you're not familiar with material,
it is Google's UI framework or UI language,
whatever verbiage you want to use there. And that's all well and good, but I think
that we can get started much easier. By just using Bootstrap. Cuz we can just use the CDN,
paste in that link to our index.html file, that is the template of our application. So that everything within our application
is going to have access to Bootstrap. Makes it very easy to do. Plus, it's a lot easier to use. Now, let me also say that Material
is a pretty cool library. There are a lot of different components
that have the Material UI built in. And that's why you would find it's used
in a lot of Angular applications, but for our purposes, this is going to be fine. All right, so let's start our components template with
a div that has a class of container. And we'll just start with
a simple div element so that we can display the individual
items within that array. Now if you'll remember
from a few lessons ago, we saw this syntax inside of our template
to where we had the double curly braces. And then inside, I think it was
title that was used, yes it was, that title property for our app component. So if we wanted to, we could display
the first item by using the index of 0. And then we could have the wishText. I think that's the property that we used. We'll definitely find out whenever
we review this in the browser, and sure enough, that's it. So we could do the same thing for
the other items, but of course, that's not scalable whatsoever. That would be a nightmare. So whenever we work with arrays, we typically iterate over
them using some kind of loop. And JavaScript has several
different loops, but the one that we typically
always use is a for loop. And Angular gives us an easy
way of iterating over an array, or let me say this, it gives us
an easy way of using the for of loop. And we will use what's called a directive. A directive generally starts with
an asterisk, followed by ng, short for Angular. And if you'll notice, Visual Studio Code
is popped up several options here. But this set right here,
this little icon indicates that this is something that we can use for
this div element that we are working with. And we see ngFor, ngIf,
ngPluralCase, ngSwitchCase. And the thing that sticks out to me is
ngFor, because, hello, we have a for loop. So whenever you use a directive,
you use it like an attribute. So this looks a little wonky. And then the value for
this directive is essentially a JavaScript expression,
that's item of items. So let's take a step back. Let's talk about the for loop. So the traditional for loop that we
typically learn first is that for loop that has the three parts. We have the initialization,
followed by the condition, and then we have the iteration. And that's all well and good, but that's
a little bit more than what we need. We just need to work with
the individual items. So JavaScript gives us the ability
to use the for of loop, which is primarily used for
iterable objects, like an array. So that we can say for, and
then let item of items, and then that's going to give us
the individual item that we can work with, and that's exactly what
we want in our template. So let's go back to the template,
and that's what we have. So we have a directive,
ngFor, the value for this directive is the JavaScript
expression for the for of loop. And then that gives us the ability
to use that individual item object however we need to. So we could say item.wishText,
and inside of the browser, we will see our list of items. Now that's all well and good, but we want
something a little bit more interactive. Because this is, after all, a wish list, we should be able to check
these things off as needed. Now I'm going to paste in some markup,
because, well, it's quite a bit of markup and
you don't want to see me type this. And if you've used Bootstrap before, you know that there can be some setup
involved to make something look nicer. And that's basically the case here. The code is essentially the same,
at least as far as the ngFor directive is concerned, and
whenever we output the wish text. Other than that, we just have a basic
ul element that has some li elements, that is using the Bootstrap markup for
outputting a checkbox. So if we take a look at
this in the browser, we get a list of items with
checkbox that we can check. And, of course, right now, behind the
scenes, the checkbox isn't doing anything. We want to be able to essentially
change the values of our wish items when the user clicks on these checkboxes,
but we'll get to that. The one thing that I do want to
get rid of is the list dots. So we can do that by changing the CSS. And let's open up app.component.css. And we're going to add
the wish-list class. So that will set the list
style to just none. And that will get rid of that. So that now we just see the checkbox and
the text for that checkbox. Now the ngFor directive
is somewhat special, in that it is what's called
a structural directive. It changes the structure of the DOM. So in the case of ngFor,
it is adding an li element for every item in the items array. So it is adding elements
to the DOM structure. In the next lesson, we will look
at another structural directive, one that we can use to make decisions and
conditionally show or hide content. In the previous lesson, we looked at
the ngFor directive, and we used it to iterate over an array so that we
could display the individual wishes. And that makes perfect sense. But what if we don't
have anything to display? Like, for example, we've just hard-coded
these wishItem objects, and for development, that's fine. But in a real application, this
information would be dynamically loaded, either by fetching it
from the web server or by accessing some storage,
like local storage. So let's comment out those lines, and
we can see that there are some issues. Now, in the terminal,
we see that there is an issue. It did not compile correctly, and we see that it is an issue with
the template of component AppComponent. And it, of course,
tells us what that template is, but Visual Studio Code gives us
some visual cues as well. The file name of our
template is a reddish color. The directory that contains that
file is a reddish color, and then its parent directory
is a reddish color as well. And of course, the tab text for
that template is also reddish, so there's definitely something
wrong with that template. If we open up that file, then we can
see by this red squiggly underneath wishText that that is the issue,
that's the error. So if we hover our mouse over it, it says Property wishText
does not exist on type never. Now, if we go to the browser,
we will see the same thing, except that this is a little bit easier
to read, at least in my opinion. Property wishText does
not exist on type never. All right, so this can be a little confusing if
you're not familiar with TypeScript. Because remember that we are using
TypeScript, TypeScript is a superset of JavaScript, and
any valid JavaScript is valid TypeScript. However, behind the scenes, TypeScript is doing quite a few things
that's we may or may not be aware of. For example,
whenever we created this items array, we hard-coded those WishItem objects. So TypeScript, behind the scenes, assumed that this items array
is an array of wishItem objects. We can see that right here that items
is an array of WishItem objects. And TypeScript was safe to
assume that because we only have WishItem objects inside of that array. Now, what happens if we
take out those objects? Let's hover over the items property, and we can see here that items
is now an array of never. And the reason is very simple,
because it's an empty array. And as far as TypeScript is concerned, it
will never have any objects inside of it. Because we initialized
it as an empty array, we don't do anything else with it,
so it's an array of never objects. And so there are primarily two
ways that we can get around this. The first is to say that our items
array is actually of type any. If we take this approach, then this would
be considered the the JavaScript approach. Because in JavaScript, we can have
an array that contains anything or we can have an items property
that can be anything. And in which case, the error goes away, if we look at the browser then of course,
we don't see anything, but that's kind of what we would expect
because there are no items to display. But what I would do is this. We know that items is only going to be
an array that contains WishItem objects, so we might as well just go ahead and say
that this is an array of WishItem objects. And if you're not familiar with
TypeScript, the syntax for doing that is fairly simple, although it looks a little
wonky in the world of JavaScript. So you start with the name of
your property or variable, followed by a colon, and then the type
of that variable or property. In this case, it's an array denoted by the
square brackets after the WishItem class. Okay, that's great. So we save that. We still have no errors, we go to
the browser, we still don't see anything. And at least at this point,
that's okay because we don't see an error. But in the terms of just the application
as a whole, we don't want to just display nothing, we want to at
least say that there are no wishes. So we can do this by using
a directive called ngIf. If the array doesn't have any items,
then display our message. So we'll have a div element,
we will use the ngIf directive, and this works a lot like
just a normal if statement. We provide a condition, and
if that condition is true, then the element is going to
be added to the document, and of course,
any content that it contains as well. But if the result is false, then this element is not
rendered in the document at all, it's missing, it ain't there,
and that's perfect for our needs. So let's do a check. If the length of items is equal to 0,
then we want to display the message of There
are no wishes to display. And so if we view this in the browser,
then we should see that message, volla. But let's take a look at the HTML
that is rendered in the document. So, there's our app root element. Let's drill down. There's the div that has
a class of container. And then we have the div that has our
message, There are no wishes to display. That works great, but
we have this UL element. Now in the grand scheme of things, it's not that big of a deal
that we have the ul element. But if we don't have any items to display, why render the UL element at all? Now unfortunately,
there is not an ngElse directive. That would be perfect in
this particular case, so that we could have just ngElse and we
would go on our way, we don't have that. So one of the ways that we can get around
that is just by using another ngIf, except that we will essentially
do the opposite comparison. If we have in the items, so
if the length is greater than 0, then we want to show our UL element in
all of the LI elements inside of it. But if not, we don't want to
render that UL element at all. And we can see that now we still
have the div that has our message, but the UL element is gone,
it's not there anymore. And that's all well and good, but
there are alternatives to this approach. For example,
we could have just a container element. So let's just start with a div. And we will still use the ngIf here,
and we can still do the same comparison if
the item's length is equal to 0. But then we could say that if that's true, then we want to render the content inside
of a template that we will call no items. Else, if we have items, then we want
to render a template called showItems. Then we can define those templates using
a special component called ng-template. We define its name starting with
a pound or a hash sign, and then the name of the template. So this would be for no items, in which case we would display
There are no wishes to display. And then if we do have items, we would want to have our other
template called showItems. So we would create that template,
give it the name of showItems, and then it would contain our
UL element just like that. So it's a little bit more typing, but it's also a little bit more clear
as to what's going on here. So once again, if we go to the browser,
we still see just that content. If we drill down into app root, drill
down into container, we have our message. But notice that the div element
that we put the ngIf directive on, that's not being rendered here, so
that's just kind of a placeholder for the content for our template. But let's see the other work. Let's go back, and
let's have our list items here. We'll go back to the browser, it will
refresh, and then we can, of course, see our list of wishes. So that works, but we can make this
even just a little bit cleaner. We could get rid of
the then statement here and we can put our message as the content for
this div that has the ngIf directive, so that if the condition is true, then our
content inside of this div element and this div element itself is going
to be displayed in the document. Otherwise, if we do have items, then the
show items template is going to be used. So let's go back to the browser. That's what we see. We have our list. If we drill down,
we have our div with a class of container. But we also have are ul element that
of course, contains all of our items, but let's make sure that the other works
as well as comment out those items. Once again, we'll go back to the browser,
we see our message and if we take a look at the rendered html, we have our
div with a class of container, then we have that other div that contains our
message, there are no wishes to display. So when it comes to making a decision,
we can do so in several different ways. We can use multiple ng-if directives. We can use ng if in conjunction
with the then statement or we can also use the else statement. Now there's one other thing
that I want to point out. NgIf is a structural directive. It changes the structure of
the document based upon the condition that is evaluated. And now that we know two structural
directives, it's important to know that you cannot have two structural
directives on the same element. So if I add ngIf to the li element,
and it doesn't matter what we use for the condition, we're going to
see that there is an error, and the error is this second structural
directive, the ngFor directive. You cannot have two structural
directives on the same element. Now that’s going to force you about how
you need to structure your mind and structure your structural directives
because there is no hard and fast rules as to which directives
you use on each element. That all depends upon what your needs are. Now, in the next lesson we are going
to learn how we can find data. We write software to work with data, and
that data can come in any way, shape or form, and it is up to us to determine
how we work with that data. Of course, it depends upon our
application, but sometimes we want to display that data, sometimes we just
want to work with it behind the scenes. Now, in the case of our wish list, we have essentially two pieces of
information that we want to display. We want the text of the wish,
which we are currently doing, but we also want to show whether or
not that wish has been fulfilled. Now, that is, of course,
what the check box is for. And eventually we want
this to be interactive so that whenever the user
clicks on these check boxes, then that toggles whether or
not the wish has been fulfilled. Now, in the sense of our data, we represent that fulfillment value
with the is complete property. It is a Boolean value, of course,
so it's going to be true or false. Right now,
we only have one wish that is fulfilled. Get coffee, because I always have coffee. So at the bare minimum, we of course,
want to display this in the browser. So the question becomes,
how do we do that? Well, let's first of all talk
about the input element. And more specifically,
let's talk about the checkbox. And the same goes for
the radio button as well. So in html,
we denote that a checkbox is checked by just adding the checked
attribute to the element. That's all we have to do. If that checked attribute is present, then the check box will be
checked in the browser. And the funny thing is it doesn't matter
what you assign to this attribute. It can be assigned false,
which makes no sense whatsoever, but it is still going to be
checked in the browser, because it is based upon whether or
not that checked attribute is present. Now, that's the html side of things. On the JavaScript side of things,
this input element has a checked property. That property is Boolean. So if it is true,
then the check box is checked. If it's false, then it is not checked. So the JavaScript property and
the html attribute are named the same, but they behave differently. And because our data is Boolean, it makes sense that we would want
to bind our isComplete property to the checked JavaScript
property on the Input element. And we can do that very easily
right here inside of our template, we will use what's
called property binding. So we will take
the JavaScript property name. In this case it's checked and
we surround it with square brackets and then the value that we assign to this
is a JavaScript expression that will determine whether or
not this check box is checked. That, of course, is the IsComplete
property on our Wish Item class. So if we take a look at the browser,
we have our three items here, but notice that
the Get Coffee Item is checked. Let's inspect this and we will see
that it is indeed type checkbox, the class is checkbox, but
notice that there is no checked attribute. That's because we set this using the JavaScript property
Opposed to the html attribute. So when you want to bind something to
the JavaScript property of an object, all you have to do is surround that
property name with square brackets, assign the JavaScript expression that
will then be bound to that property, and you are good to go. Now one thing to note here,
this is the JavaScript property. So if you were doing something using
a td element inside of a table and you wanted to bind to the call span. Well, call span,
all lowercase is the html attribute. The JavaScript property uses camel case. So if you want to bind to the JavaScript
property, you would need to use the camel case version of call span because after
all that is the JavaScript property. Now, not to confuse the issue Issue,
we can also bind to html attributes. So for example, we have a checkbox and we are determining whether or
not that checkbox is checked, using the checked property, and
we are binding that to IsComplete. But let's say that we wanted a custom
attribute called data-index. And this would represent in index of
the item inside of the items array. Now we can get the index
with the ng4 directive. All we have to do after our
iteration statement is have index, as and then whatever identifier
we wanted to use for the index. I'm going to use ii because
that's what I typically use. And if we assign ii to just this
data-index inside of the browser, whenever it is rendered,
we see that data-index is there, but it is literally the string ii. We want to bind this ii
variable to the attributes, and we do that almost in the same way. We surround the attribute with square
brackets, but before the attribute name, we have a prefix,
attr.and then the attribute name. And this is going to result in an input
element, has a data-index attribute, and it is set to the index of
the item in the items array. So we can bind data to an element's
attribute or to its property. Using similar syntax,
the only difference is that binding to attributes uses the attr.prefix
followed by the attribute name. And in the next lesson you
will learn how to bind events. Events are probably the most important
part of an application with a graphical interface because it is the primary
way that the users interact with our application. Like, for example, in our very simple UI,
the user is going to click on these checkboxes in order to toggle whether or
not that wish has been fulfilled. But of course, right now,
we aren't really doing anything. Now, we have bound the isComplete
property on our wish item to the checked
property on the checkbox. However, that is a one-way binding. We are taking the value of isComplete and binding that to the checked
property on the checkbox. So when the user clicks on the checkbox,
it's not updating the isComplete property. So we need to write the code
that's going to do that. So in order to bind an event,
it's going to be very reminiscent of the DOM level 0 event handlers,
which were simply HTML attributes. If we wanted to handle
the click event on an element, we would use onclick, or for
mouse out, it would be onmouseout. The idea being that we have the event
name and it is prefixed by, simply, on. And then the value of this attribute
would be the JavaScript that we wanted to execute when that event occurred. Now, over time, we learned that
that didn't scale very well, and so we started to separate our
markup from our JavaScript to where we set up the event
listeners in our JavaScript. Well, now in the world of UI libraries
like Angular and React and Vue, we do it declaratively so
that it is done inside of the template, which means that, once again, we are back
to using what looks like attributes. But for Angular we bind events very
similar to how we bind properties or attributes, except that instead of using
square brackets, we use parentheses. And right off the bat, Visual Studio Code
is going to pop up with a list of possible things that we might want to use. And this is not even the full list,
over here's a scroll bar, so you can see how small that is. So there's a lot of events
that we can listen for here, but notice the names of these events. They are simply just the event names. So blur, click, change. If mouseout was listed here,
which if we scroll down we would see that, or mouseover,
it is simply the name of the event. There is no on prefix or
anything like that. They are also not camel cased because
the names of events are all lowercase. So in order to bind to the click event, all we have to do is use the event
name surrounded by parentheses. There we go, and then we assign
the JavaScript that is going to execute. Now, this doesn't have to be a function. We can have a JavaScript expression that
will just execute whenever we click on it. But I think it would be
useful to have a function so that we can do some extra things here. So I'm going to say that whenever
we click on our checkbox, we are going to call a function
called toggleItem(). Now, this is actually going to be
a method on our component class. So we need to go to app-component and
we need to add the toggleItem method. And for right now, let's just write a message to
the console that this was clicked. So let's save that,
let's go to the browser. I already have the console pulled up, so
whenever we click on these checkboxes, we can see the text,
clicked, in the console. So that's great. So when it comes to DOM events, one of the
things we typically do is access the event object that occurs because that gives us
a lot of information about the event. Now, that's not going to
be given to us by default. What we have to do is pass
the event object here, and we do so using a special identifier. It is simply the dollar
sign followed by event. So there we go, that will pass
the event object to our toggle item. Now, notice we are getting an error here. And that's because as it is right now, the toggleItem method
doesn't accept an argument. But we want an argument,
we're just gonna call it e, and let's type this as an any object, and then
let's just write out e to the console. So now whenever we click on these
checkboxes, we are going to see the event object and we can see all of
the information that comes with that. So, of course,
there's the client coordinates. We can see if the control key
was pressed whenever I clicked. If we scroll down, we can see the type
of event that occurred, which of course, is rather obvious, but
sometimes you never know. We can see the targets,
which this is in alphabetical order, it ought to be easy to find,
the target's right there. So everything that we would need for that event,
we get access to with that event object. But I think in our case
we don't even need that. All we really need is the item
that we want to work with. So we can pass item to toggleItem, and that is going to give us
the ability to manipulate that item object because that item object
comes from our items array. So we are working with all
of the same objects here. So let's type this,
first of all, as a WishItem. Let's call this item, as well. And before we do anything,
let's go ahead and let's see what that
item is in the console. And we will see that
the binding that we set up for the checked property is a one-way binding. So let's click on the Get Coffee wish,
which of course, unchecks that. But if we look in the console, we can
see that the wishText, of course, didn't change because, well, that makes perfect
sense, but isComplete is still true. And if we click on Get Coffee,
once again, isComplete is still true. So property binding is just
setting up a one-way binding. That means that we need to update
the isComplete property ourselves. And we can do that very easily, since we
have the item that we want to work with, we can simply set the isCompleted
property equal to its opposite, and that way our data is going
to stay in sync with the UI. So let's let this reload. Let's click on Get Coffee. We can now see that isComplete is false. If we click on it again,
isComplete will be true. So setting up event
listeners is very simple. We do so inside of our template using
the event names surrounded by parentheses. And then we simply assign
the JavaScript code that we want to execute when that event occurs. If events are the most important
part of a graphical application, then forms, or at least working with
forms, is a very close second because events allow the user to
interact with our application. Forms allow them to provide data
to our application to work with. Now, Angular lets us work with
forms in two different ways. The first is called reactive forms, which
is the more robust and scalable approach. There's also a lot more setup involved,
and we will eventually work
with reactive forms. But for right now,
we're going to take the second approach, which is called template-driven forms. It basically allows us to define our
forms inside of our template, and then we just rely upon directives. That allows us to manipulate
the underlying properties or objects that are bound to our form. So I just pasted in the markup for
our form. It's very simple. We have just a simple text field for
the wish text, and then a button that the user will click
on to add that wish to the list. And let's start with the easiest part,
which is going to be handling the click event on our button,
because we already know how to do that. So let's just start there. And the first thing that we need to do is
prevent the form from being submitted, because that is the default behavior
of clicking a button inside of a form. At least, as far as this is concerned, it's just basic form processing,
preventDefault(). We'll use the $event object to get access
to preventDefault(), and there we go. Now, the beautiful thing about this
type of syntax is that we can execute multiple statements. So this is going to be a single statement,
and then we could call a method
to add the wish to our list. We'll call this method, addNewWish. And of course, we need to add
this to our component class. So let's do that before the toggleItem. This is just a personal preference
of mine, inside of a class, I'd like to group all of
the like things together. I want to group the properties together,
I want to group the methods together, and then I want them in alphabetical order,
because I'm OCD about that stuff. So, of course,
the code inside of this addNewWish is simply going to add the wish
to the items array. And then, ideally, we will also
clear the text box so that the user doesn't have to clear that out if
they want to rapidly add new wishes. So that should work, and we're good. So now, what we need to do is find a way
to bind data to this input element. And we do that with syntax that's
going to look very similar, because we essentially combine both
the property binding syntax and the event binding syntax together. We start with the square bracket,
followed by the parentheses, and then we have a special
directive called ngModel. Now, this is very similar to what
you would find in React and Vue. We simply are telling Angular, hey,
we have this form field that we want to bind to a property on our class,
and we can just call this newWishText. So let's take this property and
define it inside of our component class. So I'm gonna put this after the items. Now, of course, down in the terminal,
we see that there's an error, and that's because we haven't defined this
newWishText property inside of the class. But even after we do that,
we will still end up with an error. So let's hop on over to the browser,
and let's see what that error is. It says that it can't bind ngModel since
it isn't a known property of input. Now, if you rush on over
to the documentation, it's not going to give you any hint as to
why you are getting this particular error, which is frustrating,
but it is what it is. So instead, what we need to do
is open up the app.module file. Now, we haven't talked about this file,
because we haven't needed to, but now we do. This is a very important file,
because it defines practically everything that our application
requires in order to run. Now, the first three statements
are import statements. It's importing the NgModel decorator. It's importing this browser module,
which if you hover your mouse over, it says that it exports required
infrastructure for all Angular apps. So it's required infrastructure for
our app and every other app. But then there's also the AppComponent, which is the component
that we are working with. But notice the use of
the NgModel decorator. There's an object that's passed
here that defines the declarations, the imports, providers, and bootstrap. So first, we have declarations. This is a set of components or directives
that belong to this particular module. So in the case of our application,
we have this AppComponent, which belongs to this module
because it has been declared here. The imports are things that are available
to the templates, inside of this module. The providers are objects that can
be injected to parts of this module. And then bootstrap is essentially
what is bootstrapped. This is the entry point of the module. And so in our case,
once again, it's AppComponent, that's the entry point of this module. So what we need to do in order
to use the NgModel directive, is import the FormsModule, and
Visual Studio Code is being very helpful and allows us to
import that with a single click. That comes from @angular/forms. By importing the FormsModule, we now
have access to that NgModel directive. Not just inside of our AppComponent,
but for any other component that we would
define inside of our application as long as it is part of this AppModule,
and then the error goes away. So we are now a step closer
to making this work. Let's go back to our component code, and
let's do something inside of addNewWish. So we have now bound this newWishText
property to that input element. So whenever the value of
that input element changes, it will be reflected here inside
of this newWishText property. So we want to add this
newWishItem to our items array. So we will simply create a new WishItem,
the text is given to us, thanks to that NewWishText property,
and the Boolean value signifying whether or
not the wish is fulfilled as optional. And I would imagine that to any new wish
would just be unfulfilled by default. So that's all that we should have to do. And then we could set the value of
newWishText equal to an empty string. Essentially clearing out that value so
that the user can then have a fresh form and they could type in
a new wish if they wanted to do that. So let's go back to the browser,
and let's test this out. We wanna wish of $100 billion. I think that's right, and
[LAUGH] let's click on Add Wish. Okay, well,
a wish item was added to our list, but there's no text there whatsoever. So let's pull up the developer tools,
and let's take a look at the console, because it's going to give
us a very descriptive error. And we can see right here,
if ngModel is used within a form tag, either the name attribute must be set, or the form control must be defined
as standalone in ngModel options. So this is a very simple fix. We just need to go to our template. Let's add a name attribute
to our input element here. And it doesn't matter what this is, let's
just give it the name of newWishText, or let's not. Well, let's still do newWishText, but let's use hyphens in between
the words there, just so that we can see that there is no
relationship between the name and the property that is bound
to this input element. So with that simple change,
we can go back to the browser. We want $100 billion. And whenever we add wish,
there we have that wish item. And so,
now that we have this functionality, let's go back to our component. Let's comment out those
hard-coded wish items because now we have the ability
to add items on the fly. And this also gives us
the ability to actually test and make sure that this application is going
to work how we would expect it to. So, let's go back to the browser. I do want to add another div
here with a class of row. Let's also set some
margin to the top here. And this div element is going to serve
as the container for the content or rather for the list, I should say. So we'll have our list
inside of this div element, we'll also have that message if
there are no wishes to display. Just so that there's a little bit of
white space between that and I like that. So, now I wish for coffee, and voilà our application
is working as intended. Sometimes when you use ngModel, you want to be notified when
that model values changes. For example, in the previous lesson,
we used the ngModel directive on our input box so that the value of this input box
is bound to a property in our component. And so, we could also set this up so
that as the user types, we are notified of that change and
we get that value. Now, I don't necessarily want to
do that for the input box, but I do want to use this functionality
to implement a filter. So that the user can filter the list so
that they can see all of the wishes, only the fulfilled wishes, and
also only the unfulfilled wishes. So, the first thing I want to do is
uncomment these hard-coded wish items because this gives us
some data to work with. And we don't have to manually, [LAUGH]
add them every time the page reloads, that would be rather annoying. The next thing I want to do
is add the markup for the UI. And this is going to be just a simple
select element that has three possible options, all,
unfulfilled, and fulfilled. Now, the values are arbitrary, we can technically use any string
value that we would want to use. I opted to use numeric values because
I figured that that would be a little more simple. And since we're here, let's go ahead and let's use the ngModel directive to bind
this to a property on our component. Let's just call it listFilter
because that is exactly what it is. Let's go ahead and
define that inside of our component. I'm gonna put this after the items array,
and this is a string because the value
of this listFilter model comes from the options value attribute,
which is always a string. And we're going to initialize
it as an empty string. Now, let's go to the browser and we are,
of course, going to see this combo box. Notice that there is nothing
selected by default and that makes perfect sense because
if we look at the markup, there was not the selected flag
on any one of these options. So, of course it's not selected. However, since this is now bound
to this listFilter property, we can use this value to set the default. So, I think all should be the default,
we can set the default value to 0 and that is going to automatically select
the all option in the combo box. If we set it to 2,
then that would set it to fulfilled. I guess some people would want to see
that by default, but I don't think so, I think all is a good starting point. So, now that we have that all done,
we need to set up our select element so that it uses a special
event called ngModelChange. This is an event that only
occurs when the model changes. So you can only use this event on
elements that use the ngModel directive. Otherwise, it's pointless because it
is only for when the model changes. And that's not the only
special thing about this. The events object for this event
is not your typical event object. This contains the new value of the model. So as the user selects a different option,
the value of that option is going to be passed
to whatever method we choose, which I've called this filterChanged and
this dollar sign event is that value. So let's go ahead and
define this inside of our component, and we can write out that
value to the console. So I'm gonna call the parameter value,
I'm going to type it as any. And then we will simply
write out that value so that whenever we go to the browser,
by default, we're not going to see anything because
the model value hasn't changed. However, if we change it to fulfilled, we can see the value of 2
being written to the console. If we change it to unfulfilled, we see 1. If we change it back to all,
we see the value of 0. So, we can use this functionality
to essentially filter the items that we see in the browser. However, we don't want to
actually filter the items array because this is our single source of
truth when it comes to our items. So what we could do is have
a visibleItems property, which will be essentially
a copy of our items array, except that this will
contain our filtered items. So we will initialize it
with the items array. And then inside the filterChanged,
you will set a new value for visibleItems. And of course, that's going to be based
upon the new value of our listFilter. So, if it is 0 then of course the visible
items will be all of our items. Then we can have an else if to check
if value is equal to the string of 1 in which case, we'll set visible
items to a filtered list of items. And that filter is going to be
based upon if the item is not completed because this is for
showing unfulfilled wishes. And of course,
if neither of those cases are true, then what we want to do is
display only the fulfilled items. So there we go. All we need to do now is use our
new visibleItems in our templates. And really we want to do this
in two places whenever we check the length of the items. Because it's possible that
the user will select a filter and there will not be any wishes to display, in which case we want the message
to say that there are no wishes. So we will want to use visibleItems there. And then whenever we display
the list of those items, we only want to show the visibleItems. So, let's go to the browser and
let's check this out. Of course,
we are displaying all items now, but let's change the filter to unfulfilled. We see unfulfilled. Let's change it to fulfilled and
we see the fulfilled item. Now, on the surface, it looks like
this is going to work for us, but there's quite a few bugs here
that we would need to sort out. First of all, I have unfulfilled selected. So of course,
we only see the unfulfilled items. So, we want to wish for $100 billion. And whenever we add this wish,
we don't see it listed here. And the reason is very simple,
because while we did add that wish to the items array,
the visibleItems array, Was not updated. So if we refresh this filter and go back to unfulfilled,
then we will see that item. The second bug is that if we complete or
uncomplete any one of these, once again, it's not going to
automatically update what we see in the browser because we have to
essentially change the filter so that the visible items array is
updated with the new set of items. Now those are bugs that we
can pretty easily fixed. We would just need to apply
the filter anytime that the main items array was changed. However, there's a better approach. We can turn our visible items array
into a getter, which will allow us to react to just about any change that
we make to the original items array. And we'll look at that in the next lesson. In the previous lesson, you learned
about the ngModelChange event and how you can use it to react to
when the ngModelValue changes. And it's a wonderful tool. It's something that you'll use
quite regularly, I would imagine, in your applications. However, I don't think it
was the appropriate tool for us to use to implement our filter. Because if you'll remember,
I talked about two bugs. And we could get around those bugs
with minimal effort because all we would need to do is be sure that the
visible items array was updated any time that we made a change to the items array
or to the objects inside of the array. And so instead, what we can do is
use a feature not from Angular, but from JavaScript, we can repurpose
the visible items to be a getter. So that it returns an array. But that array is of course,
going to be dependent upon the filter. It's either going to return all or
the items, only the fulfilled items and
only the unfulfilled items. So we can essentially take the code
from our filter change method, and we can paste that inside of visible items. But let's do this. Let's create a variable core value, we will initialize it with
the value from the list filter. That way we don't have to change
value all of the time, and instead of setting a value here,
all we need to do is return. And the beautiful thing about this
is that now we are basing everything off of the items array so that anytime
that the items array is modified, or the objects inside of it are modified, it's going to automatically be
reflected within the browser. We don't have to write any
extra code to make this work. Now, unfortunately, this means that we
don't need to use the ngModelChange event. So we can get rid of that
FilterChanged method. We can also get rid of the ngModelChange
event on our select element. But with that very simple change, we are
going to have the functionality that we wanted, and we aren't going to have the
bugs that we had in the previous lesson. So let's go to the browser. Of course, we see all of the items. Let's make sure that the filtering works,
which unfulfilled works and fulfilled works. So the first bug was adding an item. So let's go to the unfulfilled items and let's add in our wish for $100 billion. And whenever we add this item, it should automatically populate
here in our unfulfilled item list. And it does. So that's perfect. That worked exactly as it should have,
and we didn't have to write any extra code to make sure that the visible
items array is in sync with the items, because now visible items is completely
dependent upon the items array. So now let's test the other bug. If we uncheck Get Coffee, that should
disappear from this list and it does. We see our message saying that
there are no wishes to display and if we view the unfulfilled of course,
Get Coffee is there. If we check this again, it should
disappear and if we view all of them, then Get Coffee will be
the only one selected. So there we go. We have our filter completely implemented. We don't have to do anything extra to
get the functionality that we want. Now, I think we can make our code just
a little bit cleaner if we do something like this. I'm going to define
a variable called filters and this is going to be
an array of our filters. So basically what we want are functions
that are going to be used as the callback for the filter method. So that for index 0,
that is to display all of our items, a callback method is simply going
to have something that's truthy so that it will display everything and
that's going to work. Let's type our parameter
here to wish item, and let's use this as a basis for
the other filters. Now the second filter is for
unfulfilled items so we want to check and make sure that is complete as false, otherwise we want is complete to
be true for the fulfilled wishes. So that's inside of our
visible items getter, we can essentially get rid of all
of this code and we will do this. We will return items,
we'll call a filter, but then we will use the filters and
the index is going to be the list filter. So this should work or maybe it won't, but we might have to change list
filter to any, so let's do that. Let's go back to the browser. Let's try this out. So of course, all works. Unfulfilled, appears to work. Fulfilled, appears to work. If we uncheck Get Coffee, that disappears. There it is. Let's add an item. I'll be happy with a 100,000. So let's do that. Let's add it, and voila. So there are times when using
the NGModelChange event is appropriate. There are times when it's not appropriate. And for our filter feature, a simple
getter was the appropriate approach. We haven't really done a whole lot with
our application, but already things are becoming a little cluttered, both from
the code aspect as well as the template. And we essentially have
three distinct pieces. If we really think about it,
we have the user input, we have the filter and then we have
just displaying our items array. And the reason why I say that these
are three distinct pieces is because they essentially have their own functionality. The user input is strictly for getting
user input and modifying the items array. The filter is for, well, is for
filtering the items array and then the list is for
displaying the items array. Now, of course, they all have
that items array in common, but they do different things with it. So first of all, it's very easy to
get stuck in the mindset of only creating components for
things that can be reused. And yes, it is perfectly fine to
create components that can be reused, but we use components for
a variety of different reasons. Most of all, we use components because it
organizes our application Into smaller pieces, which makes it easier to develop
and maintain and add more features. So starting in this lesson,
we are going to create three components, one for each of the three
pieces of our application. And in this lesson,
we're going to start with just the list, because that's the easiest
thing that we can do. So essentially what I want
to do is take the list out. Now it's more than just the list. It's also the message that will
display that there are no wishes to display because I think that the list
should be responsible for that. So I wanna take this out so
that here inside of our app component, we would use something like this. It would be simply wish-list, and
then we could supply the visible items to a property on this
component called items. So we would have visible items just like
that, bound to a property called items. And then that simplifies
this component's template. And it will also help simplify
the code for this component, because the toggle item method
can be extracted out and I think that is the only thing that we
need as far as displaying those items. So now let's create that component. We can do it manually but there are steps involved if we
are creating the component manually. Not only do we have to create code for it
but then we have to import components so that we can use the component decorator so
that we can define the selector and the template. We don't necessarily always need CSS,
but it could be useful. But we also need to modify the module
file because we need to import any new component that we add so
that we can declare that so that we can then use it
within our application. Because if we don't declare it, then it's not going to know
that that component exists. So it's a lot of things
that we have to do and thankfully the Angular CLI gives us
the ability to generate a component. We use the ng command, we follow
that up with generate component, and then we specify the name
of that component. I'm gonna call this wish list,
which is going to make things much more confusing because our
application is called wishlist. But for something that
displays the list of wishes, I can't really think of anything
better as far as a name is concerned. Now, here in the command line, we can see that there are four
files that were created. They are inside of a directory called
wishlist which is a subdirectory of app. And we have a template,
we have a spec file for test, we have the code file and
then we have the CSS file. So all four of those files
were automatically created for us and then the module was updated. So let's take a look at that and we will
see that on line six we now are importing that wish list component and on line 11,
it was added to the declarations. So we didn't have to do any of that,
the angular CLI did that for us. So great. I love tools that make our lives easier. So now let's go to our
wish list directory. Let's open up the template. I'm going to paste in that code that I
took out of the app components template, because this is essentially the template,
for this new wishlist component. Now, this isn't working with
a property called visible Items this is going to work with
a property called Items. And the reason why is because well,
that's what I want to do here when I changed the apps template to just wish
list and to use this items property. We can make this whatever this is
completely arbitrary, but for me, personally, it makes
sense to call this Items. I guess we could call it Wishes
if we wanted to do that. And let's do that. That actually might be better. So let's go back to the Wishlist template,
and let's change that so that we will be working with. Wishes instead of items and
we also need this toggle item method. So let's go to the apps code let's
take out that toggle item method, we're gonna cut that out and
we're going to paste it inside of the wish lists component and we also need
to import the wish Item class. Now, we still need that inside of the app
component, so we're gonna leave it. We're just gonna copy that
line where we import that and we will paste it inside of
the wishlist component. And so now we just have
errors inside of two files. One is the app components template,
so let's take a look there. We're going to see that the error says
that wishlist is not a known element, and that's interesting
because we just created it. However, if we take a look at the wishlist
component notice what the selector is. It is app-wish-list. That's a little difficult to say. The reason why we have this app prefix
is because this is the app module. So some people leave that. I typically don't unless if there's
some kind of naming collision because that's exactly what this is for. This is to help avoid naming collisions
but we're only going to have one wishlist. So let's just call it wishlist so
we'll save that we can go back to the apps template and we're going
to see that that error goes away. So we're good there, but
we still have another one that it can't bind to wishes since it
isn't a known property of wish-list. Well, that makes perfect sense because we
haven't defined a property called wishes. However, it makes us think that we
could get away with doing something like this to where we define that
property which is going to be typed as an array of wish items and
that's going to get rid of one error because we had the same error
inside of the wishlist's template. If I took out that wishes property, then we would have an error on
line one where we used wishes, we would have another error on line seven,
where we used wishes as well. But that didn't take away
the error from the app component. It still says, can't bind to wishes. Well, here's the thing about
components that have input. Now the way that this is written, we are providing input to a property
called Wishes for the Wishlist component. But we have to explicitly
say that wishes is input. And we do that by going back
to our wishlist component. And we are going to use
an input decorator. We need to import this
from Angular core and then we simply decorate the properties
that we want to use as input. So wishes is going to be input. So we will use the input
decorator before that. And by just that simple change,
the error goes away, we can see that our application compiles. And whenever we go to the browser, well, it doesn't look the same because
the styling is a little bit different. And we did add some CSS, didn't we? So let's open up the CSS for
the app component. Let's take out this wishlist class, and we're going to put that inside
of the wishlist components CSS. Because it makes sense to put this here. This is for the wish-list itself,
so we can go back to browser. And you're seeing those dots and
then seeing them gone does kind of accentuate how
our list is indented over. So let's get rid of that padding. So we'll set padding zero and
that should scoot that a little bit over. And it does. I would like that to be flush, but well. So everything works as it did before but our application is just
a little bit more organized. And in the next lesson, we are going to improve that organization
even more by creating another component. The next piece of functionality that we
will extract into its own component is the form at the top of our application,
so the user input form. So that whenever they type into the text
box, click on the Add Wish button, of course everything will
still work as it did before. Now, this is going to be a little bit
different than the wish list because there is no input,
at least as far as The form is concerned. There is, however, output. Because when the user clicks on the Add
Wish button, our component needs to tell the app component, that, hey,
I have some new data for you to work with. And the way that we do that is by
essentially creating an event. So let's, first of all,
generate our new component, and let's just call it add-wish-form. To create an event, we have to use
what's called an event emitter so that we can emit or fire that
event whenever we want to emit it. So let's start with the template here. Let's cut this out of our
app components template, and let's write out what we want to do. So we'll have the add-wish-form, and
we want to bind an event to this. So we're going to use
the event binding syntax. And whenever you think of event names,
they are typically actions, first of all. They are also typically in the present
tense, such as click, mouseOver, mouseOut, keyDown, things like that. So let's call this event addWish, and then we will have some code that's
going to execute whenever this happens. So let's go to our Add Wish form. Let's open up the template, and
then let's paste in the form. And I don't think there's really anything
that we need to change as far as this template is concerned, because we still
need this newWishText for the model. We still want to execute some code
whenever the user clicks on this button. So we still need to handle the click
event and emit our own event. So we'll leave this as is. So let's go ahead and close this file. So let's extract the code
from our component. So we essentially need to cut out
the newWishText and the addNewWish method. So let's just cut that out, and let's put this inside of the code for
our new component. Now let's change the selector. I want this to be just simply,
add-wish-form. And we need to address line 18 here because we now do not have
access to the items array. In fact, as far as this component is
concerned, the items array doesn't exist. So this is where we will emit our event,
but, first of all, we need to import two things. We need the output decorator,
so just like with an input for a component,
we have to decorate output as well. And then we need to import
the EventEmitter class. Now one last thing we need to do
is import the WishItem class so that we can work with
that inside of our file. And that should be it, so
that now all we have to do is just write the code that's going to create our
event and then emit that event. So we'll start by using
the output decorator. We use it just like the input,
except, well, it's called output. And then we have the name of our event,
which was addWish. And we're going to new up
the EventEmitter constructor. And we can specify the type of event
object that we are going to pass to it. Now, here we can do
several different things. We could say that the event object is
going to be the text from the text box. We could say that we are going to
pass a brand new Wishitem object. And I think that that's
probably the best approach. So that whenever we emit
this addWish event, we will pass it a new wish item object
that contains the new wish's text. So that's whenever we call
this addNew wish method, we will use this addWish event. We will emit it, and
then we will pass in our Wish item object. So that should be it as far as
this component is concerned. So now the only other thing that we need
to do is actually do something whenever this addWish event occurs. So let's go to our app component. Now we could define a method, we could
say that we want to call a method, addWishToItems, and then we can
define that inside of our code. However, with something as simple as this,
it would be far easier and probably more readable to just do this. We will push into our items array,
the event object, which is a wishItem. So let's save this. It does look we have an error inside
of the template for our wish item, but okay, that went away. So let's go to the browser. Everything looks it's
working like it did before. Let's do a hard refresh just to make
sure everything is loaded as it should. And then let's type in a new wish. I want $100,000, so
I'm going to wish for this. We're going to add it, and
there it is in our list. And, of course, the filter still works because we didn't
change any of that functionality. So now let's very briefly to
look at our app components code. Now of course we still have a lot of
things here, but little by little, as we start breaking out that
functionality into other components, this becomes much more cleaner. And as we start breaking
out the functionality for the filter, the code for our app
component will be very, very clean. Extracting the functionality for the filter is going to be
relatively straightforward. In fact, it's going to be very
much like the add wish form, in that we won't have any input,
we will have an output, because the app component needs
to know which filter is selected. And in order to make all of this work, we are going to lean on
the ngModelChange event. Now, if you'll remember, we originally
used ngModelChange to implement the filter, and we ran into some issues. And in this particular case,
we will run into issues, but it will be very easy to fix. So let's create a component,
we'll just call it wish-filter. And let's start with the template. So we want to extract
practically everything here, except for this containing div. That isn't necessarily part of the filter,
that's more for the structure of the page. So everything inside of that,
we'll just cut out, and let's say that we will have
that wish-filter component. And we will listen for an event,
I guess we can just call it filter, and then we will do something
whenever that occurs. So let's hop on over to our
wish-filters templates. Let's open up that file. Let's paste this in. And for the most part,
everything is going to be the same. We still need the ngModel for
our select element because we need to know what the value is for
that form control. But we are also going to use
ngModelChange, and we can go ahead and define a method called changeFilter that
will give us the new value for our model. So let's take this method name and define that inside of our code so
that we have it. And this is going to be useful for us because this is where we
will emit our filter event. So let's go ahead and write that code. Of course, it's not going to work because
we haven't defined that filter event yet. And we don't necessarily know what we
want to emit at this particular point. Well, in fact, we do. We want to emit the callback
function that's used for the filter method on the array. So there's a few things we need to
port over from the app component. First, we need to import wish-filter,
so let's go ahead and do that. We also need these filters,
so let's cut that out. We don't need that inside of app anymore. That's going to be inside of our wish. Filter component, so
we'll paste those in there. And then we need this list filter. We don't need that inside
of our app component, so that should be it as far as
what we need to port over. Let's change the name of the component
to just simply wish-filter. And we need to import the output
decorator, as well as the event emitter. So that we can define our output,
which we called filter, and we will new up the event emitter class. As far as the event object,
let's just use type any. That way we can pass anything
to it like a function and that should be good there, so
that whenever the filter is changed, we will just simply emit the given filter. And that should do it for
this file, at least for right now. So let's go to our app component. Now, one thing we do need to keep track
of is the filter that's going to be applied for the visible items. So we can go ahead and
we can define that property. We can have it set as type any, and
we can initialize it as a function so that we could go ahead and
we could pass that filter to VisibleItems, or not pass it but
use it inside a visible item. Now I don't think we
need the title property. Let's get rid of it. We should have done that a long time ago. And we do need to change
the value of filter, but we can do that inside of our template. So that whenever we bind this filter
event, we could just go ahead and say filter, is equal to the event object. So it's declarative, as we are reading
the template we know, well, we mostly know what's going on. And it should work, but not exactly. So here we are, we get the message that
there are no wishes to display and we know that there are wishes to display. And we also know that
the all filter is selected. So we should be seeing something here but
whenever we change the value of the filter,
we can see that it's working just fine. So this is the problem that
we are going to run into. And the reason why we
are experiencing it is very simple. It's because of this. Line 19, we initialize the filter
as just an empty function. And so when that is passed to
the filter method on the items array, it's returning undefined. Therefore, none of the items
are being selected for visible items. So we can get around this in
a couple of different ways. We could just return true for
the filter and that is going to be
a very quick fix there. However, I don't necessarily
like that approach. Instead, I would prefer to rely
upon the filter component to automatically provide a value
to the filter inside of app. And the way that we can do that is
by going to the components code. Now, if you'll notice, for
every component that we've created, it has implemented OnInit. And it has provided this
ngOnInit callback method. And you can think of this essentially
as this is the initialization for this particular component. So what we could do here is call change
filter, and then pass in the string of 0. Or we could emit the filter event,
passing in the first filter. Either way, it's going to get the job
done, so that whenever we save this, we go back to the browser. Let's do a hard refresh in the browser,
and we can see that it's working as it should. The all filter is being applied to
the list of items automatically, and of course the filter
is still going to change. If we modify any one of these items, we can see that the item list is
still working as it did before. The same is true for whenever we add
a new item, so we want that, okay, I'll take $1,200, so we'll add that wish,
it's automatically added to the list. Now one other thing,
let's go to the app component. We could get away without defining
this visible items whatsoever. It's useful to have it here, but
one of the things that we have been doing as we have created these other
components is to simplify everything so that a lot of the functionality
is defined declaratively here in the template as opposed
to programmatically. So instead of using visible items here, we could simply filter the items
based upon our filter, which means that we will be able to
completely get rid of the visible items so that the code for our app component
is now I'm not gonna say it's the cleanest that it could be,
but it's pretty darn close. And just to prove that this works,
let's hop on over back to the browser. Let's do a hard refresh and we can see
that the filter is automatically applied. If we change the filter at all,
we get the results that we would expect. Over the past few lessons,
we have discussed inputs and outputs on our components, but we haven't necessarily talked about
how data flows from one to the other. And even though it is very simple, it's
also important to understand this concept, so let's take a look at
the app component markup. And I want to focus on where we
use the wish list component. So in this case app is the parent,
wish list is the child. And wish list has a property,
it's the input. And we are binding the items
from the app component, the parent, to that wishes property. So in this particular case the flow of
data goes from the parent to the child, and there is no limit as to how far down
we can keep passing that information. Like for example later on we are going
to create another component, one that represents
an individual list item element inside of the unordered
list in our wish list component, where we will take the individual
item that we are working with and then pass that data on down
to that child component. So you can keep passing data
down as far as you need to for as long as you need components that
need to work with that information. So let's go back to the app component and let's look at the add wish form and
the wish filter. Now we created events that emit
data whenever those events occur. And that is setting up the child
to parent communication. So with inputs, the information
flows from parent to child, for output, the information
flows from child to parent. But let's open up the filter and
let's look at NG model. Now, of course,
we've used NG model in other places, but we are going to focus on the wish filter
component in this lesson once again, because ng-model is a little different. Even the syntax suggests that it is,
because it uses both the property binding as well
as the event binding syntax. So that seems to imply that this
is a two-way binding, and it is. We have seen that happen. So what I want to do is
modify our wish filter so that it too has a two-way binding. And the reason why I want to do it
here is primarily because of what we do when this filter event occurs. All we are doing here is setting
the app components filter property equal to the filter that was
provided through the event. It's very simple, so in this
particular case it would make a lot of sense to set up some kind of two-way
binding And we can do that very easily by just using both input and
output within our component. So the result is going to look like this. Not only is it going to
simplify our template, but it can also simplify the code
in our component class. So that all that we really need to do
is just define the filter property, say that it's going to be of any type,
and we're good to go there. So we can actually close app component and
its templates. And then we will focus on
the wish filter component. In fact,
let's open up the class because that is where we are going to
spend most of our time. So in order to create or
to set up a two-way binding for our own components, we need both
the input and the output decorators. The input is going to
be the property name. So in this particular case, it would make
sense that we call our property, filter. I'm going to go ahead and
say that this is of type any. We don't have to initialize
this if we don't want to. We can, but in our particular
case there's really no need to. Now, of course, setting up two-way binding
means that we have an input and an output. So we need to change
the name of our outputs, but there is a rule that we have to follow so that the Angular will recognize that the
input and the output are linked together. And that is, the output has to be
called the same name as our input, followed by, Change. And whenever we do this and save this, the error inside of the app
component should go away. Because Angular should now recognize
that this is a two-way binding. There is the input and the output,
but that error is not going away. So let's take a look and
see what this says. It did go away. I just wasn't patient enough. Now, of course,
because we changed the name of this event, we're going to have to adjust our code. And I'm not so necessarily sure that
I want a filterChange event and then a method called changeFilter. So let's call this updateFilter. And whenever we update the filter,
we essentially want to do two things. We want to set the filter property equal
to the new value that it should be. So in this particular case, it's going to
be the given filter at the given index. And then we will emit
the filterChange event. We will pass in the filter
property as the event object, and that is going to make this work. Now we do have this OnInit, and
instead of emitting the filterChange, what I want to do is
call the updateFilter. I'm going to pass in the string of 0, that is the default filter
that we want to display. And then we need to update
the template for our WishFilter so that it will call this updateFilter
method on the ngModelChange event. But with that in place, we will have the
same functionality as we did before, but our code is going to be
a little bit cleaner. So, here, of course, we have our UI. The default is the All filter. Let's change it to Unfulfilled. Once again, we see the unfulfilled items. And if we change any one
of these check boxes, that list is going to
automatically update. If we add a new wish, then that
will of course update the wishlist. So let's briefly talk
about how this works. So let's go back to our app component, and here we define this filter
property of type any. And we are binding this to the filter
property on the wish-filter. So when our application first runs, it's going to take the value
of this filter property, and it's going to pass that down to
the child's filter property. So initially, the input filter on
the WishFilterComponent is undefined. Not necessarily because we don't
define anything here, but because it is bound to that filter property in
the app component, which is undefined. However, when ngOnInit executes,
we update the filter. And when we do, we change the filter
property to the given filter. We emit the filterChange
event with that new filter, that in turn updates the filter
property on the app component. Now, of course, we don't want to set
up two-way binding on anything and everything, only where
it makes sense to do so. Earlier, I mentioned that I want
to extract the functionality for the individual items in the wishlist
component into its own component. Now this is not a requirement. There's nothing that says
that we need to do this. However, from my own personal preference, if I can extract something into
a component, I typically do so just because that makes my application
a little bit easier to maintain. And a lot of times, I end up wanting that
functionality because I will need to add features or something. Now, I am a firm believer in not writing
code that I don't need to write. But there's just something
about extracting functionality into components that I
just can't get away from. So, what I want to do is this. So that instead of using the li
elements here Inside of our list, we'll have a wish-list-item. And the first thing that
we need is a for-loop here. So we won't need this for the li element. So let's just lift out
that ngFor directive. And really we don't need the index either. That was primarily for
demonstration purposes so that we could have something to bind
to the custom data-index attribute. So let's just get rid of that. We can also change this
item variable to wish, just to keep things consistent
from a terminology standpoint. But then we need to supply the information
that we want this wish-list-item to work with. And we can take one of two ways. We could have a property called wish
that we bind the individual wish to, or we can provide the different
pieces of the wish. For example, we could have a wishText, which we would bind to
the wish's wishText. But then we can set up a two-way
binding for the isComplete property, and we can call that fulfilled,
and that will be isComplete. And let's take this approach because
this gives us another opportunity to practice two-way binding. And when it comes to determining
how to pass data to a child, there are no hard and fast rules. It really just depends upon what your
particular needs are at that given time. And so I think that this
is a worthy goal to attain. So let's create that component
with ng generate component. We'll call it wish-list-item. And let's go ahead and
let's cut out this li element. And that's going to be the template for
this component. Now, of course, we are going to need to
massage this template just a little bit, just to be able to work
with the properties. Because we don't have the individual wish
object anymore, we have just the pieces. So we will have the wish text there, and
we'll leave everything else temporarily because I'm not exactly sure how we are
going to implement this on the code side. But we do need to first of all
import the WishItem class. So let's pull that in. Let's also change the name
Of this selector, so we will get rid of that app prefix. We also need to port over the toggleItem, although we are going to need
to make some changes to that. But then inside of our WishListItem,
we can go ahead and we can define our input and output. We, of course,
need to import those decorators. So we will have that. We also need to import
the EventEmitter for our output. So for the Inputs property,
we first of all need the wishText. Now, I'm not going to initialize this with
any particular value, primarily because there's no need to, because it's
going to be supplied by the parent. So I'm going to use the bang or
the exclamation point, or the technical term is
the non-null assertion operator. But basically, this is saying that this
wishText property is a non-null property. It's primarily a trick for the compiler,
because if we omit this and we don't initialize a value,
the compiler is going to complain at us. But we know that this is not going to be
null because it's going to be supplied by the parent. So that's why we're using the bang. Then let's define the fullfilled property. This is what we're going to use for
our two way binding. And we can essentially do the same thing
by using the non-null assertion operator, but this is going to be a Boolean value. But then we also need the output and
its name will be fullfilledChange. And this is a new
EventEmitter of type Boolean. Now, whenever we click on the checkbox, we
want to reverse the value of isComplete. So what we'll do here is
essentially the same thing, but we are going to use
the fullfilled property. So we will set fullfilled
equal to its opposite. And then we will emit
the fullfilledChange event, and we'll pass in the new value for
fullfilled. This means that we no longer
need the item parameter because this is working strictly
with class information. And let's change this, instead of
toggleItem, it'll be toggleFullfilled. And so now that we know how we
are going to make this work, we can go to our Components template,
and let's change will be called toggleItem we want to
call the toggleFullfilled method. And the checked value is going to
come from the fullfilled property. And I think that's gonna be it. We should be able to do everything else. Let's make sure that our
wish list template is okay. We look like that we are good to go. So let's hop on over to the browser. Let's do a hard refresh to
make sure everything's loaded. And hopefully, we are going to
see the same functionality. So at least as far as our All filter,
everything is looking okay. Let's go to Unfulfilled, we see only one
item, which that is what we would expect. Let's click on that. It goes away. So it looks like we
haven't broken anything, which that's always a worthy
goal to strive for. And now that we have extracted all of that
functionality into its own component, I want to do some things with style. Because, yes, it's nice that we have
this check box, and that is a very useful visual cue to tell the user,
hey, this item has been fulfilled. But I want to do a little bit more. I want to add some styling so that it's very clear that an item
is fulfilled or not fulfilled. So in the next lesson,
we will look at manipulating style. One of the great things about
graphical applications is that we can convey information to the user
without using any text whatsoever. Like for example, we have a checkbox to
denote whether or not a wish is fulfilled. If it's checked, of course,
it is fulfilled, if not, then it is not fulfilled. And it can't get any clearer than that. However, I want to add some extra
styling for fulfilled items. I want to strike out the text and make
the color of the text just a little bit different, just so that there's even
more difference between the two states. Now, when it comes to manipulating style,
we as an industry, and I just mean in JavaScript and client-side
development in general, we have decided that manipulating classes is typically
the best way of manipulating style. It's not just an angular thing. It is an industry-wide thing. So let's define a class called strikeout. This will have
the text-decoration property. We will set it to line-through. And now we just need to
apply this class for the label elements for fullfilled items. And the way that we do that is
with a directive called ngClass. Now, this uses the square bracket syntax. So this implies that we
are binding something to a property called ngClass on label. And that is exactly what we are doing. So that means that whatever
we use as the value for this ngClass attribute has to
be a JavaScript expression. So that means if we want to
assign a single CSS class, it would need to be a string. So we surround it with a pair of quotes. Let's save that. Let's go to the browser, and we're going to see that all
of the items are struck out. That's great,
except that that's not what we want. We want only the items that are fulfilled. So we can accomplish this in
a couple of different ways. The first thing that we could do is use
a ternary statement, because remember, this is a JavaScript expression, so
we could check the value of fullfilled. And if it is fullfilled,
then we will apply the strikeout class. Otherwise, we won't apply any class. If we go back to the browser, we are going
to see that that is indeed what we get. And whenever we change the state
of any one of these items, the strikeout class is either applied or
it is removed from the label. And that's great, but
this is also slightly difficult to read. There is something to say about
defining CSS declaratively. But when it comes to the template
of a component, I prefer concise, easy to read templates as opposed to
using a lot of JavaScript expressions. So what we could do is define
a property in our component. Let's define a getter. And let's just call it cssClasses. And for right now, we are going
to return the result of checking the fullfilled property and
returning the appropriate string. So now we have this cssClasses property
that we could use to bind to ngClass. And whenever we view this in the browser,
we are going to get the same result. Whenever we change the state
of any one of these wishes, that strikeout class is applied or
it is removed, and that's great. That's phenomenal. We can also add in the text-muted class. That's coming from Bootstrap, and that's going to give us slightly
different colored text. So you can see that the Get Coffee wish is
muted as opposed to just the normal text. But when it comes to applying multiple
classes, we have multiple options. Yes, we can take this route and
use a ternary. But we can also define our
classes using array so that each element in the array is a class
that we want to apply to the element. Now let's be good developers here,
and let's return the same type. So we will return an array for cssClasses. One will be empty, one will have the
classes that we want for fulfilled items, and here we can see we
have the same results. That's fantastic as well. But we can also do this. We can return an object. And this is very useful because instead
of using a ternary expression, this allows us to just return an object where
the property names are the CSS classes. That we want to apply. So we could have strike out, and then
the value is a conditional statement that determines whether or not that CSS
class will be applied to the element. So we'll say that we want to
apply the strikeout class based upon the value of the fulfilled property,
and then we could essentially do the same
thing for text muted if we wanted to. So let's go ahead and get that set up, so that whenever we view this in the browser,
we will see the same results. But we can also make that approach just
a little bit easier, because we could use both or all of the CSS classes that we
wanted to apply based upon that condition. So now our code is just a little bit
easier to read, at least In my opinion, that we want to apply these classes based
upon the value of the fulfilled property. So once again, sanity check, let's make
sure everything works, and it does. So when it comes to
manipulating CSS classes, There are many different
ways that you can do it. You can use just simple strings, you
can use arrays, or you can use objects. I think I say this a lot,
but there are no hard and fast rules as to which is more
appropriate than the other. It really just depends upon your use case. I want to add the functionality to remove
individual wishes from the wish list. So this means that we need to add
a button for each item in the list, and then whenever we click on that button,. We issue an event. Now, the issue here is that we
have the wish list item component which contains the functionality for
the individual wish items. That's how I wanted it. But if we need to manipulate the array
of wishes we have to do that inside of the app component because
that's where it is defined. So these two components
are not directly related so we can't necessarily define an event here
inside of the wishlist item component and then listen for
that in the app components. Now we can accomplish this in two
different ways, the first would be to define a remove item event inside
of the wish list Item component, so that we can issue that event and
listen for it inside of the wish list. But the wish list itself really doesn't
care about that event because it gets its wishes from the app component. So there's really nothing
that we can do here except. A remove Wish event and then just
forward that on to the app component. So we would need to define that remove
wish event on the wish list item, and then on the wish list so that the app component
could listen to it on the wish list. That's not scalable at all,
that would be a nightmare, especially for very large applications when the event
occurs way, way down the component tree. So the more feasible option than is
to essentially create what's called an event bus. It's a global object that basically lets
you issue events from anywhere within the application, and listen for those
events anywhere within the application. And the way that we can do that
is by using observable objects. Now if you're not familiar with
the observer pattern that's very simple, you have an object that needs
to supply data to other objects. So those other objects subscribe
to the observer object, and then when those changes occur
it notifies the subscribers, if that sounds like
an event Guess what it is. In fact,
every time we have used the event emitter, we have used an observable object. Except that in this lesson we are going
to use the observable type directly. So let's go to the shared directory. Let's create a new folder there
we'll call it services, and then inside of that services we will
create a new file called event service. Now before we do anything here, let's go
back to the wishlist item component and let's modify our template here so
that we have our delete button. I'm gonna put this inside of another div
element and it's simply just going to be a button that uses the button
close class from bootstrap. This is going to automatically add that x,
let's go ahead and define the type attribute,
we'll set that to button, but remember that these divs
are block level elements. So if we look at this in the browser,
well, let's just go ahead and do that. We will see that the buttons are on
their own lines and we don't want that. We want everything together. So let's use Flexbox, so
we'll add the deflex class and then we will use the justify
content between, that's going to put as much white space
in between those two div elements. And you can see, there we go, but
the close buttons are way over there. So let's open up the app
components templates. Let's add another div element here, but we're going to use one
of the column classes. Let's say that for
the small size screen and above, we'll use the four column width. That should make this a little
bit easier on the eyes so that we could see which close
button goes with which item. That's a lot better. So with that in place,
we should be able to go ahead and define the click event on this button. Let's say that we'll have
a method called remove wish, and let's go ahead and define that,
because what I'm trying to get to is, writing the code that I want to write. Because when I do that, I find that and
I end up with much cleaner code. So inside of this remove wish, let's say that we're gonna have an event
service out just called simply events. And we'll have a method called emit, because that's typically what
we've been using to emit an event. And we will emit an event called remove
wish, but then we need to specify something identifying for
the wish that we want to remove. So in hindsight, going with the option
of providing the wish text and the value for fulfilled probably
wasn't the best approach. We should probably just use the wish
object itself as input we'll do that in the next lesson. For right now let's just get this
event bus working, so that we can have something to work with, so for
the remove wish event for right now. Let's just pass in the wish
text as our event object, so to speak, for this remove wish. Ideally, it would be the wish that we
want to remove, but we'll get to that. So the concept here is going to be very
similar to what we have with just normal events, in that we are going to
emit an event called remove wish. And then we are providing the information
involved with that remove wish event, which in this case is
going to be the wish text. And then let's go to the app component,
and let's go ahead and write the code that we will want for
listening for that events. So we can do this inside
of the constructor, so that we would have our events. And we would listen for the remove wish
event, and then we would have a callback function because that's
typically what we would have. We could define a method to do this, or we could just provide
the callback function inline, so that eventually we'll get the wish, and
then we will remove Wish from items, but for right now we'll just write
out the wish to the console, just so that we can see what that is,
let's go ahead and define wish as any. So that's the API that I want to use, so now we just need to implement that
inside of the EventService file. So the first thing we need to
do here is import two things. The first is called Observable,
the second is called Subject. Now you'll notice that this
is being imported from RxJS. This is the Reactive Extensions for
JavaScript, which Angular uses extensively. And in fact, it uses Observable
extensively, not just for events. Whenever we talk about HTTP requests, it uses Observable then It is
used throughout the framework. Now, Subject is a special
type of Observable object. This is essentially going to allow
us to emulate typical events, so that we can have multiple objects
that subscribe to our Observable object. Meaning that we can
issue a single event and then multiple objects can be listening for
that same event. So let's start by defining our class,
we'll call it simply EventService. We don't need to inherit anything, but we do need the Subject,
this is very important. We need the Subject which is going
to allow us to essentially pass messages from the Observable Object
to the subscriber objects. Now I use that term messages because
that's essentially what an event is, an event is a message. In fact, we use messages for
every piece of software that we write, we just might not see them
working behind the scenes. All right, so we have the Emit method
where we would have the eventName. We'll set that as a string and
then we would have the payload for that event, which will be of type any. And then we also have the Listen
method that has the eventsName, which is a string, but then we have the callback function
which we'll just call back function. And then we will define this
function as having an event, arguments and it will return void. Now emitting an event is going
to be very straightforward, we're going to use this subject and then anytime we want to emit an event
we call a method called next. We pass in the object that we want
the subscribers to work with. So in this particular case,
we'll have the eventName and then we will have the payload. So whatever object is going to
subscribe to an event is going to get an object with these two properties. But we're going to simplify it for
those subscribers because inside of listen we are going to use our subject and
there's a method called AsObservable. And this is going to give us
access to a subscribe method. And this subscribe method by
default accepts a callback function that will accept whatever
we pass to the next method. So whenever we emit any event
this next method, we'll execute, it will pass in this object that
has the EventsName and payload. That object will be passed to the callback
function for the subscribe method. So here we will have a callback that gets,
let's call this nextObj. It's a little bit more
telling as to what it is, and then inside of this callback for
function. We are going to check if
the given events name is equal to the events name
that comes from the nextObj. Because if those are equal,
then we want to call the provided callback function where we will simply pass
in the payload from the nextObj. It's a little bit convoluted, but
if we sit and think about this, then it makes perfect sense. So the object that is going to emit
the event calls the subjects next method. And it passes in the event object,
so to speak, that event object has the EventsName and
the payload. The object that is going to listen for
that event is going to use the subjects as Observable method, because this gives
us access to the subscribe method. So an object that is going to subscribe, we'll receive this event object
with the EventsName and payload. So we simply check if
the EventsName is the same as was provided to the Listen method. And if it is, then we execute
the provided callback function and then pass in the event payload. Now all we need to do is add
a reference to that service. So inside of the @ component,
that should be inside of the parents and then shared, then services,
and then EventService. Although, we need our events domain,
so let's go back to EventService, and we want to export
default new EventService. So there we go, that should fix the error
there inside of the app component. So let's copy that line, let's paste it
inside of the WishList item component. We do need to change this import path
because we are deeper in the directory structure, but with that in place,
we should be able to go to the browser. Let's open up the console and we have an error expression has changed
after it was checked, blah, blah, blah. That's okay for now,
that doesn't really affect us right now. So whenever we click on any one
of these buttons, we should see. Well we,
at least see something in the console. We see undefined, but
we don't see necessarily what we expected, I expected to see the text of the wish, so something somewhere is not
being passed correctly. So the first thing I'm going to
do is add Debugger for emits, and then we can do that inside of
the callback for subscribe, so we will add debugger there. So let's go back, and let's clear this out
whenever we click on one of these buttons. All right, so let's inspect here, we can
see that the payload is Learn Angular, so that makes sense. Let's continue on so
that we will hit the next debugger. We see that the eventName is removeWish. The payload is Learn Angular,
okay, so that's great. Let's start stepping through here. So we will step,
the eventName should be the same as the New Object's eventName,
so let's step over. Once again, we see Next Object
has eventName as removeWish. Payload is Learn Angular,
so, that is okay. Let's step into this,
the wish is type any. We can see that that is Learn Angular,
let's step over. So all of that should be fine. Why? Well, now we see Learn Angular. Maybe I just wasn't patient enough and
needed to restart, I don't know. It's working now, so
let's get rid of the debuggers. Let's save it,
let's go back to the browser. Let's do a hard refresh to make
sure everything is loaded, okay? Looks like it is, let's clear this out,
so whenever we click OK. I don't know why we were seeing undefined
before, but it is clearly working now. So we have our event bus, and this is
fantastic because now we can issue events from anywhere within our application. And we can listen for those events also
anywhere throughout our application. The only thing that we need to do now
is modify our WishList item component, so that we work with the wish object
instead of the individual pieces of the wish object. In order to complete the remove wish
functionality we need some way to identify the wish that we want to remove
because as it is right now the wishlist item component only works with
the Individual pieces of a wish, so we can accomplish this in
a couple of different ways. The first would be to supply some kind
of unique identifier for each Wish. Which in a real application,
that's what we would have, because the wish information would be
coming from some kinda data store. However, I think it would be just fine
if we forego the individual pieces and then just provide. The actual Wish object
to the Wishlist Item. That way we can do whatever it is that
we need to inside of the WishListItem component, which is really
what I wanted to begin with. So I'm going to modify this so
that we no longer have that Wish Text property we won't have the two
way binding for the fulfilled. I mean yes, refactoring kinda seems like
that we are undoing the work that we've done but it was also good practice just as
this is also good practice for us as well. So as far as the CSS
classes are concerned, we're gonna base that upon
the wishes is complete property. That's gonna be fine. Then for the remove wish, now we can pass
in the wish object that we will get. Then when it comes to toggling the
fulfilled, we can leave this method here. There's nothing that says that
we have to get rid of this. I mean I think ideally what I would
wanna do is remove the Toggle Fulfilled method altogether so that we could
declaratively have that right here for the click event, but
this is gonna be just fine. So for the text we'll have
the Wish that wish.txt for the fulfilled we'll set
that to the is complete and that should be fine as far as this
component is concerned we need to go to the wishlist components because we are no
longer going to pass the wish.text. And this fulfilled property instead we
will just have the wish property and that should work there so
now all we need to do is inside of the app component we need to modify this so
that instead of writing something to the console We will simply
modify the items array. We will use splice so
that we can have the index. So let's first of all do this. We'll get the index of the item
that we want to remove. That'll be easier enough to do. And then we will remove that
with the splice method. We'll pass an index and
we only want to remove that one item. So that should work. Now Visual Studio Code is saying that
there's still an error inside of the wish list. However everything compiled okay. So let's go to the browser. Everything looks okay. So if we Click on the Delete for
Get Coffee. That should remove it. [LAUGH] And it does. That worked the first
time that's incredible. How many times has that ever happened? Not very often. So if we remove everything
everything's gone. So okay, I want $100,000. Let's add that. Let's change our filter. And if we remove that, there we go. We have the functionality now
to remove individual wishes and we accomplish that by writing our own
event bus now, the only thing that I wanna change now, this is how we get
access to that event bus because as it is we have created that event object or
that event service objects and we are exporting that And we're using
that object wherever we need to. Wouldn't it be nice if
we could automatically inject that into the classes
that we want to use it in? Well, we can and
we will look at that in the next lesson. Dependency Injection has become the norm
in modern software development. It doesn't matter if it's server-side or
client-side. It doesn't even matter what client-side
framework you use because all modern frameworks have some kind of
dependency injection service, and angular is no different. Now, if you're not familiar with
the concept of dependency injection, it's actually very simple
it injects dependencies. So, first of all, what is a dependency? Well, Let's take a look
at our event service. We, of course,
have this event service class, and then we export an object that we create. So we are creating an actual object
that we are then importing inside of the wish list item component. And then the app component. We are using that object to listen for the remove wish event and
to emit that remove wish event. This event's object,
this actual object that we created, is a dependency in the app and
wishlist item components. And we could say that it
is a hard dependency, because we have actually
created that object, and we are actually using that object
inside of those components. Well, hard dependencies can
be a little problematic, because it can make your code a little bit
more difficult to maintain and update. But it can also cause some issues whenever
you need to test your components. So, we want to use
the Dependency Injection service so that we don't have to create
our dependencies ourselves. All we have to do is tell Angular
what it is that we want to use. And then it will automatically
inject our dependencies. So for our wishlist item component, we'll say that we wanna import
that event service class. Now, of course, this isn't going to work
now because we aren't exporting that. But let's first of all,
imagine that that's what we are doing. We are exporting the class. So that in the constructor, we say
that we want an object called events, and we want it to be
of type event service. We're going to say that it's private
events, so that it will automatically create that property for us, so
that we don't have to create that object. All we have to say is I want this wishlist
component to rely upon this dependency and then Angular will provide that object for
us automatically we could do the same thing inside of the app component
to where we would once again Import the EventService class, and
then in the constructor, we would say that we want an object called Events and
it needs to be of type EventService. Now, in this particular case,
we don't need to create a property because we are using events right here
directly inside of the constructor. But that's the idea. We don't create our dependencies,
Angular would do it for us. The first thing we need to do
is go to our event service. We need to get rid of this export
statements to where we create that actual object. And we are gonna export the class itself. But that's not enough. As you'll see,
there is a compilation error. If we take a look at the browser,
well, we are going to see an error. It says, no suitable injection token for Parameter events have class app
component that basically says that's it can't inject the event service
because it doesn't know that it can. It's not an automatic thing even though
we want it to be an automatic thing so what we need to do is mark
this class with the injectable decorator this is essentially
going to tell Angular that this class can be injected into other classes,
so we'll add that. Now, there's a little issue here. We're gonna have to go
to the other files and we're gonna have to save these again so
that the compiler Will recompile everything, but now we can see
that it compiled successfully. Fantastic let's go to the browser and
we don't see anything. Let's do a refresh here.once again,
we don't see anything and we kind of get the same error that there's this injector
error for at module event service. Blabbity blah, blah, blah, blah. Well, here's the thing, it's great that
we used the injectable decorator here, but that by itself isn't enough. So we can do one of two things here. We can go to our AppModule and
we could import that event service, and then we could add that event service
to the providers array, so let's do that. We'll go back to the browser, and voila, we have that error of
expression has changed. We'll ignore that. And as you can see,
our code works just fine. So that's one way of doing it. However, whenever we use
the injectable decorator, we can essentially specify where we
want to be able to inject that class. So all we have to do is pass an object
that has a property called providedIn, and then this gives us
the ability to essentially say where we want to provide
this event service. So we have a few options. If we wanted it to be inside of
the AppModule and only the AppModule, then we could essentially
do the same thing, except we could say that
it would be AppModule here. We would, of course, need to import that
here, but that would give us the same functionality that we just had by using
the event service as a provider here. I don't want to do that. We could, but I don't want to. We could also provide
a string called root. Now this is an application-level injector,
so this essentially means that the event service would be available
throughout the entire application. I don't have any data to back this up,
but I would think for the most part, that's what we would want to do. However, there are other options. There's one called platform,
because it would be possible to have multiple Angular applications
running in the same page. And it could be possible that you would
want that class to be injected or injectable throughout all
of those applications. In that case,
you would want to use platform. And then there's an any which,
well, it's any. For our case,
root is going to be just fine. So with that change,
we'll be able to go back to the browser. Our code is going to
work as it did before, so we can clear out all of the other things. Let's add the wish for
$100,000, there it is. We completed it, which would be nice. And let's get rid of it. One of the most common things that we do
within our client applications is interact with the server. We issue HTTP requests to fetch data or
manipulate that data. And Angular is a little bit different
than other UI frameworks like React and Vue because it has a built-in HTTP client. Now, yes, you can technically say that
every framework has a built-in HTTP client because, well, we have the Fetch
API that's built into the browser. And yes, that is absolutely true. But if you've built applications before, you know the benefit of using
an HTTP client library, something that makes it a little bit
easier to work with the Fetch API. So React and
Vue do not have a built-in HTTP client. You have to use a third-party client,
or you can just use the Fetch API. For Angular,
we can import the HTTP client module. As I mentioned, it's built-in. We just need to import it
from @angular/common/http. And after we import that, we can add
it as an element to the imports array. I am inside of the AppModule file. So we are adding this as an import
just like we did with the FormsModule. And by doing this, we make
the HttpClientModule available throughout our application, so that then we can
write a service that will interact with whatever data that
we need to work with. Like for example,
we are working with our wishes, and currently we have the items array
inside of our app component. This is hard coded to
have individual wishes. Instead, I would like to fetch
this information from a JSON file. Ideally, we would have some web service so
that we can make GET, POST, DELETE requests, but we don't. So for right now, we will just have a JSON
file that has that same information. We will fetch that information and
then use that to populate the items array. So let's go to our assets folder,
and let's create a new file. Let's just call it wishes.json. And then let's paste in that array. Now, of course, this is not valid JSON. So we need to make a few changes. First of all, each and individual element is going to be
an object that will have a property called wishText that is going to be
set to the string value that we have. In this particular case,
it's Learn Angular. But then we also have
that isComplete property. And we can go ahead and set that as false. But of course, the property name
needs to be a string as well. So this gives us something that we can
easily just copy and paste a few times and then make the necessary changes. So we have a wish to get coffee,
that is always true, because, well, I always have coffee. And we have that other wish for
finding grass that cuts itself. That has been a dream of mine for
so many years. All right, so we have this wishes file,
and we want to be able to fetch this information, parse it into an actual array
of objects that we can then work with. But in a real application, we would want
to abstract this out into its own service, so that we could have a service
responsible for working with wishes. So we would fetch the wishes, we would add
a wish, we would delete a wish, things like that, because that service would then
issue those HTTP requests to the server. So let's create a service. Now we can do this in
a couple of different ways. In a couple of lessons ago, we created
our own service for our event bus. And that was perfectly fine. We can also turn to the CLI
to create a service. So let's look at that. So the command is, ng generate service. And then we provide
the name of the service. But we don't want to have the term
service at the end, because what this would do [LAUGH] is create
a class that says WishServiceService. So basically, we just want to define
the name of the service that we want without the word service, and
then this is going to create two files. The first is going to be the code file. That is, of course,
going to be our class for our service, and then there's the spec for the tests. So we have that file now,
let's open up wish.service.ts. This is inside of the app folder. And you can see that it automatically
makes this service injectable. So we will be able to turn around and use
the service inside of the app component. So let's go ahead and do that. We will import the WishService
from wish-service, and then we can inject
that into the constructor. So let's make this a property,
we'll call it wishService, and the type is WishService. So this gives us that wishService that
we can use inside of the app component. That's great, but we need to write the code that is
going to fetch that JSON file. So inside of this service,
we need to import the HTTP client, and we do this from the same file. So that would be @angular/common/http. And this is injectable, so we can
inject that into our constructor here. So let's make this a property
called http of type Http client. And then we will have
a method called getWishes, or we could call it whatever we want. But the idea is that we know
that this is the method that we would use to fetch our wishes. So we would use our Http object,
this has a variety of methods. You can see right here there's delete,
get, head, JSONP, options, patch, post. So basically, any type of request that
we would want to make, we could do that. In this case, we want to make a get
request and then we simply specify the URL that we want to make a request for
that is our assets and then wishes.json. Now there are other options that we can
add here which we will talk about at a later time, but for right now,
I just want to make this work. So what we are going to do then is return
the result of calling the get method. Now the get method returns an observable,
and by calling the get method,
the actual request has not been sent yet. Since this is an observable object,
there is a subscribe method that we can use whenever you call the subscribe
method, then the request is sent. So just because we call the get method or
the post method or any one of the other methods,
that request has not yet been set. So let's hop on back to the app component. And what I want to do is make our
http request with the OnInit method. Now remember whenever we created our other
components using the command line that tool gave us our component, but
it also made them implement the OnInit. This was a method that executes so that we can perform other
initialization processes. One of those things could
be making an HTTP request. So, we want to implement this
OnInit inside of our add component, so let's add that implements OnInit. We of course need to update
the import statement so that we aren't just importing components,
we also import OnInit. And then we can define that ng OnInit. So here, we would use our wish service,
we would call the method getWishes, and remember that this returns an observable,
so we would call subscribe. So right at this point,
whenever we call subscribe, that is going to make that http request,
and so we need to provide a callback function that will execute when
that request has been completed. So we are going to get some data back. And all we really want to do is set our
items equal to the data that we received. Now let's do specify that data is any but
with that change, we can hop on over to the browser, and we are going to see
that our code still looks like it works. Let's make a quick little
change to our JSON file just so that we can prove that we
are now pulling data from there. Let's just add an exclamation
point to learn angular, and we will go back to the browser. Let's refresh because it needs
to load that data again. But there we go. We now have that exclamation point
at the end of that learn angular. So we are successfully retrieving
that information from the JSON file, it's being parsed into Wishitem objects so that we can display them here
inside of our application. We can filter them however we need to. And of course, we can change their status,
and of course, deleting them works as well because we
haven't changed any of that functionality. So making basic http
requests is very simple. In the next lesson we will look
at some of the options available, such as setting headers,
specifying URL parameters, and eventually, we will also talk about handling errors. When it comes to HTTP requests,
we very rarely just issue a simple get request like we did in
the previous lesson. Instead, we usually have to
supply some options involved, such as special headers or
an authorization token. Of course, it varies depending upon our
server application and what it needs. But a lot of the time, we are supplying
some other information here. So because we don't have
an actual server-side application, everything that we are going to be dealing
with is a get request in this lesson. But of course, the things we talked about can be
applied to any of the request types. In fact,
the only real difference between a get and a post request programmatically
using the Http client is that you provide the body as
the second argument. So the first argument is the URL, the second is the body that you want to
send with that request, and then finally, the third are the options that you may or
may not want to provide, and it's the options that we are going
to be talking about in this lesson. So, when it comes to my own applications,
I typically have a method that will generate just the standard options
that I would need for every request. So, let's do this. I'm gonna make it private, and
I'm gonna call it GetStandardOptions. And this just needs to return an object. This object is, of course, going to have
several different options that may or may not be needed for
the request to be successful. One of those things is
typically the headers. If we don't have the correct headers,
sometimes our request is going to fail. It all depends upon how the server is
going to Process that incoming request. So we have a class called HTTP headers,
and if we are going to use that,
we of course need to import that. So Visual Studio code is prompting us
here to update the import statement, this is imported from Angular common HTTP. And this constructor simply accepts
an object where the property names are the names of the headers and
their values are, of course, the values. So if we wanna set the content type for
this particular request, we could do so application/jsom or
if we had some kind of authorization token that we needed to provide,
we could also do that as well. But we don't in this particular case, so we will leave that alone so
that whenever I make a request so what I will do is get those options by
calling that method, getStandardOptions. And then for our get request, all we have to do is supply these
options as the second argument. Well, let's go ahead and
let's add a fake method for adding a wish. So we'll call it AddWish to where
we will accept the wish object. This will be a wish item
which we need to import. But this is where we would
typically use a post request. So let's take this code out. Let's paste it in here. And in this particular case, we would
definitely need that authorization header. So what we could do is go ahead and
get our standard options. We could say that retrieving
the wishes doesn't require the authorization header but
adding a wish does because well, we are changing data on the server so
it only makes sense that yes of course, we definitely want some
kind of authorization. So in this case, what we could do Is use
our headers object, it has a set method. Now one thing about the headers object,
it is primarily immutable. So if we want to add a new header, we essentially have to
replace the old headers. So by calling this set method,
we are essentially creating a copy of our headers and then adding
a new one called Authorization, and then whatever value is needed for
authorization. So that updates our headers,
which of course updates our options, that we can pass on to
the post method in this case. So, let's get rid of these syntax errors, even though that request
will definitely not work. In fact, let's do this,
let's make it private so, that we can't call this method
from outside of the class. Now another common option that we
would use are URL parameters and this is especially true for GET requests. So for example if we weren't
actually fetching a JSON file, we were hitting some
kind of Web service but we were able to specify the format
that we wanted the data in. We could have a format URL parameter and
then we could set that to JSON or for whatever reason, XML or
any other type of format. We could easily do that by
just adding that to the URL or we could modify our options because it has a params object and
this is of type HttpParams. And just like the HTTP
headers that we used, this is imported from
the Angular common HTTP. Now whenever you new up this constructor,
you can pass in an object that has various options, probably the most
used would be called fromObject. So basically, this fromObject says that
we want to create our URL parameters from this object where the property
names are the URL parameter names. And then their values are of course,
their values. So by setting this
HttpParams using fromObject, I want a parameter called format and
its value as JSON. So that is essentially going to
send a request using this URL, except that we don't have to specify
the query portion of that URL. It will automatically be generated for
us, thanks to this params option. So we can save that,
we can actually see this in action. We can go back to the browser,
let's pull up the Developer Console. And let's go to the Network tab, and
we will probably need to refresh here. Now there's going to be several requests,
but what we want is this
right here wishes.json. We can see that the URL
includes the query portion. We have a query parameter called
format and its value is JSON. And just to prove that that is
coming from this options object, let's change it to XML. So that once again,
when that request is issued, we can see right here, format = xml. Now probably the most
important thing when it comes to making HTTP
requests is handling errors. And the way that we handle errors using
the HTPP client in Angular is a little bit different than other clients, and
we will look at that in the next lesson. Handling errors is an important part
of software development because errors will happen. Things will go wrong. It might be our fault,
it might not be our fault. It can just be something that happens. This is especially true with HTTP
requests because there are so many things that can go wrong. It could be a client issue. It could be a network issue. It could be a server issue. So when it comes to handling errors, we
should at least provide some information to the user that, hey,
whatever you tried to do it didn't work. And here's why. And really in the best cases, we can sweep it under the rug if we
don't have to tell the user anything. But in most cases, we want to provide the user with at
least a little bit of information. Now, the first thing
that we can do is provide a second callback function
to the subscribe method. So here,
we are inside of the app components. We're using our wishService to get our
wishes and then we're calling subscribe. Now, the first callback function is
handling the response on a successful request, and we have seen that work. We know what it does. However, if there is something that goes
wrong, we need to handle that error. And we can do that by
providing a second argument. It is another callback function
that receives the error object. And then we can do whatever
it is that we need to do. We can tell the user
that an error occurred. And this has a message property
that we could provide them. So let's do that,
let's alert(error.message). And as it is right now
we don't have an error. So let's go to our wish service and
let's make a request for a file that does not exist. So let's just change the name of the file
from wishes.json to wishes1.json. And whenever we save this,
let's go to the browser, we will see the result
of that HTTP request. There is an HTTP failure response for
the URL 404 not found. Now, for technical people,
I think that that's perfectly fine. If I were to get that error message,
I would know what the problem is. However, the vast majority of people
in the world are not technical, so we need to provide a message
that means something to them. Now, I am noticing some other errors. Cannot read properties of undefined,
reading filter. We could fix that very easily. Let's go to our app component. I want to minimize as
many errors as we get so that we don't clutter up the console. So what I'm going to do is simply define
items as an empty string to begin with and that should fix that particular error. At the very basic level, all we need to do is provide a second
argument to the subscribe method. This argument is a callback
function that works with an error object when an error occurs. But of course, we as developers want and really need more information
when an error occurs. So a lot of times,
we would log that error and we would try to provide as
much information as possible. So let's go to our wish service. And the first thing that we are going to do is Import an operator
called catchError. Now this is called an operator because
well, you'll see how we will use it. This is coming from
the Reactive JavaScript library, so it's rxjs/operators. And we are going to use this catchError
in order to essentially catch the error as it occurs. Then we can inspect that error,
try to find out what went wrong, so that we can log the appropriate
message into our system. And then we can also provide the user
with something that's meaningful for them as well. And the way that we do that
is by essentially piping in a process to our request that
is going to handle the error. But that's not really
what we need to do here. We need to pipe in catchError, and then we specify something
that is going to handle that. So, I am inside of the getWishes method. We are making our request,
and then we are calling pipe. We are piping in a process
that will process, And error in case if that occurs and
we're going to write a method called handleError that is going
to handle and process that error. So let's do that,
we can make it private and this method is going to
accept an error object. And this is an httpErrorResponse. This classes from
the angular common HTTP and Visual Studio code automatically
added that import statement for me. If not, then you would need to do
that where you import httpClient and headers and params. So we want to know what's happened
with this particular request. So the first thing that we
can do is check the status. And if the status is equal to 0,
then it's not a server error, it is a client or a network error. So we can write something to the console
or if we had a logging service, this is where we would want to do that. To where we can say that,
there is an issue with the client or network and then we could
supply the error information. Now again, this would be for our purposes,
this isn't necessarily for the user. But then we can add an else,
because if the status is not 0, then it is an HTTP response status,
we are getting something from the server. So, in which case, we would want to
signify that we have a Server-side error, and then we would want to be able
to inspect that particular error. And let me go back and
change the code for the client or network. I don't want to output a string,
well, I do, but I also want to output the error as well,
so we need to do that correctly. And so we will have an error message and
it will display information about the error that occurred,
but then we also want to supply the user a readable message,
something that is meaningful to them. So, we can return an error and
really, what we are doing, we are essentially throwing an error. But by calling throwError, this essentially gives us an observable
that wraps around that error. And we simply want to create a new error,
and then we'll have our message, cannot fetch. Or let's do this, retrieve wishes
from the server please try again. And so now, if we save this,
let's take a look at the browser, we are going to see some errors. First we see this failure to get,
now this is coming from the browser, this isn't necessarily
coming from our code. Whenever the browser attempts to
retrieve a resource, if that's a 404, it logs it within the console. So we can ignore this error here, because that is not from our code but
this one certainly is. Server-side error and
then it gives us the markup for that error,
cannot get assets/wishes1.json. Then if we take a look at the alert box,
what the user sees, cannot retrieve wishes from the server,
please try again. So for the most part, handling
errors is pretty straightforward and it can be as simple as simply providing
a second callback function when you call the subscribe method. However, I would imagine for most
applications, you would want to at least process that error so that you can log
it or provide it in the console so that you can inspect that error and
see what went wrong. And most of all, you can provide
a meaningful message to the user. So far in this course,
we've very briefly talked about modules. And when it comes to
building applications, modules are one of those things that,
well, we don't necessarily need them, but they are extremely useful for
very large applications. Because it allows us to
essentially create a container for like minded or closely related
components and functionality. For example, so far in this application,
we've been focusing on the wish list and displaying the wishes,
manipulating them, and all of that. If we were going to build
more functionality for this application that doesn't necessarily
work with wishes like a contact form, well, then it would make sense for
us to first of all create a module that serves as a container for
all of the wish oriented stuff. So All of the components,
all of the services, everything that we have done as far as working with
wishes would be inside of a module, and then we could create another module for
all of the contact form stuff. So guess what we are going to do in this
lesson, we are going to create a module. And we can do that from the command
line using ng generate module, and then we simply specify
the name of the module. Now this is going to be a little bit
difficult because I've use the term wishList in a variety of places. So let's just call this the wishModule. And this is going to create a directory
inside of our app directory called Wish. And by default,
it's just going to give us one file, and it's going to be that module file. You can see right here, it tells us
what exactly it created this file. And it did so
inside of a directory called Wish. So now we have this wish directory,
and really we want to put everything that we have worked on
thus far inside of this folder. Now, of course that has nothing
to do with the AppComponent, but everything Wish related. So, the WishFilter,
the list, the WishListItem, AddWishForm, even
the stuff inside of shared. And putting it inside of
the shared folder is questionable, because really this stuff should have
been inside of a module as well. So let's see what happens,
let's just start dragging and dropping things into this Wish directory. Now Visual Studio code is going to
try to fix some of these paths. So we'll see what happens
whenever I click on Move. If I'm prompted with anything,
well, it doesn't look like it, but definitely we can see that there is
a compilation error because some of the paths cannot be found,
but that's okay. Let's just go ahead and
grab the wish-filter, wish-list, and wish-list-item folders. Let's drag those into
the wish directory as well. Yes, we want to move those. Now of course, we are going to need to
modify not just the app module, because, remember, this is where we had specified
that we had some components to work with such as WishListComponent,
AddWishFormComponent, and so on. And so essentially what we want to do is
take these import statements where we are importing those components. We'll cut them out, and we will put
them inside of this new Wish module. And we will want to add them
to the declarations, so we can also cut those declarations out. So that's inside of the app module, all
we will really have is the AppComponent. And we won't necessarily
need the FormsModule or the httpClient module because those
things are being used by the components inside of our newly created Wish module. So let's also bring those in. Now, I'm noticing that there were some
changes to the pas of those files. Here we can see that WishListComponent
was still set to WishList, so there's not an issue there. But if we look at AddWishFormComponent and
the filter It added the wish there. So that's interesting that
Visual Studio Code modified the paths for some of these and didn't for the others,
but that's an easy enough change. Now, let's also grab those other import
statements for the HttpClientModule. And the FormsModule because we need
those inside of our WishModule. So let's just cut those out,
paste them in. We also want to import those. So once again, we will cut them
out of the imports in AppModule. We will paste them inside of
the imports for the WishModule. Now we are still seeing some errors in
our output, well, I need to scroll down. But yes, we still see some errors. And that is inside of the AppComponent. Now, this makes total sense. Because we've just lifted out
all of those components and put them inside of the module. So as it is right now, our application
has really no idea where those are. So what we need to do inside of our
wish module is it's not good enough to just import these and declare them
here, but we also need to export them. So there's an option called exports. It's an array and we want to export
each one of these components so that whenever we set up our
application to use this WishModule, which we probably should do. Let's go ahead and do that. Everything that can be exported
from the WishModule is going to be available to use
within our application. So here inside of the AppModule,
we've cleaned this up quite a bit, but we do want to import the WishModule. So let's go ahead and do that. We will add that to the imports array. Let's save everything and let's see what we get as far
as the output in the console. Console. Looks like there's an error inside
of the wish-list-item component. So let's open that up. And I can't imagine what
we are missing here. Right here, the EventService. Now our EventService is something that
should be shared across our application. So we have a couple of
different options here. We could break this out
into a shared module or we can leave it as it is and I think for
right now we will opt for that. Let's get one module working first and
then we'll go from there. All right, so I don't see any red
in the file explorer over here. But we do still have an error inside
of our, let's see that is AppModule. So let's take a look at that file. Well, there's WishModule. Let's take a look at the WishModule. Let's see what we have. I don't see any errors. So it could be that we need
to stop our application. We'll run ng serve once again, because sometimes we just have to
stop the process, restart it and then see if it will build or
if there will still be an error. And here we can see that
it compiled successfully. So it looks like that was just an issue. Cannot retrieve, yes, because we are attempting to
retrieve a file that doesn't exist. So let's go to our WishService. Let's change the URL to wishes.json. Let's go back and let's see if it loads. It does. So looks like everything's
working if we add a wish. Okay, so
our application looks all well and good. Now I do think that
the WishService should probably be inside of our WishModule as well. So we have working code, let's break it. Let's move that WishService and
we do need to change the paths. But Visual Studio Code is prompting me,
update the imports. Yes, let's update the imports and
that should make that work just fine. However, once again,
it's saying that we have an issue. So let's take a look at the browser
because that's going to give us a better understanding of where we have an error. And it looks like right here,
cannot find module wish service or its corresponding type declarations
that is inside of AppComponent. So let's go to AppComponent, and let's see what we have there as far
as that WishService is concerned. That is being injected. And the path is correct. So let's do this. Let's copy that import. Let's go to our WishModule and
let's paste this in. We, of course, will need to modify this, because this is directly
inside of this directory. And then we will export this module. But just saving the file
again makes that compile. So it's crazy how this works sometimes. All right, so it looks like everything
is once again working as it did before. In the next lesson we are going to create
another component, one for our WishModule. And in fact it's going to serve
as the wish list application. So we will essentially
move all of the code from our AppComponent into that
new WishAppComponent. This will essentially allow us
to drop in our wish application anywhere within our project. I want to extract just about everything
about our wish list application into the WishModule. Even going so far as to taking what we
currently have inside of the AppComponent, and putting that inside of a new component
called Wish inside of the WishModule. That way, all we have to do is drop that
component into the app components so that we would essentially have something
like this to where we would have a wish app or something along those lines. And then voila,
we have our wish list application. I'm probably taking this
a little bit too far. But my goal here is to transition
into talking more about forms. And so I want to keep all of our wish
list stuff intact and all together so that if we ever do need to talk
about it again, it's there. We just need to drop that component in and
we're good to go. So let's go to the command line and
let's generate a new component. We'll call it simply wish and we want
to put this inside of the WishModule. Now the reason why I'm calling this
component just simply wish is because that's following the pattern that we
have as far as the app component because we have an app module and
then we also have an app component. So in this way, we will have a wish module
and then we will have a wish component. And really all we need to do is take
the markup from our app component. Let's cut that out, place it inside of
the template for our wish component. Now of course,
not everything is going to work because, we do need to address the code as well. So let's open up the code for
our wish component. We'll do the same thing for
the app component. And for the most parts,
we want the import statements for the WishItem, the EventService and
the WishService. Let's cut those out of app and we will
paste those inside of the WishComponent. And then we need to do a few more cut and
pastes such as the items property, the constructor and ng on init and
we need filter as well. Basically everything inside
of the AppComponent class. Let's cut that out and let's paste
it inside of our WishComponent. Now let's do go ahead and
cut out what was generated for our WishComponent because we can paste
that inside of our app component and that should make the errors go away there. We do however have an error inside
of the WishComponent so let's. Take a look, it looks like it's mainly
pathing, so let's modify the paths for importing the EventService,
the same for the WishService. Let's save that, it should compile now. And so let's close those files. Let's sum it up the WishModule,
because we want to modify this. Because now, whatever is going to
be using this WishModule doesn't necessarily care about
the WishListComponent, the AddWishFormComponent,
and all of that stuff. Instead, all we really need to export
is the WishComponent, because anything that is going to use this module is going
to primarily just use this WishComponent. So, we can export that. And then inside of the AppModule, well, we
don't really need to do anything at all. Because in the previous lesson,
we added the import for WishModule. So inside of AppComponent, all we really
need to use is that app-wish element. Now, I'm going to leave this named as is, because I kind of like the idea that
this is an application for the WishList. Although I say that out loud, and
now it makes a little more sense for us to change that because I
would want app-wish-list. But no, let's just leave it as it is cuz
that could be a little bit confusing with the WishListComponent
that we currently have. And so now that we have extracted that
stuff, let's go to the browser, and everything should work as it did before. We can see that we are properly
loading the wishes from our JSON file. Let's make sure all of
the functionality works so that if we fulfill one of these,
the filtered list updates appropriately. If we remove an item,
that should remove it. And if we add a wish, then,
of course, that is there as well. So, fantastic. We now have extracted all
of the functionality for our wish-list application
into this WishModule. So in the next lesson,
we can get started writing another module, one for a contact form, so
that we can talk about forms. We need to talk about forms. Now yes, we have very briefly talked about
forms using the template driven approach. If you'll remember whenever we
created the AddWishFormComponent, we used the template-driven approach. Basically, we used the NgModule directive, assigned that to a property on our
components class, and then that created a two-way binding between the form field
and the property behind the scenes. And it worked rather well. And I dare say that the way that we
used it for this very simple form is exactly what the template-driven form
approach is for, it is for simple forms. And while it works well for simple forms,
we typically don't want to use it for larger forms, and especially if our
application is very forms heavy. Well, a variety of reasons, for one, there is a performance hit with
using the template-driven approach. There's a lot of overhead to manage
the things that are going on behind the scenes. And for now that we can't really be
guaranteed that the data that we are working with is actually
the data that we want to work with. I know that that sounds weird, but
due to the asynchronous and two, a binding nature of using NgModule, the
data that we are working with inside of our component might not necessarily
be what we need to work with. So instead, we are going to start
looking at the reactive form. But I want to do this
inside of another module so that we can swap out these
modules as we need to. So let's generate a module. Let's just call it contact,
and we'll also go ahead and create a component inside
of the ContactModule. And we can just call it contact. The idea is going to be that it is
a contact form, so let's go ahead and generate that component. We do want to make sure that
it is in the ContactModule. And while the CLI is
generating those things, let's go to our ContactModule and
let's open up the module file. Now, if you'll remember,
whenever we used the NgModule directive, we had to include the FormsModule, but
we don't do that with reactive forms. Instead, we use the ReactiveRormsModule. So we want to import that
into our ContactModule. And now that we have that
ContactComponent, let's go ahead and let's add that to the exports array and then we can close this particular
file whenever we're done with that. So let's do that. Let's go to the AppComponents
template as well as the AppModule, because we do want to be sure that
we import that ContactModule. So let's go ahead and do that. And that will give us the ability
to use our new ContactComponent. So inside of the apps template, let's just
use app-contact and that should fix that. So let's look at the browser just to
make sure that we are displaying our information and we are. So, great. Let's go to the template now for
our contact form. I'm going to paste in the markup because,
well, you don't want to see me type all of this. But it's a very simple form. It's a contact form, we have a field for
the person's name, their email address and their message and then of course,
a button so that they can submit the form. And let's be sure that
that's going to look okay. I think it should, it does, great. All right, so
now let's go to the component. And we want to use reactive forms. And the primary way that we do that is
by importing a class called FormControl. Basically what we are going to
do is create FormControls and then bind that to the individual
fields in our form. We need to import this from angular/forms. And then we just define our properties
that are going to represent those FormControls. So we have three,
we have the senderNameControl, and we want to new up
the FormControlConstructor. Now, we can pass in an initial
value if we wanted to. And I think initializing as an empty
string is going to be fine, because these are after all form
controls and empty strings make sense. So we will also have a senderEmailControl,
which once again, we will new up the FormControlConstructor. And then finally,
we will have the senderMessageControl. So we have these FormControls, and now we just need to bind them
to the actual form fields. So we are going to do that
inside of our template. We're going to add a directive,
simply called FormControl. And then the value of this directive is
going to be the properties that we just created. So this is the sender name. So this will be senderNameControl. For the email address, once again,
we'll use the FormControl directive, but we'll bind this to
the senderEmailControl. And then finally for
the text area for the message, that will be the senderMessageControl. So from a setup perspective, it feels
a lot like the template-driven approach. We had to create a property that
we are now binding to a particular field in the form. The only difference is that,
we created those properties explicitly as FormControl objects and we are binding
those objects to these form fields. So then the question becomes, why use reactive forms especially since it
appears that the setup is mostly the same. We create properties,
we bind them to the form fields. Well, the key is I used the term objects. We created these FormControl objects and
as such, this gives us an API that we can tap, Into
to make our forms a lot more flexible. For example, we're going to have
a method called SubmitForms. So let's just go ahead and define this. But if we take a look at just one of
these, like the SenderEmailControl, let's look at what IntelliSense
is going to pop up. And you can see right off the bat that
there are a lot of properties and methods. Some of these are extremely useful. Like for example,
there's a dirty property. Now I've always thought that the term
dirty sounds rather awful within this context, but that is exactly what it is. If the dirty property is true, then the value in that form field
has changed from its original value. And that is extremely valuable to
know as you are processing the form. There's also a pristine property,
which is essentially the opposite. Has the value of this particular
form control changed? If not, then pristine is going to be true. But it also gives you the ability
to mark a form field as pristine. Or there's also a term of touched,
meaning that the user has given focus to the form field and
then took the focus away. So there's a lot of functionality here, especially the ability to use very
expressive and flexible validators. So let's do this, let's do a check. And we will check if
the senderNameControl is dirty. Well, then we will simply alert a message
that says, you changed the name field. Of course, that's not going
to be very useful overall for this contact form, but for
example purposes, it's going to be fine. So let's go to our button,
let's handle the click event. The first thing we really need to do
is prevent the default from occurring, so let's call event.preventDefault(). And then we can call the submitForm. So let's go to the browser, and
whenever we click on Submit Message, we should not see the alert box,
because the name field is clean. There has been no change to it, but whenever we change the value to
something other than an empty string, clicking the Send Message button,
we get the behavior that we expect. We get the alert box with our message. You changed the name field. Now, in the next lesson, we are going
to look at creating a FormGroup. Because, yes, as you've seen,
as it's possible to simply create a form, bind fields to form controls, we can
group those controls into logical pieces. In the previous lesson,
we created a contact form, and we used reactive forms to set up
the ability to process this form. We, of course,
haven't done any processing, but we also briefly talked about the benefits
of using reactive form as opposed to the template-driven approach. One of those is that we get this API, which gives us a much more
flexible way of processing a form. And that's a wonderful thing, but it also
gives us the sense of data integrity. Because as the user submits a form, we get a snapshot of the data of that
form at the time it was submitted. So we don't have to worry
about data being changed on us like we do with
the template-driven approach. So what I want to do in this lesson is
take this just slightly a step further and use a group, because our form
has just three form fields. These fields are related to one another,
so it just kind of makes sense to use
a group to group all of these together. So, to do that, we need to, first of all,
import the FormGroup class. This is, of course,
coming from @angular/forms. And then we want to create our FormGroup. We'll do that by creating another
property, let's just call it, contactForm. And we will new up
the FormGroup constructor. This accepts an object that basically
allows us to define our data model. So just like we defined our model
with individual properties, now we are going to have a model that
is encapsulated within this FormGroup. And we can essentially take these
properties that we created in the previous lesson, paste them inside
of this FormGroup. We, of course, need to change the syntax
because we are dealing with an object literal here, but
basically it's the same thing. We create our form controls, except that now they
are properties on the contactForm. I'm going to make these a little
bit easier to deal with as well. So I'm going to remove control
from those property names. Now, of course, our submitForm method,
it doesn't work. So let's comment out that code. And then let's go to the templates, because this is where we need to
bind our FormGroup to our form. We do that at the form element. So we are going to use
a directive called formGroup, and then we simply assign the contactForm
object that we created. And then for the individual fields, we
no longer use the formControl directive. Instead, we use an attribute
called formControlName. And the value is the name of
the property in our FormGroup. So we now have senderName, we have
senderEmail, and we have senderMessage. And all we need to do is change
from using the formControl directive to the formControlName. So now we have that group,
it is properly bound to our form. The only other thing that I want
to change is getting rid of the click event on our button. Because instead of listening for
this event, we want to listen for the submit event on the form. And we do that by binding
to the ngSubmit event. Now, the reason why we want to do
this is because it allows the user to submit the form, both by clicking
on a button that has a type of submit, which we have, but it also lets the user
use the Enter key on the keyboard. Which I certainly appreciate,
because as I'm entering a form, my hands typically don't
leave the keyboard. And it's very frustrating if I
can't tab between form fields, and if I can't submit a form by just pressing
the Enter key, so this will be nice. Let's go back to our code, and there's
a few other syntax errors that I need to fix, because we are dealing
with an object literal there. And now this gives us a slightly
different way of accessing the different elements within our form, but also
just working with the form in general. So let's write this out. We'll say, this.contactForm.value. And we'll see what we get. So let's go to the browser,
let's pull up the developer console, and let's, first of all, submit the form. You can see that we get an object
that has three properties, senderEmail, senderMessage,
and senderName. And, of course, if we change any of
the form field values, well, then we are going to see those values represented
whenever the form is submitted. So once again, submit the form. We now have the email and the name. And by using a FormGroup,
we also have the ability to check the validity of the entire
form all at once. All we need to do is
use the valid property. And since we haven't defined any
validators, this is always gonna be true. But instead of having to check
each individual property, all we have to do is check
if the form itself is valid. If it is, then great. If not,
then we can provide the user A message. And in the next lesson, we will look
at how we can validate our form. JavaScript was created for
the explicit purpose of processing forms, because before we had JavaScript,
well, it was just very frustrating. The user had to, first of all, wait for the page to load over
a dial-up connection. They had to fill out the form,
submit the form over a dial-up connection, then they had to wait for the server to
process it and then respond over a dial-up connection, only to find that you missed
a field or you did something wrong. It was very frustrating. So JavaScript made it so that we could
process forms inside of the browser. But even then, it was still
a very cumbersome process, and it really wasn't until a few years
ago when the validity API was introduced that it really made
it easier to process forms. Now, of course, there's always been
third-party libraries, because, well, it was never really fun. But thankfully, with Angular,
it is extremely easy to validate a form. All we have to do is,
first of all, import validators. This is, once again,
coming from @angular/forms. And then we just need to apply those
validators to whatever form control that we need. Like for example, we have a contact form,
and we kind of need the name, the email, and the message. Otherwise, what's the point
of sending a message to us? So whenever we create these form controls, we can pass in a second argument, that is,
the validator that we want to use. So we want all of those
fields to be required. So we will simply pass the required
validator to each one of those controls. And voila, we now have a form where
all of the fields are required. Now, we had that code that output the
value of the valid property on our form. And in the previous lesson, it returned true because we
didn't have any validators. But now, whenever we submit the form,
it's false, because, well, of course it is,
all of our fields are required. So, if we provide some information and
then submit the form, it is now true, so great. But of course, we need to apply
more validators, especially for the email, because it's not enough
to just check if it is required, we also need a syntactically
correct email address. So you can also pass
an array of validators. So that's exactly what we will do for
senderEmail, and there is a validator called,
simply, email. And we can do something similar for
the senderMessage, because if the message itself isn't more
than ten characters, what's the point? So we can use a minLength validator. And then we can specify the minLength
of the string that is supplied. So we can say that a message
has to be more than 10, or at least it has to be at least 10
characters, or else it's not valid. So now we can go back to the browser and
we can check this out. Of course, every field is required. So, once again, by not entering
anything and submitting, it's false. But if we supply something to each one
of these, it's still false because we need a valid email address, or at least,
a syntactically correct email address. So we provide that, but it's still false because our
message is only four characters long. So, if we add something that's
more than nine characters, we submit, it is now true. All right, so that's all well and good. But we need something visually so that
we can tell the user, this is not valid, because there's nothing more
frustrating than clicking a button and not knowing what the heck is going on. So one thing that we can do is
add a visual cue to the button. We can disable the button if
the form is not valid, so we can bind to the disabled property. And we can do this in a couple of
different ways because we have two properties here. We can use our contactForm object. We have the valid property,
which we have been working with. So we could say that this
is disabled if not valid. I hate that approach because my brain just
doesn't really process that very well. But thankfully,
we can see that it does indeed work. The submit button is invalid
if the form is invalid, but once it is valid, it's enabled. That's great, but thankfully we
don't have to use valid here, we do have an invalid property. And so I like this a whole lot better,
so that if it is invalid, then it is disabled. If not, then it's not. This reads a whole lot easier. So we will get the same
functionality that we did, it's just that our code is
a little bit easier to read. So that's great, but
it still needs some work because we need to tell the user, hey,
this field is required. Hey, this field is required, and
it needs to be a valid email address. And so far, everything has been easy. It hasn't been cumbersome. This is gonna get a little verbose,
so let's focus on the email address, since we have two things that
we need to check for here. And while we could take several
different approaches for this, what I want to do is just add a message
to the bottom of the field to display the error that the user needs to fix here. So we're gonna add a div element after
the input element, but of course, we only want to show this div element
if the email field is not valid. So we can use ngIf, here, and
we'll use our contactForm. But that's not good enough because
we want the individual email field. So we have a method called get, and then we pass in the name of
the field that we want to get. So in this case,
that would be, senderEmail. And then we can check if it is invalid. Now this is going to display an error,
we have a red squiggly here. And if we save this and
if we go to the browser, we're going to get
the explanation as to why. It says that the object is possibly null. Well, that's all well and good, but we know that this really
shouldn't ever be null. If it is null, then there's
something definitely wrong here. But we need to make this
work syntactically, so what we can use is the null
null coalescing operator. So what we can use is essentially
the null-checking operator. I don't really remember what
the actual name of this operator is, but it is a question
mark followed by a dot. Basically, it says that if what
comes before this operator is null, then fine, it's null,
don't do anything else. However, if it's not null,
then it's going to go ahead and check the invalid property. So this is going to fix that. And so, if this is not valid,
if it is invalid, then we can say that this is invalid. And so, let's take a look at
what that's going to look like. And there it is. Now, I don't particularly want this. We are seeing the error message as
the form is loaded into the browser. I would like the message to
be hidden until the user does something with this field. So that let's say that
they give focus to it and then they decide to not put anything in
there, so they move on to the next field. Well, that would be the perfect
time to display an error message. Hey, this is required. So we can do that, but it's going
to require a little bit more code. So here's what we want to do. If this is invalid, And if the field
is dirty or if it has been touched, which is the kinda state
that I just went over, the user gave focus to it, decided
to give focus to another form field. So they touched that field signifying
that they at least interacted with it. So if it is dirty or
if it has been touched, then we want to display
that error message. Now, notice what I've done here,
we've typed out or I've used ContactForm.get, passed in
the name of the field, and so on. So it does get verbose taking
this particular approach. What we could do is create some kind of
helper method, or a helper property, or something inside of the component class so that we can get to this
information a little bit easier. I'm gonna leave this as is. But now with that in place,
we can go back to the browser and the form is going to load as it should. There's no error messages,
because the user hasn't done anything yet, which is what we wanted. But if we touch the email
address field and then give focus to something else,
then we get the message. But, of course, the message,
this is invalid, this isn't good enough. We want to provide something meaningful to
the user, but we also need to keep in our minds that there's actually
two different error messages. There's one that's going to tell
the user that this is required. There's also one that's going to tell
the user that they need to supply a syntactically correct email address. So we're going to use
the small elements here. We're going to set the class to
text-danger so that it is red. And then we are going to use ngIf, because we need to check what kind of
error that we are encountering here. So let's just copy what we have here for the invalid, because we're
going to use that as our basis. Because instead of using
this invalid property, we have a method called hasError, and then we can pass in the name of
the validator that we want to check for. So in this case,
we used the required validator. And if that is the error, then we
can say that this field is required. But then we also need to check
the email error as well, because we have that email validator,
so we will use email. And then for this message, we can say,
please enter your email address. So now, whenever we go back to the browser
once again, there is no error message. We touch the field and
we can see that the field is required. Okay, so we start entering stuff, but now we see that the error message
changed, please enter your email address. So if we supply a syntactically correct
email, then the message goes away. But the minute that we have an error for
the email address, we get that message. And of course, if there is no value,
we once again get the required error. Well, let's essentially do the same
thing for the message very quickly. So let's just copy what we did for the
email, let's paste it for this text area. And of course, instead of using
senderEmail, this is senderMessage. We have to change all these. Once again, we could set up
some kind of helper method or something to make it a little
easier to get to this information. Now for the minlength error, all we
would use is the name of that validator. So whatever validator we used,
we use that name. So that would be minlength,
and I believe the message has to be at least 10 characters,
all right? So that should be fine. Let's go back to the browser. Let's enter, well,
let's not enter our name yet. We will enter a valid email address,
and then our message. And we're not seeing,
it is the name of our validator, but it is all lowercase,
that's kind of important, isn't it? So let's go back. Our valid email address, and then our
message has to be at least 10 characters. So once we reach 10 characters,
then that message goes away. But, of course, the form itself is not
valid because we need to supply the name. And I guess very quickly,
we could add the name validator as well. So let's copy what we did for
email or the message. It doesn't really matter. Let's paste it for the sender name. We, of course, need to change
[LAUGH] the field for this, but we only have one validator here and
that is the required. So we can leave that as it is,
this field is required or we can have something
a little bit more custom for this field, please enter your name or
something like that. I think this field is required is fine. So now, if we touch it, error is there. If we type something, the error goes away,
and we now have validation for our form. Angular has many built-in form
validators and they will work for the majority of our use cases. However, there will be times when
you want your own validator. And thankfully, it's very easy to
write your own custom validator, because all it is is a function. So I want to add another validator
to the email address field. Basically, I want to
prevent people from using certain domains like gmail.com or
yahoo.com. I know that that doesn't sound
very useful, and in fact, it would be very frustrating, but
it gives us an example to use. Now, remember that I mentioned
that a validator is a function. So we could define that function
here inside of our component, but I think it makes more sense
to put it inside of its own file, especially after we are done
adding some of the features to it. So let's call this invalidEmailDomain, and let's first of all talk about
the anatomy of a validator. Well, as I mentioned,
it's just a function. The function name itself
really doesn't matter. So for right now, I'm going to
call it invalidEmailDomain, and it accepts the control
that it is bound to. It is of type AbstractControl. So what exactly does that mean? Well, whenever we set up our form
controls instead of our form group, we specify the validators. And so here for our senderEmail, we are going to add that
invalidEmailDomain validator. So when Angular validates this
form field or this form control, it's going to pass this form control
to our invalidEmailDomain function. And then we do our validation and
we return one of two values. The first is an object of
type ValidationErrors. So if the value of this control is not
valid, it will return an object and it will specify the type
of error that occurred. The other value is null. If our function returns null,
then the value is considered valid. Seems kinda weird, especially
whenever we see how we return this ValidationErrors object, but
it is still quite simple. So let's first of all get
the value of the control. So we'll use the control object,
it has a value property. But remember that we
are also using strings. So if we want to see if the provided
email address has a given hostname, it would make sense for
us to just normalize all of the string, because email addresses
are not case-sensitive. So what we will do is call tolowerCase()
here, but notice what I'm doing. I'm using the ?.operator so
that if control.value, Has a value, then it's going to
be converted into lowercase. If it is null, well, then null is
going to be assigned to value. And this is important because the first
thing we are going to do is check if we don't have a value. Because if we don't have a value, then
technically, our form control is valid. It doesn't have a host name
that we want to prevent, so we return null if we don't have a value. Now, of course, that's just for
this particular validator. Other validators might need to
return an error object in that case, we don't in this case. So the next thing we need is to
check if the provided value has any one of the host names
that we want to prevent. So let's do this. Let's create an array called hosts, and we will have gmail.com and
yahoo.com, and we could do this very easily by
using the some method on our array. So we will call hosts.some, and we're going to be working
with each individual host. So, basically, if some of the hosts are
substrings in the form control's value, then, of course, yes,
we have an error that we need to return. So all we are doing here is calling some. It returns a Boolean value, so
that if some of the hosts are substrings in the value, then matches will be true,
otherwise it will be false. So that then we simply need to check
matches whenever we return something. If we have a match, then we return an object that has
a property called invalidEmailDomain. Now this, it's not arbitrary, but this property name can be whatever
it is that we want it to be. This is the error name itself. So if we take a look at the template here,
whenever we check to see what error occurred, such as required in this
case, but we want the email address. So here we check required,
here we check email. We will essentially do the same thing, but we will use whatever property name we
specify here inside of our validator. So our error name is going to be
invalidEmailDomain, and then we will simply change our error message,
the email provider is not allowed. But let's go ahead and
let's finish this return statement. So if there is a match,
we return the validation error's object, otherwise we return null. And so now all we need to do is,
well, first of all, we need to import this ValidationErrors. This also comes from @angular/forms, but then we need to import
this invalidEmailDomain. So let's, first of all, export that. I don't think we did. No, we didn't. So we will export that function and then
import that here inside of our component. And then once we save this and we go
to the browser, everything should work. Visual Studio Code, for whatever reason, still thinks that there's
an error in the template. I don't think that there is. Okay, so let's try this out. We know that the validation for work. So all we are gonna be testing here
is the validation for the host name. So if we have something that is permitted,
asdf.com, we can see that that works just fine. But if we use gmail.com,
the email provider is not allowed. If we use yahoo.com,
the email provider is not allowed. But if we use outlook.com, well,
then we can see that that is valid. So there we go, we have our own validator. But I want to take this a step further
because I don't necessarily like that the hosts are hard coded
here inside of the validator. Instead, I would like to
do something like this so that we have a function
that we could call. And it would look something like this, so that we would have
the invalidEmailDomain here. And we would call
createInvalidDomainValidator. [LAUGH] That's a mouthful, but it at
least is explicit as to what it does. And then we could provide the host
names that we wanted to prevent. This way, we could use this function
anytime that we needed to create an invalid domain validator, and it
would give us a little more flexibility. So let's do that. Let me make sure that this is typed
correctly, createInvalidDomainValidator. Okay, so here's what we are going to do. We're going to change
our validator code so that instead of importing
the invalidEmailDomain function, we are going to import a function that
will create that invalid email domain. So let's save that. Let's go back to our validator file,
and instead of exporting this function, what we will do then is export
the createInvalidDomainValidator. So that it would accept the hosts that
we wanted to work with, which is going to be just an array of strings, and
this is going to return a ValidatorFn. This is the type that we need
to import from @angular/forms. But from there, all we really
need to do is just cut and paste. So let's take this, cut it out and paste it inside of our
createInvalidDomainValidator. We can get rid of this hosts variable
because now we are relying upon the hosts that were passed to
createInvalidDomainValidator. And let's do this. We will simply return our function, and
we will use an arrow function here. So that should give us the same
functionality as we did before, but now we have a validator
that is dynamic. We can create it however
we need to create it with whatever hosts that we want to
prevent the user from using. Let's add another one, just to make sure that everything does
indeed actually work as we expect it to. So let's also prevent hotmail.com. I still have a Hotmail account. It long ago became my spam account,
but still it can be useful here. So let's test Hotmail. That email provider is not allowed. Let's try Yahoo and Gmail. Now, of course, our validators can be
as simple or as complex as we need. Even though ours is a little more dynamic,
I would still say that it is simple. Single page applications
are not a new concept, it's been around for
many, many, many years. And, of course, thankfully, the way
that we create and develop single page applications has changed over the years
to where now it's relatively simple, whereas at the beginning
it was very cumbersome. Now if you're not familiar with
the concept of a single page application, it is an entire web application that
is loaded into a single web page. This is very different from
a traditional web application. So here we have tutsplus.com. This is a normal website. So we go to tutsplus.com,
we click on a link. This link is going to send
a request to the HTTP server. The server will handle that request. It will generate the output, which is
the HTML that is sent to the browser, and then it will send that
response back to the browser. With a single-page application,
the server, for all intents and purposes, is left out. The initial page is sent from the server. But clicking on a link to go to other
parts of the application doesn't necessarily mean that it will
send a request to the server. Our Angular application is going
to be handling those requests. And the way that that works
is by using a router. And if you're not familiar
with the idea of a router, it's very simple, it essentially
routes a URL to a component. So for a traditional website,
the server handles all of that, it accepts a request for a given URL,
and then it returns a response. The result being a completely separate
page within an Angular application. The Angular application receives the URL,
and it loads another component
that resembles a page. If that's clear as mud, hopefully getting
into it will be a little bit clearer. So, the first thing we need to
do is create a new project. Now, we could add the router
to our existing wish list. However, if you ever plan on creating or
writing a single-page application, even if you don't intend to use
the routing capabilities up front, it makes sense to go ahead and
just create your project using the router. So, we're going to create a new
project called router app, and the very first question is if
we want to use Angular router. The default is no, but in this case, yes,
we do, and let's use just ordinary css. And then when our project is created,
we will create a couple of components that will represent individual pages,
that we will, quote-unquote, navigate to. Let's generate the first component,
and we'll just call this first. Then we will do the same thing
except we'll call it second, so, that this is going to give us two
components that we can then then navigate to, to represent individual
pages if you will. And before we start up our application,
let's go ahead and load up our code editor because there are quite a few differences
between an application that has the router and then just a normal application
that we have been working with. And we'll start with the app module, so let's go into the source folder inside
of app, we'll look at app module. And for the most part everything looks
normal except that now we have this app routing module. This is a module that contains
the routing information because what we have to do is
essentially define our routes. Basically we say that we want this
particular path to go to this particular component. And all of that is defined inside
of this AppRoutingModule, and this is inside of
the AppRoutingModule file. So, let's go ahead and let's open that up,
and we will see our module is defined here, it is importing
the router module and for route and then the routes are being passed to
this and then exports the router module. But what's important here
is this routes variable, this is an array of objects that
essentially defines our routes. At the most basic level,
there will be two properties, there will be the path Which
is essentially the URL and then the component that we
want that path to route to. So, we have our first component which we
need to import both the first component and the second component as well, but
I want you to notice the path itself. Now, there are some frameworks that
want you to put a slash before this, but these paths are all
relative to our application. So, the route of our application
as it is currently is local host port believe 4200, so
the path that we specify within a route is going to be
that first segment in the URL. So, in this case it will be first or
it would be second, so, let's take a look at that in the browser. So, let's hop on over there to
our Angular application, and at first is going to look
like a normal application. We have the boilerplate
page that we would get from the app template, but
now let's go to slash first. We're going to see the same thing here,
but notice way down here at the bottom, there's the first works, that is the content from the first
component that we created. If we go to slash second, then it will
change to second works or it won't. Did I set up the route correct? No, so the path of seconds was being
routed to the first component, so that's why we saw the content for
this first component, so we can change that to second component,
which we need to import. And then once that's done,
then whenever we go to slash second, there we have the content that we wanted. So, this is the idea behind routing,
you have a URL, and then our Angular application
is going to handle that URL and it's going to route it to a component
that is essentially a different page. But in this particular case it looks like
the majority of the pages are the same and that's because the app component
is still being loaded, this is essentially the template or
the home of our application. So, if we wanted to, let's keep all
of the css, and there's a lot of css. Let's also keep the toolbar, but
right here in this div element let's get rid of all of the content
inside of this div element. And then at the very bottom
you see this router outlet, this is an important component
because this essentially tells the angular router where to load
the component that we are navigating to. So whenever we go to slash first,
the content for the first component is loaded right here. The same is true for
the second, and really for any route that we attempt to go to, the
output is rendered here at this outlet. So, now if we go back to the browser,
we have our navbar at the top, we can see that the second works
because we are at the second page. Let's go to first and
there we go to first, but if we go to the route of our application,
it's not going to put anything there. And the reason is very simple, because the route of our
application is our app component. However, we can change that by
specifying a different route, so we have first and second as the paths. If we don't have anything for a path, that
is going to be essentially our homepage. So, now we have set the first
component to be our homepage, it still is going to load the navbar and everything else because that is still
being loaded from the app component. But now you can see that we see
the content for the first component, but notice the URL, we are at home, there
are no segments after the host import. But what about if we go to slash third,
what happen there? Well, we see nothing, but we want to display something to the user
because slash third doesn't exist. And just like a typical website, we want
to tell the user, hey, you tried to go to some place that doesn't exist, and we will
look at how to do that in the next lesson. The concept of single page applications
has been around for many, many, many years. And even so it is very easy to get into
the mindset of using this new technology, this new methodology of
creating a web application. And so we tend to just forget everything
else that we know about typical web applications, but the one thing that we need to remember
is that this is still a web application. Yes, it is very different from
a traditional web application, but it is still loaded into the browser,
users still expect a typical web application experience so
we need to provide that experience. And one of the things that we
need to do provide a page for the users when they try to go
to a page that doesn't exist. Like for example, we have two pages, the first is the default page which
is handled by that first component. Then we have the second page, which
all we have to do to go to that second page is change the URL, To have
a second segment, and that's great. But if we go to third, well,
it takes us back to our default, and we don't necessarily want that. We want to tell the user, hey, you tried
to go to this page it doesn't exist. It's not technically a 404, but
that is basically what they expect to see. So to provide this experience,
the first thing we need is a component that we can use to handle those
cases when a page is not-found. So let's generate a new component. We can call it simply not-found. And let's go ahead and
change the template so that it says that, you've tried to go to
a page that doesn't exist. Now, I know technically we
aren't dealing with pages, we are dealing with components, but
remember, the end user doesn't know that. To them,
this is just another web application. It might behave a little bit differently,
might be a little bit more responsive, because it is a single page application,
but ultimately from their mindset, they are still working with pages. So the page you tried to
go to does not exist. Great, so we have that message. Now we need to set up a route so that when
the user goes to something that doesn't exist, we route them to that component. So first of all,
inside of our routing file, we need to import the NotFoundComponent. Then we need to define our routes,
and we do that by setting the path to a wildcard,
it is simply too asterisks. And then of course, we set
the component to our NotFoundComponent. And that's it, that's all we had to do. So, whenever,
we go back to the browser, of course, the default is going to
go to the FirstComponent. Whenever we change the path, the second
it, of course goes to the second. And then no matter what we do for
the other URLs, it will go to our NotFoundComponent. So third of course, doesn't exist some,
random text, of course, doesn't exist. And we can even have
multiple segments here, it doesn't matter because it is
a wild card, it is a catch-all. So any path that doesn't
match the empty string for the default route or the second string for our SecondComponent is going to
be handled by this wildcard. Now, since we're here, this is a perfect opportunity to talk
about our routing table, because how you define your routes will change
the way that your application behaves. Always remember that,
Angular uses a first-match policy. So when the application receives
a request, it's not technically a request, but I'm gonna call it a request,
it is gonna look at that path, and then it is going to look at the routing
table, and it is going to go in order. So the first route in our routing
table is our default route, where the path is an empty string. So for our default page,
it found a match right in that first rule. So let's go to our second page. When our application receives this
request, and it's going to take that path, and it's going to look at
the first route in the table, and it won't find a match because
the path doesn't match. So then it looks at the second rule. Well, there it will find a match. So it will route that request
to the SecondComponent. Now, if we move the wildcard route to
any other spot within the routing table, then we are going to
mess up our application. So in this case,
the default route is still going to work, because that is the first rule,
it will match that rule. However, anything that we type for
the path after that, will be matched by the wildcard because that is
the second rule in our routing table. So now, well, we have syntax there,
so I need to save that file. So now that the wildcard route is
the second route in the table, the URL for our SecondComponent is
being handled by the wildcard route. So as you're defining your routes,
be mindful of the route order, because it does make a difference and you can very easily break your application
by defining your routes incorrectly. One of the most basic things that we want
to do within a single page application is navigate to different components, and we essentially have two
different ways of doing that. The first uses an a element. So it's very similar to what we
would do with normal HTML, the only difference is that instead of using
an href, we use a router link attribute. And then the value of this router link
is the path that we want to navigate to. So I want to add a link for
the home page, in fact, let's get rid of everything else here. And we also want a link
to go to our second page. So the path will be simply second. And then for the text,
let's have second page. So let's take a look at this. Let's go to the browser and
we need our links to be visible. So, let's add some CSS here. For the a elements inside of a toolbar,
we'll set the foreground color to white. Let's also add some margin to the right. Let's just set it to 15 pixels, that will be enough to separate
the two different items and it is. So now,
if you look in the lower left hand corner, you can see the URL for
the home is our home URL. If I hover over the second page, we can see that the URL was automatically
generated and it goes to the second. So if we click on any one of this links,
of course, it is going to navigate us to
the appropriate component. That's fantastic, but we have another way. But sometimes we can't
always use an a element, sometimes we need to
navigate programmatically. So let's look at how we can do that. And what I'm going to do is, lift out
the ContactModule from our wish-list. So let's go there. I'm just gonna copy this entire
contact folder, because remember, this is the module, everything as far as our contact form
is concerned is inside of this module. So we can just copy that. And then we want to go to our router-app,
so that we can just drop that in. Now of course, since we wrote our
ContactModule to be a module, we can just drop it in at it to
import that into our AppModule and then we will be good to go. I mean,
that is the general idea behind modules. So let's go to AppModule. And we want to import the ContactModule. Let's see if Visual Studio, yep, it's
going to let us import that automatically, so we are good to go there. So that now we just need
to set up a route for that. Now of course, we want to define
this route before the wildcard otherwise we would never
get to the contact page. But we want to set the component
to simply ContactComponent. And once again, Visual Studio is
gonna make our lives easier and just automatically import that for us. We are good there, but of course,
we want to navigate to contact programmatically as opposed
to using an a element. Now, we're still gonna use an a element,
but we aren't gonna use a router link. Instead we will use an href we
will set that to a pound sign or hash whatever you wanna call it, and
we're going to handle the click event. So the idea is that this could
be a button or something. We are going to navigate to
the contact page programmatically. So the first thing we should do
is preventDefault, because, yes, even though the href is set to a hash or
pound, whatever, we still want to prevent the browser
to navigating to that pound or hash. And then let's have a method
called goToContact. So that is the code that we will execute,
and then the text will be simply Contact Us. So we need to define this
goToContact method in our component. So let's go to the app_component and
let's add it to the class. Now, we navigate by using a router object,
and that can be injected into our component. So let's define a constructor that's
going to have a private router, and the type is going to be router, and
we import that from Angular Router. And now that we have that router object,
we can use its navigate method. Now this is going to seem a little weird,
but this is really a good design because what you do is pass
an array to the navigate method. That might sound weird, but
this allows you to build a URL. So typically, in the past what we
do in just normal JavaScript and other frameworks is we build a URL
by concatenating strings together, or we use a template string. Or there's a variety of different
ways that we can build a URL, but it involves a lot of extra work,
which I typically don't enjoy. So what the navigate method
allows us to do is pass an array, where the elements in that array
are the different parts of the URL, and it will build that URL for us. So in our case we want to navigate
to the contact page, and so the path is going to be contact. But if our path was actually contact/us, we could pass in a second
argument to that array. And then behind the scenes, Angular is
going to build that into an actual URL, and we don't have to concatenate
strings or anything like that. It's really a wonderful design. The most basic usage of navigate is that,
passing the array that contains the different pieces of the URL,
and you're good to go. So if we go back to the browser,
we don't see our contact link. Why don't we? Because I didn't save it. That's kind of important. So let's save the HTML. Let's go back. Now we see Contact Us. Now, of course, if we try to
navigate to home and second page, that's going to work just fine. But whenever we navigate to Contact Us,
there's our form. Yeah, we used Bootstrap, didn't we? So let's go to index.html,
and let's see here. I'm going to paste in the CDN for
Bootstrap. So it's not going to look
exactly the same, but it's going to look a little
bit better at least. So here we go. Now remember, all of the functionality
was inside of that contact module. So all the validation should still work. So as far as the name,
if we give focus to something else, hey, that's required, fantastic. And I want to use my Gmail. No, that's not allowed. So can we try Yahoo? Nope, that's not allowed. So everything else works as it did before,
except that now it is in a different app, and we navigated to this
form programmatically. [SOUND] Now that we know how to create and
use routes and navigate using those routes, let's create
a page to display a list of products. And then in the next lesson, we will create a page to display
the individual details of those products. So let's start by creating a module,
because we're going to be working with several different pieces
all related to products. We're going to have the components for
displaying our content. We will also have a service to
emulate working with the data store. So let's start by generating a module and
let's just call it products. Very simple. Then we can go ahead and create the component that will
display the list of products. So we will generate that component. We'll call it products/productslist. And then let's also specify that this
is inside of the products' module, and then we will generate our service. And I don't remember if we've generated
a service using the command line. I remember that we did so manually. So if we haven't, then, well, this is
great, we will go ahead and do that. We'll use the generate command, but this time we specify our service and
we want products. Let's just call this products. So this will be our products service. And once this is done, now, whenever you
generate a service, there is no M flag, so we can't specify to create
that service inside of a module. But by using products in front
of the name of our service, it gets placed inside of that directory. So we're good to go there. Everything is going to be inside
of our products' folder, and that's exactly what I want. So, let's go to our service because it
makes sense to start there because we need some data before we have anything else,
and I'm going to paste in an array. So, all this class is going to
do is provide access to either the data array here or to the individual
items inside of the data array. So, yes, this could be a JSON
file that we retrieve with HTTP, just like we did with our wishes and
stuff. But this gives us a little different
approach to that, and this also gives us practice creating our own observables,
which is actually quite simple. So for this lesson, we need just
one method to get all products. We essentially want to
return the data array, but we don't want to just return
the array because we want to return an observable that will
then provide access to our data array when it is subscribed to,
and this is very easy. We're gonna use a function called of,
this is from the Arc.js library, and this is going to return
an observable of our data. And that's all that we need to do, so
that the inside of our product list, we will, of course,
need to inject this product's service. So let's do that first,
let's open up the code for our component, and we want a private. Let's call this just store, and
we need to import the product service. But inside of ngOnInit,
we will use our store, we'll call the getAllProducts,
and then we will subscribe. This is going to give us our list of
products that we can then work with. So inside of this product list component, let's say that we will have
an array called products, this will be of type any, and
let's initialize it as an empty array. So that whenever we
subscribe to getAllProducts, we will simply set the products'
property here equal to the products that were provided through our data store. And so this gives us our data for
our product list. So let's go to our components template. Let's get rid of the defaults. Let's have a div with
a class of container. Let's have another div
with a class of row. And then inside of here let's have,
I guess, an h4 element, and here we will simply
display the product name. But of course we need the ng4 list. I'm getting ahead of myself here. So we want to generate multiple rows
based upon however many products we have. So let's go ahead and
let's do that here, so that we will use. The ng4 let product of products and
that should get us there. Let's go to our app component
because we do need to import this or not the app component,
we need to go to the app module. And so,
let's import the products module and we will add that to the imports array so
that then we can set up the route so let's go to our Apps, routing module. And let's set up a route to
take us to that product list. So let's import the product
list component. Let's add a route. We'll say that this is
simply just products. And then the component will of
course be products list component. So there we go. With that,
we should be able to go to the browser. Let's go to /products, and we should
see our list of products, guitar, piano, and drum. Now, if there's one thing that I want you
to take away from this particular lesson, it's this. Whenever you start working with a router, the way that you provide data
to your components changes. Because, here, our app component
primarily exists to display the individual pages that we navigate to. If you remember from our wish list, the app component is where
we loaded all of our data. And then we supplied that data to all of
the other components that were inside of the app component. Well, now, app component is just
a container for everything else. And so it doesn't make sense to load
our data inside of the app component because we can't really provide
that data where it is needed. So now the components that
represent individual pages, are mostly, if not solely responsible for
getting their own data. So you can almost think of
each individual component that represents a page as
its own small application. And so now the primary question
we have is how do we navigate to a dynamically generated page? Because now we have a list of products
that was dynamically generated. This is completely dependent
upon the data store. How do we get to an individual page for
showing the guitar information, or the piano, or the drums? Well, we use something
called route parameters and you will learn how to use
them in the next lesson. We have a page list of products. And so now, we need to page to display
the individual products so that we can see the whole lot of information that we have,
which is just the name and the price. So, the thing about this is
that it needs to be dynamic, because what we have here is dynamic. What we see in our list is
completely dependent upon our data. So when it comes to setting up our route,
we need something that can handle dynamic data because yes,
we could create an individual route for each individual products,
but that's not feasible. Our data is going to change. So let's talk about our URL. We have our products,
which of course, is our list, and typically what we would do is follow
that up with another segment, and then it would be some kind of
identifier for a given product. Well, we have IDs to work with,
so In our case, our URL will be products/1, 2, and 3. And we can make this work by using
what's called route parameters. You can think of a route parameter
as a variable for your route. So our route is going to look like this,
to where we still have the products part of our URL, but then we are going to
follow that up with another segment. And we will begin our
route parameter here. It starts with a colon, and
then we give it a name. ID is going to work for us because
that is what we are working with. And then we just specify the component
that is going to handle this route. So let's call it product detailsComponent
of course we need to create this so let's hop on over to the command line. We will generate that component
inside of the products module. Product details I think we called it, and we also need to modify our service
because we only have one method and that is to get all of our products we
need one to get just a single product. So with that done We should be able
to just import this, we can, and I think that's it as far
as our route is concerned. So remember that we have this route
parameter as the second segment for our products route. The parameter starts with a colon and
then we have the parameter name id. Pretty easy to remember. At least the name will be. All right, so let's go to our product
service and we need a method to get a product and let's just call it get
product to where we will have an id. Let's make sure that it's the number and
this is going to be very simple. All we will do is try to find
the product with the given id. So we are going to compare
the id property on each one of these product to the provided id,
and instead of returning this, we are going to return an observable
of the product that was found. So there's our method. We should be able to close that. It says that there's an error. I don't see an error. Where's our error? We need another parentheses there. Okay, so we can close our service
because we are done there. And let's go to our
product details component. Let's go to the code. And we want to inject our data store here,
just like we did in the previous lesson. So that is products service but
then we need some way to work with the, Activated route, because remember that
this component is handling a route. And since we have a route parameter, which is just some information
about the activated route, we need to be able to access
the information for the activated route. And we can do that by
injecting the activated route. Now, I'm gonna call this route. This is not to be confused with router
that we used a couple of lessons ago. Whenever we navigated to the contact
page and we used the router, it's the same idea except that we
are working with the activated route. Okay, so the first thing that we need
to do is get the id from the URL. And the route gives us that. It has a property called ParamMap and
this is an observable. We can call subscribe and our callback function is going to
work with an object of type paramMap. We need to import this as well. Both the activated route and
the paramMap comes from angular router. And then inside of here,
we will have access to the ID parameter. We'll call the get method
on our parameters object. We'll pass in the string of id and
then that's going to get us our id. So let's do that. And then we will feed that into our
call to getting the individual product. So let's do this, let's have a property. Let's call this simply
product type any and let's initialize it as an empty object. So that after we have the id,
we will use our store. We will call get product. We will pass in the id and
we need to subscribe there. But that is going to give us our product,
which we will then just set to the product property on this class,
and that is going to get us there. Now, notice that there's a red
squiggly here for the id. That's because getProduct is expecting
a number, we are passing a string. One thing to remember is that whenever
you work with route parameters, it comes from the URL. And URLs are strings,
they are always strings. So you will need to coerce the data coming
from your route parameters into whatever type of data that you need. In our case, we need a number. So let's do this, because it could be possible that we
don't have an actual value for id. So let's check if we have a value for id. Because in the case that we do, that's really the only time that we want
to fetch information from our data store. So now we can convert that id into
an integer, we'll pass that to getProduct. And then that is going to work,
or at least it should work. There aren't any errors that I see. So let's go to the template, and
let's modify our template here, we want to display
the product information. So let's have a div of container,
I guess we can go ahead and have a row. And then let's have an h3, which we'll
start off with the product name, and then with smaller text
we'll have the price. So we will simply output product.price,
and that should work. Let's go to the browser,
let's go to products/1, and we should see, I think that's guitar? Yes, it is, if we go to /2, we see piano. If we go to /3, we see drums. Now the next thing I want to do is
add links to our products list, so that the text here will be links, so that
we can easily navigate to those pages. So let's go to our
products list component. All we need is the template,
and we can still use an h4, but inside of the h4,
we will have our a element. We will still use routerLink, but we
aren't going to use just the attributes, we are going to bind data here. The reason is because now it's
more than just a simple URL. We have data that we also need
to supply with that route, and we do that with an array. The first element in the array is
the first segment, products, in this case. The second element is going to be
whatever value that we need to supply to the parameter. In this case, it's the route parameter, so this is going to be
the id from our product. And that should be all that we need to do. So let's be sure that our text
is wrapped with this a element. But Visual Studio Code doesn't like this,
can't bind a router link since it isn't a known property of a,
let's take a look at the browser, yep. Yeah, we need to import the routing
module to our products module. We can easily get that from
the app routing module, so it is this router module. This was automatically imported
whenever we created our project. And since the app routing module
is imported into the app module, then we didn't have to worry about that. But since we are trying to use the router
link inside of our ProductsModule, we need to import at
least the RouterModule. So let's do that,
let's go to the ProductsModule, we need to import the RouterModule. And that should fix that, so whenever we
go back to the browser, there we go, and notice that we have links now. However, notice in the bottom left-hand
corner, the URL is products/products/1. So what we need to do is begin our URL
inside of our component, so let's go back. So for products, we need to begin that
with a slash, so let's save that. Let's go back to the browser, and that
URL should be fixed, there we go, it is. So if we click on Guitar,
that takes us to the guitar page, if we click on Piano, and
of course, Drums, they all work. So route parameters allow us to handle
routes based upon dynamic data. Just think of them as variables for
your routes. It's not an exaggeration to say that
Angular fundamentally changed the way that we build web applications. It absolutely did by making it so
much easier to build interactive and responsive user interfaces. In fact, Angular provided the inspiration that can
be found in every UI framework today. And now you have the knowledge and tools to use this powerful framework to
start building your own applications. Throughout this course, you learned how
to use the Angular CLI to create and manage your projects. You know how to use directives and templates to display
your application's data. And you know how to bind data
to properties and attributes, as well as set up events. You learned how to create your own
custom components that handle input, output, and two-way binding. And you learned how to use Angular's
dependency injection and HTTP services. And of course, now you know how to build
single-page applications using Angular's built-in router. Now, I know full well how easy
it is to jump into a project and almost immediately get stuck. But thankfully, Angular's community is so
helpful, so don't be afraid to reach out. And of course, you can always
contact me through Twitter or the Tuts+ forums if you
have any questions. Thank you so much for
watching this course. If you found it useful, please like the
video and subscribe to Envato Tuts+ for more free courses and tutorials. We have a lot, and there are more to come. From all of us here at Tuts+, thank you,
and I will see you next time.
