The post that was here has been edited and re-published here: https://angular.io/docs/ts/latest/cookbook/a1-a2-quick-reference.html.

Enjoy!

If you are developing now in Angular 1.x with an eye toward Angular 2, the best thing you can do is to write your Angular code with TypeScript. Angular 1.x code you write in TypeScript today will look very similar to code you will write in Angular 2 tomorrow (not literally tomorrow!).

At a recent Angular conference, the members of the Angular team from Google stated that one of the best ways to code now in Angular 1.x in preparation for Angular 2 is to use TypeScript.

What is TypeScript?

TypeScript is an open-source programming language that is:

• A superset of JavaScript
• Including all of the current JavaScript syntax, plus much more.
• Any valid JavaScript code is valid TypeScript code. And as such, TypeScript works with all existing JavaScript frameworks, including Angular.
• TypeScript transpiles to plain JavaScript
• So we can deploy the resulting JavaScript files for our Angular application just as we do now.
• And the resulting files execute in any of today’s browsers on any OS.
• Plus there is no runtime overhead of using TypeScript because all of the types evaporate and the TypeScript-only syntax is replaced … leaving only pure JavaScript.
• TypeScript allows us to define strong types
• Editor tooling, such as the new Visual Studio Code editor, use these types for static type checking of our code during development
• This makes development, debugging, and refactoring easier.
• Plus it clarifies the developer’s intent. For example, we can define that a function is meant to take in a string. Not a number, not an object, just a string.
• And TypeScript provides class-based object-oriented programming techniques.
• So we can optionally think of our code in terms of objects with properties and methods.
• And the TypeScript compiler transpiles the classes into JavaScript functions.

Here is the code for an Angular controller, written using the class-based object-oriented programming techniques available in TypeScript.

To learn more about using Angular with TypeScript, check out the Pluralsight course: “Angular with TypeScript“

Enjoy!

Angular and ASP.NET Web API are like chocolate and peanut butter, they are GREAT together! But there are lots of intricacies and many, many things that can go wrong when putting these two technologies together. This problem solver covers some of the most common things that can go wrong and how to fix them.

Using Angular as the client technology in the front-end and an ASP.NET Web API service in the back-end is a common requirement. So much so, that I developed a Pluralsight course to help developers tackle all of the touch points between an Angular client application and a back-end ASP.NET Web API service: Angular Front to Back with Web API.

As of this writing, there have been over 400 posts associated with that course, many of which identify problems that developers have had in merging these two technologies. This post summarizes the most common issues and identifies locations in the course where solutions to these issues can be found

No Access-Control-Allow-Origin Header is Present

This issue first appears in module 3 (Retrieving Data) clip 6 (Calling the Web API from Angular). We created the ASP.NET Web API code in a project separate from the Angular code. So when the solution is executed:

• The ASP.NET Web API executes on one port, say http://localhost:52293
• The Angular code executes on another port, say http://localhost:52436

When the Angular code calls the ASP.NET Web API, it will work in Internet Explorer but *not* in Chrome. In Chrome, pressing the F12 tools will show the error: No “Access-Control-Allow-Origin” header is present, Status Code: 500 Internal Server Error.

This is a problem with cross-origin requests. Since the origin of the call is from http://localhost:52436 and the endpoint is at http://localhost:52293, the request is considered to be a cross-origin request. In other words, the request is originating at a different URL than the service. By default, cross-origin requests are denied. (This works in debug mode with IE because IE does not consider the difference in port numbers to be a cross-origin request.)

The solution to this problem is CORS, or cross-origin resource sharing. Wikipedia states that CORS “allows many resources … on a web page to be requested from another domain outside the domain from which the resource originated.” In other words, CORS defines a way that a service can interact safely with a browser application that originates on a different domain or different server.

To enable CORS in the ASP.NET Web API, start by downloading the CORS package using NuGet Package Manager.

Once CORS is installed, there are two additional steps:

1) Call the EnableCors method.

Open the WebApiConfig.cs file in the App_Start folder. Add this line to the Register method:

config.EnableCors();

2) Set the EnableCorsAttribute.

Set this attribute on any controller class that wants to allow cross origin requests. For example, on the ProductsController, it might look like this:

[EnableCorsAttribute(“http://localhost:52436″, “*”, “*”)]
public class ProductsController : ApiController
{}

Note that the port shown in red is the port for the Angular application. This code tells the PrioductsController class that it should allow cross-origin requests only from the defined location, which is from our Angular client application. Alternatively, use “*” to allow access from any cross-origin request.

These steps are covered in detail in module 4 (CORS and Formatters) clip 3 (Enabling CORS in a Web API service).

OData Does Not Work

This issue appears in Module 6 (Using OData Queries) and often takes the form of a problem with the contains method of the OData $filter. This problem is due to confusion on the multiple OData packages that are available in Visual Studio.

The course requires version 4 of OData, so be sure to select the NuGet package that says “OData v4.0” in the description.

NOTE: There are many similarly named NuGet packages, such as “Microsoft.Data.OData” and “Microsoft.AspNet.WebApi.OData”. Be sure to select the one shown below.

User Login Generates a CORS Error

This issue appears in module 10 (User Registration and Login). It often only occurs in Chrome (not IE).

There are two possible issues here:

1) There is one line of code that is missing from the demo in the course.

[EnableCorsAttribute(“http://localhost:52436″, “*”, “*”)]
public class AccountController : ApiController
{ }

This line of code enables CORS for the AccountController just as we did for the ProductsController earlier in the course (module 3)

2) There is one line of code added during the demo, but is sometimes missed when coding along.

In the Providers folder, ApplicationOAuthProvider.cs file, GrantResourceOwnerCredentials method, add the following line:

context.OwinContext.Response.Headers.Add(“Access-Control-Allow-Origin”,
    new[] { “http://localhost:52436″ });

Where the defined URL shown in red is the location of the Angular application that this code is granting access to.

This code is explained and demoed in module 10 (User Registration and Login) clip 4 (Logging the User In) starting around 9:32 with showing the error and the line of code is added at 10:13.

User Registration Network Methods

Several questions have come up regarding the network methods that occur when the Register button is selected to register a new user. I entered a new user name and password, then clicked the Register button. The results are shown below when using Chrome on Windows:

Hope this answers the questions.

Save Issues

I have not been able to reproduce any specific issue here … but if you have problems with the Save operation … Try changing this in productResource.js:

‘save’: {
    headers: { ‘Authorization’: ‘Bearer ‘ + currentUser.getProfile().token }
},

With this:

‘save’: {
    method: ‘POST’,
    headers: { ‘Authorization’: ‘Bearer ‘ + currentUser.getProfile().token }
},

Cannot Read Property ‘exceptionMessage’ of Null

This is most likely caused by the exception handling in mainCtrl.js. Change this:

function (response) {
    vm.password = “”;
    vm.message = response.statusText + “\r\n”;
    if (response.data.exceptionMessage)
        vm.message += response.data.exceptionMessage;

    if (response.data.error) {
        vm.message += response.data.error;
    }
});

To this:

function (response) {
    vm.password = “”;
    vm.message = response.statusText + “\r\n”;
    if (response.data && response.data.exceptionMessage)
        vm.message += response.data.exceptionMessage;

    if (response.data && response.data.error) {
        vm.message += response.data.error;
    }
});

Please let me know if you have run into anything else that should be added to this list.

Enjoy!

In my prior post (http://bit.ly/DeborahK_AngularServices) I outlined the difference between the factory pattern and service pattern when building a custom Angular service with JavaScript. In this post we’ll look at the differences when the Angular custom service is written in TypeScript.

Angular Custom Service

The basic code to create an Angular custom service in TypeScript is the same for both the factor pattern and the service pattern.

Here is an example of a simple custom service written in TypeScript, missing only the Angular module registration:

module app.common {
    export interface IHelloService {
        sayHello(text: string): string;
        sayGoodbye(text: string): string
    }

    export class HelloService implements IHelloService {
        sayHello(text: string): string {
            return “Hello ” + text;
        };
        sayGoodbye(text: string): string {
            return “Goodbye ” + text;
        };
    }
    <Module Registration Here>
}

This code begins with a TypeScript module. The TypeScript module encapsulates the code within an Immediately Invoked Function Expression (IIFE) and provides a clean namespace for the service.

The interface defines the intent of the service. The service intends to provide a sayHello method and a sayGoodbye method. Both take in a string parameter and return a string.

The service class is exported so that it can be used from any other Angular code, such as an Angular controller. The class implements the defined interface, thereby committing to implement every property and method defined in that interface. In our case, it is committing to implement the two methods.

The primary difference between the factory pattern and service pattern when building an Angular service with TypeScript is the module registration. Let’s take a look at how that registration is different.

Service Pattern

When using the service pattern, the TypeScript code to register the service with an Angular module is straightforward.

Simply call the service method:

angular
        .module(“helloWorld”)
        .service(“helloService”,
                         HelloService);

Insert the above code into the service example in place of <Module Registration Here> and you have a working service using the service pattern.

Factory Pattern

Using the factory pattern, the registration code is a little more complex.

As shown in the prior post (http://bit.ly/DeborahK_AngularServices), an Angular factory returns an object. When building the service with a TypeScript class, a class itself cannot return an object. Properties and methods of the class can return an object, but the class itself cannot.

So when using the factory pattern with TypeScript, the trick is to define a function that creates an instance of the service and returns an object. The code for that looks like this:

function factory(): HelloService {
    return new HelloService();
}

angular
    .module(“helloWorld”)
    .factory(“helloService”,
                     factory);

Insert the above code into the service example in place of <Module Registration Here> and you have a working service using the factory pattern.

Enjoy!

For more information on this and many other techniques when building an Angular application with TypeScript, check out my Pluralsight course: “Angular with TypeScript”

When we want reusable code in our Angular application we build a custom Angular service. We can then use that service in any Angular code that needs it. There are several types of services available in Angular, but there are two types that are used most often: Factory and Service

Factory

We can create a service as an Angular factory, also known as a “factory service”.

Here is an example of a simple factory written in JavaScript:

app.factory(‘helloService’, function(){

   return {

      sayHello: function(text){

         return “Hello ” + text;

      },

      sayGoodbye: function(text){

         return “Goodbye ” + text;

      }

   }

});

With a factory-style service we return an object with properties and methods. In this example, the object has two methods: sayHello and sayGoodbye.

This is the recommended and most commonly used type of custom service when coding in JavaScript.

Service

Alternatively, we can create a service as an Angular service, also known as a “service service”.

Here is an example of a simple service written in JavaScript:

app.service(‘helloService’, function(){

   this.sayHello= function(text){

        return “Hello ” + text;

   };

   this.sayGoodbye = function(text){

        return “Goodbye ” + text;

   };

});

With a service-style service, we don’t return anything directly. Rather, we define the service properties and methods on “this”. Those methods may return something, but the service function itself does not.

In many scenarios, it is easier to use a service-style service when coding in TypeScript. In looking at the two different sets of code here, the body of the service code looks more similar to code we would expect to see within a class.

Enjoy!

When working on an Angular application, it is important to ensure that the browser does not keep prior versions of your JavaScript or other files cached. Otherwise, when you make a change to a JavaScript or HTML file and re-run the application, you may not see your changes.

Here are the steps to ensure that Internet Explorer does not cache your files:

1) Select the Tools icon and select Internet options:

2) Click the Settings button (on the General tab)

3) Select the desired option. I often pick “Every time I start Internet Explorer”

Enjoy!

It is sometimes difficult to find detailed step-by-step guidance for building an application using Angular and ASP.NET Web API. The Pluralsight course: “Angular Front to Back With Web API” covers the following topics from front to back:

• Retrieving Data
• CORS and Formatters
• Passing Parameters
• Using OData Queries
• Saving Data
• Action Results, Error Handling & Validation
• User Authentication & Authorization

(If you don’t have a Pluralsight membership, sign up for a free trial here.)

Here are some of the comments about the course from Twitter and the course discussion page:

Awesome WebAPI + Angular course!

Thanks for your great course, it helped me to understand how to establish different CURD action between front end and back end.

oh yea! Your course rocks too! Even a beginner can view this course and your other one and be successful.

Great course, it is really concise and to-the-point.

First of all I would like to congratulate you on publishing a fantastic set of courses on AngularJS Line of Business Apps and more so recently Angular Front to Back with Web API. I think what stands out for me is the way in which you provide holistic approach to delivering excellent technical content.

I Love your angularjs pluralsight courses. Learnt a lot and using at work.

Your classes on AngularJS on pluralsight is my reason am better than my peers, thanks

Thank you for building a .Net course F2B that uses (vm = this) and (controller as) syntax!!! You rock.

Enjoy!

Developers interested in building great business applications with AngularJS are finding the Pluralsight course: AngularJS Line of Business Applications to be just what they need.

(If you don’t have a Pluralsight membership, sign up for a free trial here.)

Here are some of the comments in the discussion section for the course:

You’ve built a complete application, which is awesome!

Excellent course. One of the best ones I have ever seen.

Deborah, this is by far the best Angular.js course I’ve seen in the last two years. And believe me, I watch them all. But somehow you’ve managed to explain it so well that I really feel like I can finally make my own applications!

Great course, wish I would of started with it 🙂

Deborah, you speak human language. I loved your style of teaching!

Thanks for the great course! I really appreciated the systematic reinforcement of software engineering best practices that never fell by the wayside, even while building a demo app.

One of the best course on AngularJS at intermediates level. What i liked the most is the pace & clarity on each of the topic covered. I would highly recommend this course.

This course covers the following topics:

• Introduction
• Building the First Page
• Accessing Data
• Routing to Multiple Views
• Building Data Entry Forms
• Validating Forms
• Defining Business Logic in an Angular Service
• Visualizing Data With Charts
• Exception Handling
• Final Words

Enjoy!

One of the many new features in AngularJS 1.3 is the ability to reuse validation messages.

When displaying validation messages, you may find that you often reuse very similar messages:

“Class name must be entered.”  “Start date must be entered.”  “End date must be entered.”

Wouldn’t it be nice if you could reuse error messages instead of repeating them throughout the application? Angular 1.3 provides an ngMessagesInclude directive as part of the new Angular ngMessages module that allows you to share error messages throughout an application.

This post shows you how to use this new feature.

For more information about the new features in AngularJS 1.3, check out my latest Pluralsight course, authored with Joe Eames:

What’s New in Angular 1.3

Reusing validation messages in Angular requires the following steps:

1. Create an HTML file for the common messages.
2. Include the HTML file in the same element as ngMessages.
3. Override any messages as required.

Let’s take it one step at a time.

NOTE: If you are new to using ngMessages, check out the Angular 1.3 course.

Create the Messages File

The first step is to create the HTML template file for the common message text. In this file, add HTML with an ng-message attribute for each message. The value of the ng-message attribute must be a valid $error object key. That key is often the name of the validation type, for example: required, minlength, or maxlength.

The message text itself should be generic, meaning it should not refer to specific field names or field requirements.

The resulting HTML file could look something like this:

<span ng-message=”required”>
This item cannot be blank.</span>
<span ng-message=”minlength”>
You have not met this item’s minimum length.</span>
<span ng-message=”maxlength”>
You have exceeded this item’s maximum length.</span>

Include the HTML File

The next step is to include the messages HTML file for each input element that wants to reuse the messages using ng-messages-include. Insert this directive in the same element containing the ng-messages directive.

The following shows an Email field with a label, textbox, and validation. The entire form-group is shown below to provide context for the validation messages.

<div class=”form-group”
     ng-class=”{‘has-error’:classForm.inputInstructorEmail.$invalid &&
                            classForm.inputInstructorEmail.$touched}”>
    <label class=”col-md-2 control-label”
           for=”inputInstructorEmail”>Instructor’s Email</label>

    <div class=”col-md-4″>
        <input class=”form-control”
               type=”email”
               id=”inputInstructorEmail”
               name=”inputInstructorEmail”
               placeholder=”instructor’s email”
               ng-model=”vm.class.instructorEmail”
               required
               minlength=”6″ />
    </div>
    <span class=”help-block has-error”
          ng-if=”classForm.inputInstructorEmail.$touched”
          ng-messages=”classForm.inputInstructorEmail.$error”
          ng-messages-include=”app/errorMessages.html” >
        <span ng-message=”email”>
            Instructor’s email must be a valid email address.
        </span>
    </span>
</div>

Notice that the only ng-message directive included in the code above is for an invalid email address. This one is required here because it was not included in the messages html file.

Override Messages as Required

There may be times when you want a customized message. In those cases, you can easily override a message by simply adding a child element with an ng-message directive. The child element ng-message will always override any message defined for the same key in the included messages file.

    <span class=”help-block has-error”
          ng-if=”classForm.inputInstructorEmail.$touched”
          ng-messages=”classForm.inputInstructorEmail.$error”
          ng-messages-include=”app/errorMessages.html” >
        <span ng-message=”email”>
            Instructor’s email must be a valid email address.
        </span>
        <span ng-message=”minlength”>
            Instructor’s email must be at least 6 characters in length.
        </span>
    </span>

Use this technique any time you want to reuse messages throughout your application.

Enjoy!

Wouldn’t it be great if everything always just worked? That we never had a runtime error… That the server-side Web services were always available and worked? But we know that is not the case. Things go wrong.

The most common ways to handle exceptions in an Angular application are:

• With a JavaScript try/catch block
• You can add a try/catch block around code that could fail
• That allows you to catch specific errors and handle them appropriately.
• You can use the Angular global exception handler
• Angular has a built-in service, called $exceptionHandler, that catches exceptions
• By decorating this service, you can tailor it to the needs of your application.
• When working with promises, you can also add failure or catch functions

This post covers the second option, using the Angular global exception handler.

If you are interested in more information, I cover exception handling in detail in my Pluralsight course: “AngularJS Line of Business Applications“.

Decorating $exceptionHandler

Angular provides a built-in global exception handling service called $exceptionHandler. Any uncaught exception is delegated to this service. This service only catches exceptions, not communication errors (such as 404 not found) or syntax errors.

The default implementation of $exceptionHandler logs any exceptions to the browser console. You can change this functionality by decorating the $exceptionHandler service.

Say we wanted to change the default global exception handler to display a message to the user. We could accomplish this by decorating the $exceptionHandler service as shown in the code below:

• Line 14:
• The above code configures the application with a decorator.
• The code needs the Angular built-in $provide service, so it is passed as a parameter to the configuration function.
• Line 15:
• The $provide service is used internally as part of Angular’s component registration process.
• The decorator method of this service can intercept requests and provide different or additional functionality.
• The decorator method takes two parameters:
• The first parameter is the string name of the service being decorated. In this case, it is the $exceptionHandler service.
• The second parameter is a min-safe array containing the name of each decorator function parameter and then the decorator function itself.
• Line 16:
• The decorator function has a dependency on $delegate. So $delegate is listed in the min-safe array.
• $delegate provides the original service to the method. This allows you to call the base implementation of that service.
• Line 17:
• $delegate is passed as a parameter to the decorator function.
• Line 18:
• This method returns a decorated $exceptionHandler service object.
• The returned function has two parameters: the exception and the cause.
• Line 19+20:
• In this example, the code in the returned function replaces the exception message with a custom message.
• Line 21:
• Then it uses $delegate to call the base implementation of the service.
• The base implementation simply logs the error to the console.
• Line 22
• Lastly, this code adds an alert to notify the user of the issue.

Now, any time that an unhandled exception occurs, the message is logged to the console (the default behavior) *and* the user is notified with an alert.

You can add anything you need to this function. For example, you may want to add more extensive logging or a more detailed message.

Enjoy!