(This post is part of my “from scratch” AngularJS project. If you are feeling lost, the first post is here.)
Now that we have gulp setup and running and merging our files via gulp-concat, we don’t need to stop there. Let’s go ahead and make some more tasks to run and make our lives easier.
(This post is part of my “from scratch” AngularJS project. If you are feeling lost, the first post is here.)
We’ve created quite a lot of files in just our application so far. Unfortunately, for every one of those files, it means we need to add an include to our index.html file and increase the request count for visitors just to load the app. Wouldn’t it be nice if we could just package all of our code into one file and just load that file in the application? That’s exactly what we’ll set out to do here.
There are a TON of applications that will get us the end result we are looking for: browserify, require, webpack, etc. Although, in my opinion, the simplest and easiest to understand is gulp-concat. At its very basic form, gulp-concat literally merges the files you give it into one output file. To get it going, we’ll need to have gulp installed, and get to gulp installed, we really should know what it is doing first!
(This post is part of my “from scratch” AngularJS project. If you are feeling lost, the first post is here.)
Previously, I had mentioned that test driven development hasn’t really “stuck” for me and I find myself switching back to BDD for the most part. I find that this is usually because I don’t plan features out far enough in advance and I’m more of the “experiment and refactor” kind of developer. I have found instances where TDD actually works better for me, and today’s topic is one of those instances.
We are going to be working on the card service. This service will allow us to get a deck of cards, shuffle the deck, deal from the deck. Since this blackjack project is a game based off of set rules, we know how the cards should behave. We can write tests against these rules and then we’ll write our service to meet the rules. The rules are:
Now let’s write those tests:
(This post is part of my “from scratch” AngularJS project. If you are feeling lost, the first post is here.)
Now that we have used views, directives and controllers, let’s move on to another big part of the AngularJS library, “Services”. If you’ve used angular for any amount of time, I’m pretty sure you’ve already googled “What is the difference between service, factory and provider?”. I know I have and I still haven’t fully grasped it yet. The best answer I can give is that if you need it to be runtime configurable, use a provider. Otherwise, use a factory. Why? Because John Papa said to! Services and factories are nearly identical, but using the revealing module pattern, you can make them really look like header and implementation files, which makes the Objective-C developer in me very happy!
(This post is part of my “from scratch” AngularJS project. If you are feeling lost, the first post is here.)
Going back to our first controller, we had to throw a lot of code into our shell.html file to display our game. This code had to know a lot about how the GameController functioned and if we wanted to have multiple copies throughout the application, we would need to duplicate this code every time.
Thankfully, AngularJS gives us the ability to place complex objects into our html code with very simple format. This ability is called angular “directives”. Angular is built on directives. In fact, we’ve already used a few built in directives in the shell.html file: “ng-if”, “ng-controller”, “ng-click”. Let’s get started making our own!
We are going to create a new file called game.directive.js in our app/game folder. Here is that file:
(function(){
'use strict';
angular
.module('blackjack.game')
.directive('blackjackGame', blackjackGame);
function blackjackGame(){
return {
restrict: 'E',
templateUrl: 'app/game/game.directive.html',
controller: 'GameController',
controllerAs: 'game'
}
}
})();
Whatever we call our directive will be what is used in the implementation of it in html. Angular auto converts our camel case “blackjackGame” into “blackjack-game” for usage. There is also a trend (that I’m following in this example) of prefixing your directive with some sort of namespace tactic. Our namespace is ‘blackjack’. Had we called our directive “game” instead, then down the road used some sort of third party directive with the same name, we would’ve had issues. This way eliminates those issues.
The format for the directive method has some complicated options, but we will keep this one reasonably sane. I’ve previously written about the ‘restrict’ option, but just know that ‘E’ will require us to use the element name like so:
<blackjack-game></blackjack-game>
The controller and controllerAs replaces the “ng-controller=’GameController as game'” from shell.html. The templateUrl tells angular where to get the html to fill this directive with. game.directive.html looks like so:
<div> <div ng-if="!game.started"> <button class="btn btn-primary" ng-click="game.start()">Start Game</button> </div> <div ng-if="game.started"> Game In Progress <button class="btn btn-danger" ng-click="game.end()">End Game</button> </div> </div>
Starting to look familiar? We’ve simply ripped this out of the shell.html file. Now our main area in shell.html looks like this:
<div class="primary-area"> <h1>Welcome to Angular Blackjack</h1> <blackjack-game></blackjack-game> </div>
This makes the main html component easy to read and understand what is happening on the page. There are lots more options for directives, but since this is a very basic one, we won’t configure it any more.
We’ve now created our first custom directive and replaced lots of lines of code in our template with one simple line!
Here is the result of our work
Hope you all are enjoying this series. Please feel free to reach out with any questions or concerns.
Up Next: Services
Adam Weeks 