{"id":6664,"date":"2015-03-25T10:00:03","date_gmt":"2015-03-25T01:00:03","guid":{"rendered":"http:\/\/www.techscore.com\/blog\/?p=6664"},"modified":"2018-11-14T16:33:48","modified_gmt":"2018-11-14T07:33:48","slug":"angularjs-basic-setup","status":"publish","type":"post","link":"https:\/\/www.techscore.com\/blog\/2015\/03\/25\/angularjs-basic-setup\/","title":{"rendered":"AngularJS Basic Setup"},"content":{"rendered":"

Hello!\u00a0 My name is Andrew MacKinnon and I'm a Systems Engineer at Synergy Marketing.<\/p>\n

Several months ago between projects I decided to learn more about frontend JavaScript frameworks and see if it could be applied to the next project I was assigned. \u00a0I looked at various frameworks including Backbone.js<\/a>, Ember.js<\/a> and AngularJS<\/a>. \u00a0In the end my dabbling paid off and we settled on using AngularJS for the next project, mostly due to community size, amount of resources and initial learning curve.<\/p>\n

In this article I will explain our initial setup of AngularJS.<\/p>\n

* I\u2019ve updated the versions of software where needed to match the current available versions. \u00a0Look at the respective site for each tool to see the current version \/ instructions before installing.<\/p>\n

NVM (Node Version Manager https:\/\/github.com\/creationix\/nvm<\/a>) is a tool to manage multiple active Node.js versions. \u00a0This is useful if any of our other tools, such as the test suite, change to require a different version of Node.js. \u00a0It will make upgrading (or downgrading) a simple task.<\/p>\n

To install I used wget and the bash installation script (instructions on the NVM github page)<\/p>\n

> wget -qO- https:\/\/raw.githubusercontent.com\/creationix\/nvm\/v0.24.0\/install.sh | bash<\/pre>\n
Node.js<\/h2>\n
Since NVM is installed, installing Node.js is a trivial matter.<\/p>\n
> nvm install v0.10.37\r\n> nvm alias default v0.10.37\r\n<\/pre>\n
The 0.10.x series was used because it is one of the two versions that the test suite selected supports (http:\/\/karma-runner.github.io\/0.12\/intro\/installation.html<\/a>).<\/p>\n
NPM<\/h2>\n
NPM (Node Package Manger) is the default package manager that comes with Node.js. \u00a0We\u2019ve been using it to install and manage packages that are used for development and testing.<\/p>\n
Packages installed using NPM can be done on a global level (all projects can use it) or locally to a given project. \u00a0This can be controlled by using the -g flag. \u00a0Multiple packages can also be installed at the same time by separating package names with a space.<\/p>\n
> npm install -g bower grunt-cli karma-cli yo generator-angular\r\n<\/pre>\n
One thing that is important to note: Any global packages installed for a given Node.js installation is for that Node.js version only. \u00a0For each Node.js version installed using NVM, global packages will need to be re-installed.<\/p>\n
Bower<\/h2>\n
We use Bower (http:\/\/bower.io<\/a>) as a package manager for libraries included as part of the website itself. This also includes the library for mocking backend processes. \u00a0We installed it globally to allow us its use in any project without having to install it for each project.<\/p>\n
> npm install -g bower\r\n<\/pre>\n
Grunt<\/h2>\n
Grunt (http:\/\/gruntjs.com<\/a>) is a JavaScript task runner. \u00a0Task runners help automate various tasks such as minifying, concatenating JavaScript files into a single file, automatically running JSHint and automatic running of test cases during development.<\/p>\n
Grunt is generally installed on a per project basis, so we installed the command line interface globally to allow us to access the Grunt version installed for the project from the command line.<\/p>\n
> npm install -g grunt-cli\r\n<\/pre>\n
Yeoman<\/h2>\n
Yeoman (http:\/\/yeoman.io<\/a>) is a web scaffolding tool. \u00a0Yeoman by itself is a good tool to help get the initial project started, but the Yeoman workflow helps with development, building and managing the project. \u00a0This workflow includes Yeoman, a build system and a package manager.
\nTo use Yeoman, first it needs to be installed.<\/p>\n
> npm install -g yo\r\n<\/pre>\n
Next the generator that will be used needs to be installed. \u00a0The generator can be chosen from the available existing ones, or you can create your own. \u00a0We went with the AngularJS generator provided by the Yeoman team.<\/p>\n
> npm install -g \u00a0generator-angular\r\n<\/pre>\n
Testing Libraries<\/h2>\n
One of the big advantages of using a frontend framework is the ability to do unit testing. \u00a0Done right, this can reduce the amount of time needed for manually testing the user interface and result in increased time to create new functionality.<\/p>\n
It was decided to use Karma runner and Jasmine assertion library for the unit tests and Protractor for E2E (end to end) tests. How the tests were written and how Protractor was used is a topic for another time though.<\/p>\n
The Yeoman AngularJS generator has Karma included in the Bower configuration, so there was no need to explicitly add it. \u00a0However, we did add the Karma command line interface so Karma could be executed from the command line.<\/p>\n
> npm install -g karma-cli\r\n<\/pre>\n
This is a global install so it can be accessed from any project. \u00a0Karma and Jasmine on the other hand are installed locally to each project, allowing us to change versions on a project by project basis.<\/p>\n
The Setup<\/h2>\n
Using Yeoman and generator-angular, we executed Yeoman from the command line.<\/p>\n
> yo angular demo\r\n<\/pre>\n
Following the prompts we selected to not use Sass, to use Bootstrap and left the modules as the default selections.<\/p>\n
\"Yeoman<\/a><\/p>\n
NPM install and Bower install are automatically run, causing the preset packages to be downloaded and installed into the local project.<\/p>\n
Sometimes errors do come up during the install process. \u00a0Unfortunately, these need to be handled on a case by case basis.<\/p>\n
After the installation is completed and any errors that came up during the install fixed, we then installed tools needed for unit tests (saving them as a development packages to the package.json file used by NPM).<\/p>\n
> npm install karma-phantomjs-launcher karma-jasmine grunt-karma --save-dev\r\n<\/pre>\n
note: PhantomJS (http:\/\/phantomjs.org<\/a>) is a headless WebKit that is used in place of a browser for testing. \u00a0For full testing actual browsers should be used, but for simple unit tests this is enough.<\/p>\n
A few lines in Gruntfile.js, located in the project root, were changed to allow us to load the site from other machines and to not automatically open a new browser window when the server is started.<\/p>\n
    \/\/ The actual Grunt server settings\r\n    connect : {\r\n      options : {\r\n        port : 9000,\r\n        hostname : '0.0.0.0',\r\n        livereload : 35729\r\n      },\r\n      livereload : {\r\n        options : {\r\n        open: false,\r\n<\/pre>\n
This is done by changing the hostname to \u20180.0.0.0\u2019 and setting the open option to false inside livereload.<\/p>\n
At this point we can run the frontend on top of node using the Grunt task provided by the generator and view it in the browser.<\/p>\n
> grunt serve\r\n<\/pre>\n
Mocking<\/h2>\n
An important part of using a framework like AngularJS is being able to develop both the front and backend simultaneously. \u00a0This is possible because the frontend is no longer coupled with the backend; instead, the two communicate using JSON. \u00a0The result is a delay in the development of the backend doesn't slow down the development of the frontend. \u00a0The same goes for the reverse.<\/p>\n
The problem with not having a backend, is populating lists with records, testing how an invalid input appears in the frontend after receiving a response from the backend etc. \u00a0To solve this problem the records could be hardcoded as HTML or JavaScript somewhere, but that means it also has to be removed at some point before a production release. \u00a0To deal with this we use mocking.<\/p>\n
Mocking allows us to simulate a backend and can easily be configured to not include any of the mocking data into the production release. \u00a0For this we are using the bower-angular-mocks library(https:\/\/github.com\/angular\/bower-angular-mocks<\/a>). \u00a0It is installed using Bower and saved for development only.<\/p>\n
> bower install angular-mocks --save-dev\r\n<\/pre>\n
Since this is being saved as a development dependency, it is not automatically added to the index.html file. \u00a0To use it, we needed to add it manually:<\/p>\n
<script src=\"bower_components\/angular-mocks\/angular-mocks.js\"><\/script><\/pre>\n
The problem now is how to automatically remove this from the production build. \u00a0This can be done by using a library to process the HTML and configure grunt to remove it during the production build.<\/p>\n
The grunt-processhtml library (https:\/\/github.com\/dciccale\/grunt-processhtml<\/a>) is used to manipulate the index.html file during a build. \u00a0We used this to remove the angular-mocks.js and associated files during the production build process.<\/p>\n
> npm install grunt-processhtml --save-dev\r\n<\/pre>\n
Add a new setting for processhtml within the Gruntfile.js initConfig object.<\/p>\n
 <\/p>\n
processhtml : {\r\n  options : {\r\n    commentMarker: 'process'\r\n  },\r\n  dist : {\r\n    files : [{\r\n      expand : true,\r\n      cwd : '<%= yeoman.dist %>',\r\n      src : ['*.html', 'views\/{.*}*.html'],\r\n      dest : '<%= yeoman.dist %>'\r\n    }]\r\n  }\r\n}\r\n<\/pre>\n
Processhtml is configured to look for comments using the keyword \u2018process\u2019. \u00a0If the build is dist (distribution) then it will move any required files to the production directories.<\/p>\n
Next we add this to the Grunt task.<\/p>\n
grunt.registerTask('build', [\r\n  'clean:dist',\r\n  'wiredep',\r\n  'useminPrepare',\r\n  'concurrent:dist',\r\n  'autoprefixer',\r\n  'concat',\r\n  'ngAnnotate',\r\n  'copy:dist',\r\n  'cdnify',\r\n  'cssmin',\r\n  'uglify',\r\n  'filerev',\r\n  'processhtml', \/\/ <== here!\r\n  'usemin',\r\n  'htmlmin'\r\n]);\r\n<\/pre>\n
Each time the build task is run, processhtml will also be run.<\/p>\n
Next index.html had to be set up to automatically remove mock files during a production build.<\/p>\n
<!- build.js(.) scripts\/vendor.js -->\r\n<!-- bower.js -->\r\n<script src=\"bower_components\/jquery\/dist\/jquery.js\"><\/script>\r\n<script src=\"bower_components\/angular\/angular.js\"><\/script>\r\n<script src=\"bower_components\/bootstrap\/dist\/js\/bootstrap.js\"><\/script>\r\n<script src=\"bower_components\/angular-animate\/angular-animate.js\"><\/script>\r\n<script src=\"bower_components\/angular-aria\/angular-aria.js\"><\/script>\r\n<script src=\"bower_components\/angular-cookies\/angular-cookies.js\"><\/script>\r\n<script src=\"bower_components\/angular-messages\/angular-messages.js\"><\/script>\r\n<script src=\"bower_components\/angular-resource\/angular-resource.js\"><\/script>\r\n<script src=\"bower_components\/angular-route\/angular-route.js\"><\/script>\r\n<script src=\"bower_components\/angular-sanitize\/angular-sanitize.js\"><\/script>\r\n<script src=\"bower_components\/angular-touch\/angular-touch.js\"><\/script>\r\n<!-- endbower -->\r\n<!-- endbuild -->\r\n\r\n<!-- process:remove:dist -->\r\n<script src=\"bower_components\/angular-mocks\/angular-mocks.js\"><\/script>\r\n<!-- \/process -->\r\n\r\n<!-- build:js({.tmp,app}) scripts\/scripts.js -->\r\n<script src=\"scripts\/app.js\"><\/script>\r\n<script src=\"scripts\/controllers\/main.js\"><\/script>\r\n<script src=\"scripts\/controllers\/about.js\"><\/script>\r\n<!-- endbuild -->\r\n\r\n<!-- process:remove:dist -->\r\n<script src=\"devmock\/app-mock.js\"><\/script>\r\n<!-- \/process -->\r\n<\/pre>\n
There are a couple sets of HTML comments. Originally the ones starting with \u2018build:js\u2019 were built as part of the generator used. What they are doing is telling bower to compact all of the files listed between the opening and closing comments into a single file (eg. create the vendor.js file and place it into the scripts directory). This will allow the browser to cache the file so it doesn't need to download the file until it changes. That reduces HTTP requests and helps speed up the page when it first loads.<\/p>\n
Similarly we\u2019ve added two new comment blocks using the keyword \u2018process\u2019. In these blocks we are telling Grunt to remove the contents between the comments during a production build. You might have noticed that the second block has a file called \u2018app-mock.js\u2019. Keep reading, I\u2019ll explain that a little further down.<\/p>\n
The AngularJS application needs to be configured to use angular-mocks. Normally the AngularJS application is set in index.html in such a way that it is automatically bootstrapped when the page loads. To completely remove the mock files during production, I found it easier to manually bootstrap AngularJS.<\/p>\n
First, remove the ng-app attribute from the body tag in index.html<\/p>\n
<\/head>\r\n<body>\r\n<\/pre>\n
Second, bootstrap the application inside the app.js file (if the mocking files are not present)<\/p>\n
(function() {\r\n  if(!angular.mock) {\r\n    angular.element(document).ready(function() {\r\n      angular.bootstrap(document, ['demoApp']);\r\n    });\r\n  }\r\n})();\r\n<\/pre>\n
This tells AngularJS to bootstrap if angular.mock is not present.<\/p>\n
Third, create a new file and place it somewhere that best suits your directory structure. In our case, we created a directory called \u2018devmock\u2019 inside app and a file called app-mock.js.<\/p>\n
'use strict';\r\n\r\nangular.module('demoAppDev', ['demoApp', 'ngMockE2E']).run(\r\n  function($httpBackend) {\r\n  });\r\n\r\nif(angular.mock) {\r\n  angular.element(document).ready(function() {\r\n    angular.bootstrap(document, ['demoAppDev']);\r\n  });\r\n}\r\n<\/pre>\n
In this file the application is being bootstrapped and demoApp included as a module.<\/p>\n
At this point the mock setup is complete. There is only one thing left to do before we can load the server up and look at our web application. We need to tell the mock that calls to get HTML files are to be allowed. This is done by adding a call to passThrough inside the run block.<\/p>\n
angular.module('demoAppDev', ['demoApp', 'ngMockE2E']).run(\r\n  function($httpBackend) {\r\n    $httpBackend.whenGET(\/^views\\\/main\\.html\/).passThrough();\r\n  });\r\n<\/pre>\n
This tells angular-mocks that anytime a request for the views\/main.html file is intercepted, it should just let it go without stopping it. The parameter is a regular expression, so it can be changed to match any URL. This comes in handy when you want to load a list. You can write the production code exactly as you would for a backend and intercept the API call here, then return the JSON list without connecting to an actual backend server.<\/p>\n
angular.module('demoAppDev', ['demoApp', 'ngMockE2E']).run(\r\n  function($httpBackend) {\r\n    $httpBackend.whenGET(\/^\\\/api\\\/foo\\\/bar\\\/list\/).respond(function(method, url) {\r\n      return [200, {data: ['foo', 'bar']}];\r\n    });\r\n    $httpBackend.whenGET(\/^views\\\/main\\.html\/).passThrough();\r\n  });\r\n<\/pre>\n
Wrap-up<\/h2>\n
This is just a simple example of how we first configured AngularJS. \u00a0It slowly changes to match requirements and as we learn better ways. \u00a0There are a number of areas I glossed over without going into detail. \u00a0For now, I\u2019ll leave those points for you to look up if you\u2019re interested.<\/p>\n","protected":false},"excerpt":{"rendered":"
Hello!\u00a0 My name is Andrew MacKinnon and I'm a Systems Engineer at Synergy Marketing.<\/p>\n
Several mont
\u7d9a\u304d\u3092\u8aad\u3080...<\/a><\/p>\n","protected":false},"author":36,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[18],"tags":[161,173,163,166,170,46,172,164,165],"_links":{"self":[{"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/posts\/6664"}],"collection":[{"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/users\/36"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/comments?post=6664"}],"version-history":[{"count":25,"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/posts\/6664\/revisions"}],"predecessor-version":[{"id":6834,"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/posts\/6664\/revisions\/6834"}],"wp:attachment":[{"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/media?parent=6664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/categories?post=6664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techscore.com\/blog\/wp-json\/wp\/v2\/tags?post=6664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}