Ultimate AngularJS: Build a Real-World App from Scratch

The web has changed a lot since the early days, and one of the reasons we're able to make single page apps with frameworks like AngularJS is because JavaScript has improved a substantially. Let's take a closer look at what single page apps are and how they differ from traditional round-trip applications.

Creating single page apps with plain old JavaScript is possible, but it's difficult. Let's see where exactly AngularJS fits in and how it helps us to develop SPAs.

AngularJS has many great features and is great to work with, but there are a few downsides that we should consider as well. Let's take a look at some of the ways Angular falls short, but also why it's worth using.

We need a few tools before we start our project, including:

• A text editor
• The native terminal or program like iTerm2
• NodeJS

Let's get these installed and configured.

We'll need a solid project directory structure for the application we'll be building. The way that we organize our directory for an AngularJS app comes down to a mix of preference and practicality, so we'll stick with a pretty standard structure that you'll see in a lot of larger apps. We'll use the command line to create our folders and files so that we can get a better feel for how to use it.

The best way to get up and running with an AngularJS app is a simple "Hello, World" example. Let's set one up to see how to bootstrap an Angular application.

There are many patterns in software development, and one of the most popular is the MVC pattern, which stands for "Model-View-Controller". AngularJS uses the MV* (the * meaning "whatever"), but let's take a look at what's involved in the MVC pattern to get some context.

Controllers are a core feature of AngularJS and they are used to communicate data to our views. Let's take a look at how to wire up a controller and send some test data to a view.

When starting out with Angular, often one of the first pieces of "magic" that we see is the mysterious $scope object. Let's take a look at what $scope is used for and how we can use it to link our controllers and our views together.

You might have already seen two-way data binding at work if you've looked at any AngularJS examples. With two-way data binding, we can bind an input to a text element and the two will update one another automatically. This is a cool feature that doesn't require any extra JavaScript on our part.

We've already seen some of the features of Angular's tempting as we've been doing these simple examples. Let's take a closer look at tempting to see what else it can do for us.

Dependency injection is all about how we get a hold of other pieces of code that we need in our apps. AngularJS has its own dependency injection system which offers a convenient and simple way for us to tell our controllers which dependencies we need. Let's take a look at how it works.

Sometimes when we use a third-party library in AngularJS, we want to be able to set some configuration on it. Providers offer us a way to do this. Let's take a look at how to customize the Angular Material library using the provider that comes with it.

Directives are a powerful feature of AngularJS that allow us to create custom HTML elements and define their behavior. Even though we're at the first stages of learning Angular, it's useful to get a glimpse into what directives are and how they work so that we can make sense of the directives that Angular Material provides.

Angular Material gives us many ready-to-use components and the first one we'll make use of is the toolbar. This will give us a top navigation area. We also need to craft the individual classified cards.

Most single page application frameworks have a "repeater" which gives us a way to loop over an array and repeat whatever we want for each item. In most cases, we want to template something out on each iteration.

With filters we can easily change how our data is displayed in our views. This is useful for things like currency, dates, and casing. Since we have price data for our application, we'll put in the currency filter.

Most applications will need to hide and display different parts of the user interface based on some condition. This is useful for letting users do things like toggle sections of the app on and off. Let's take a look at the various ways we can conditionally hide and show elements.

So far, we've just been working with data that comes from our controller, but what we actually need is a way to fetch data from somewhere else. Since most applications will use remote data sources, we'll find out how to use Angular's $http service to make requests for data.

Angular's $http service returns promises when we make requests for data. Let's take a look at how to use $http and handle the response from a GET request.

As our applications grow, we'll often find that we need to make the same HTTP requests in multiple areas of our application. Instead of repeating our code, we can create a service that abstracts the HTTP logic to one location. We'll use a factory to do this.

We need to make it possible for users to create, read, update, and delete classifieds. Angular Material provides a nice sidenav directive that we can use for our input form. Getting the form up and running will require a little bit of JavaScript in our controller.

With the sidenav in place, we can how write the code that will accept new classifieds and save them locally to be displayed on the screen.

We can make use of our existing sidenav for editing classifieds. All we need to do is adapt it to handle that task by implementing an edit method which changes the values of existing data.

Deleting classifieds is a fairly straightforward matter--we just need to remove the specified data object from our array. This can be done by splicing it out.

We've already seen how filters work when we want to change the way a value gets displayed, but we can also use them to limit the data that gets displayed on the screen based on a search parameter. To do so, we need to bind an input element to a filter on the ng-repeat for our data.

AngularJS makes it really easy to add animation to our apps if we use the angular-animate library. With it, we just need to add some CSS that describes how we want our animations to look.

Without routing, our whole application lives at one single URL. This is bad because we don't have a way to send people a link to a specific location within our apps. We should compare native desktop apps with web apps to get a sense of the concepts involved with routing.

With UI Router we deal in "states" of the application instead of routes. Let's take a look at how states work and how to configure them.

One of the problems with $scope is that we can easily get confused about property names in our views. However, if we use the "controller as" syntax, we can define a for our controllers that gives us explicit naming.

Switching over to UI Router means that we have to refactor what we've build already and split things into separate components. It will be best if we start by turning the main part of our application (the classified listings) into a state with a URL route called "classifieds".

We want to have a distinct state for adding in new classifieds so that we can send someone a link to our app that has the sidebar open and ready to accept input for a new classified. We'll wire it up so that people can access the new classifieds state at /classifieds/new.

Sometimes we need to be able to fire events and listen for them in our application so that we can act on those events. An example of this would be re-routing the user to the main classifieds state when the sidebar closes. We can make this happen with a watcher by accessing $scope.$watch.

Now that we've split our app out into different controllers, we need a way to communicate data between them. For example, we need a way to tell our parent classifieds controller that a new classified has been added in so that it can be pushed onto the classifieds array. We can do this with $scope.$emit.

If we want to be able to send someone a link to edit a specific classified then we need to be able to reference that particular classified in the URL bar. With UI Router we can have any of our URL parameters be variables, which is perfect in this case.

Firebase is a real-time data store that we can hook into very easily. The service provides a library called AngularFire that makes working with Angular simple. We won't need to change much of our code to get our data persisted to a backend.

Reading data from Firebase is easy and there are just a few changes we need to make to our code.

Since Firebase is a real-time datastore, when we add in a new classified from one device, we'll see it show up in our other devices immediately.

The final step is to enable editing and deleting of our Firebase data. The ID we use in the URL bar will change to be the unique ID provided for each data object by Firebase.

Directives are really useful because we can define custom HTML elements that wrap up any kind of complex bahavior we like. One of the keys to making them work is isolating their scope so that they are closed off from the outside world. Then, we make it possible for specific data to get in based on attributes we set up for the directive.

Our classified cards would make a great directive because there might be multiple places in our application that we would want to use them.

There are a few steps to making a directive that works well. Let's finish out the classified cards directive to make sure it has the behavior we expect.