Another Intro to Angular
I’ve heard some pretty cool stuff about Angular — people seem to like it. MVC(ish) on the front end? Sounds awesome! Two way data binding with your html? Crazy talk. Too bad the only thing I’ve done with it is make a todo list.Well let’s take a dive into creating and Angular application and see if we can turn that todo list into something with a little more substance. There are a couple different types of parts in an angular application you’re probably familiar with, but let’s review them real quick:
- Controllers
- Services
- Directives
- Factories
- Components
Each of these serve a different purpose, and can fulfill different roles throughout your application. Controllers manage actions like sending network requests, business logic for displaying elements, serving as an abstraction layer on top of other services, etc. whereas services are often used for managing data since they are singletons and only created once. Directives, on the other hand, are predominantly used for creating smaller, more isolated and testable components in your application — these are where you use all of your HTML templates. Factories are a bit of an outlier because they behave very similarly to services, however they’re really supposed to be used, as the name implies, as factories that create other objects similar to constructor functions in standard JS. There’s also a new kid on the block called a component, which acts similarly to a directive, however it doesn’t have a link function, and you should only be using bindings to the controller instead of to scope (don’t worry if you don’t know what those are, components are pretty new and you can just use directives for now).
But that’s not all! This may seem well and good, but how do you fit your whole application into a couple different directives or components? For a while, this was pretty much as far as I got, and yeah this allows for some pretty cool self contained, single-purpose tools, but there’s one key missing element that can take your Angular application from a tiny cluster of javascript to a fully fledged SPA (Single-Page-Application). That key is what’s called a router. This not only allows you to define separate urls for the various states and views of your application, but also handle transitioning and passing data between them, acting as a state machine for your application. What’s cool about that? Well now you can define different views, and control and maintain a consistent state without the need for managing any of that state on the back end.
This can be done relatively simply by setting various ui-views in your markup! eg.
<!-- index.html -->
<body>
<div ui-view=”left-pane”></div>
<div ui-view=”right-pane”></div>
</body>What a ui-view allows you to do is to tie different “states” (aka routes used by your router) that have templates, controllers, params, etc. in your routes file, for example:
// some-routes.js
app.config(function ($stateProvider) {
$stateProvider
.state(“index”, {
url: “/home”,
views: {
“left-pane”: { template: “<div> hello! </div>” },
“right-pane”: { template: “<div> goodbye :( </div>” }
}
});
});This can make adding functionality like a sidebar or floating overlay both extremely easy and modular. Woohoo! Now combine this with using directives, controllers, services, and factories and you have yourself a fully fledged application!
