Comments

Angular 4 Tutorial: Angular 4 in 20 minutes

So, do you want to learn the fundamentals of Angular 4 in a quick and easy way? You have come to the right place! You don’t need familiarity with any previous versions of Angular. In this tutorial, I’m going to take you from the ground up and show you Angular 4 in action. You only need a basic familiarity with HTML, CSS, and JavaScript.

If you learn better by videos, you can also watch this tutorial on YouTube; otherwise, continue reading.

Beginner’s questions

Let’s start with a few beginner’s questions. If you’ve used any previous versions of Angular, feel free to skip this section and jump to “Getting the tools”.

What is Angular?

Angular is a framework for building client applications in HTML, CSS, and either JavaScript or a language like TypeScript that can be compiled (more accurately, transpiled) to JavaScript. If you have never worked with TypeScript before, don’t worry. I will give you the basics in order to complete this tutorial.

What is TypeScript?

TypeScript is a superset of JavaScript. That means any valid JavaScript code is valid TypeScript code. But many prefer TypeScript because it has additional features that we don’t have in the current version of JavaScript that most browsers understand. So, when building Angular applications, we need to have our TypeScript code converted into JavaScript code that browsers can understand. This process is called transpilation which is the combination of translate and compile. And that’s the job of  the TypeScript compiler.

Why do I need a framework like Angular?

A common question a lot of beginners ask me is: “Why do we need Angular in the first place? What’s wrong with the plain old vanilla JavaScript and jQuery?”.

There is nothing inherently wrong with using vanilla JavaScript/jQuery. In fact, a lot of web applications out there are built this way. But as your application grows, structuring your code in a clean and maintainable and more importantly, testable way, becomes harder and harder. I’m not saying this is impossible. But using a framework like Angular, makes your life far easier. Sure, there is a learning curve involved, but once you master Angular, you’ll be able to build client applications faster and easier.

Is Angular better than React/Vue.js?

These days there is a lot of debate between Angular vs React vs Vue.js. Whether Angular is better than React or Vue.js depends on how you define “better”. Each of these frameworks have strengths and weaknesses and there is no one shiny framework that makes every developer in the world happy. My suggestion to you is to learn the fundamentals of each of these frameworks and choose the one that works best for each project depending on its requirements.

Getting the tools

Now, let’s get dive into some code and get our hands dirty! The first thing you need to install is the latest version of Node. So, if you haven’t installed Node, head over to nodejs.org, and install the latest stable version.

Node comes with a tool called Node Package Manager or NPM, which is used for installing third-party libraries. In this tutorial, we’re going to use NPM to install Angular CLI. That is a command-line tool we use to create a new Angular project. It is also used for generating some boilerplate code during development (such as components, services, etc) as well as building an application for deployment. We do all this in the terminal.

So, once again in the Terminal, run the following command to install Angular CLI:

npm install -g @angular/cli

The -g flag stands for global. If you don’t put -g here, Angular CLI will be installed only in the current folder, and it’s not going to be accessible anywhere else.

If you’re on Mac, you need to put sudo at the beginning of this command to execute it as an administrator; otherwise, you’ll get permission errors.

Your First Angular App

So with Angular CLI in place, now we can create a new Angular project using the following command:

ng new hello-world

As you can see, we can access Angular CLI using ng. We provide a command (in this case new) to instruct Angular CLI on what we want it to do for us. Here, we are telling Angular CLI to generate a new project called “hello-world” and store it in a folder with the same name. We’ll be looking at these generated files shortly. For now, let’s finish the first step and see our new Angular app in the browser.

So, run the following commands in the terminal:

cd hello-world
npm install 
ng serve

With the second command (npm install) we install all the dependencies of our application. The last command (ng serve) compiles our application and hosts it using a lightweight web server. Now, we can access our application at http://localhost:4200. 

So, open up your browser and navigate to this address. You should see the following page:

Congratulations! You generated and served your first Angular 4 application. Now, let’s have a quick look at the files and folders in our new Angular project.

Structure of Angular Projects

Inside the generated folder, you’ll find the following top-level folders:

  • e2e: includes end-to-end tests.
  • node_modules: all the third-party libraries that our project is dependent upon.
  • src: the actual source code of our Angular application.

99.9% of the time you’ll be working with the files inside the src folder. But let’s quickly overview the other files we have in this project:

angular-cli.json: a configuration file for Angular CLI. We use this file to import third-party stylesheets or define additional environments (eg testing environment) for our application.

package.json: a standard file for Node-based projects. It contains metadata about our project, such as its name, version as well as the list of its dependencies.

protractor.conf.js: Protractor is a tool for running end-to-end tests for Angular projects. We hardly need to modify this file.

karma.conf.js: Karma is a test runner for JavaScript applications. This file contains some configuration for Karma. We rarely need to modify this file.

tsconfig.json: includes setting for the TypeScript compiler. Again, we hardly, if ever, need to modify this file.

tslint.json: includes the settings for TSLint which is a popular tool for linting TypeScript code. That means it checks the quality of our TypeScript code based on a few configurable parameters. This is especially important in a team environment to ensure that everyone follows the same conventions and produces code of the same quality. We can run linting on our code using Angular CLI in the terminal or we can add it to our editor as a plug-in.

So, as you see, all these files are configuration files that work smoothly out of the box. Unless you want to customize them for your specific environment, you don’t ever have to modify them.

Architecture of Angular Apps

Ok, so you’ve learned how to generate and serve a new Angular project. You’ve also learned about various files and folders in a new Angular project. Now, let’s look at the architecture of Angular applications.

The most fundamental building block in an Angular application is a component. You can think of a component as a view component. It represents a view or part of a view (what the user sees). A component consists of three pieces:

  • HTML markup: to render that view
  • State: the data to display on the view
  • Behavior: the logic behind that view. For example, what should happen when the user clicks a button.

 

A component can contain other components. For example, let’s imagine you’re going to build a web app like Twitter using Angular. In your implementation, you may have a tree of component likes this:

  • App
    • NavBar
    • SideBar
    • ContentArea
      • Tweets
        • Tweet
          • Like

 

Now, at the root of the application, we have a component called AppComponent. This is the root of every Angular application. Our AppComponent contains 3 child components: NavBar, SideBar, and ContentArea.

The reason for such separation is because the navigation bar is logically a separate part of the view. It has its own markup, state, and behavior.  We can encapsulate all that using a component called NavBarComponent. This way, when modifying or extending the navigation bar of our application, we can focus on a small component with a lightweight template.

Benefits of Component-based Architecture

As you can see, this component-based architecture makes our applications more organized and maintainable. Plus, we can potentially reuse these components in various parts of an application or in an entirely different application. For example, tomorrow, we can grab this NavBarComponent and put it in an entirely different project. We just need to modify the links. But all the HTML markup will remain the same.

Back to our tree of components, you can see that inside the content area, we have a tree of components like this:

  • Tweets
    • Tweet
      • Like

Again, this is one way to model this. We don’t necessarily have to have a separate component for the list of tweets and each tweet. We could combine TweetsComponent and TweetComponent into one component. But, I’d like to separate the LikeComponent because we could potentially reuse this like button somewhere else in this application or in another application. Even if we don’t reuse it, separating the markup, state and behavior of this like button into a separate component, makes our application more maintainable and testable.

An Angular Component in Action

Now, let’s inspect a real component in action.

Back to our project, open up the src/app folder. Inside this folder, you should see the following files:

  • app.component.css
  • app.component.html
  • app.component.spec.ts
  • app.component.ts
  • app.module.ts

 

These files represent AppComponent, which is the root component for our application. In this particular case, all these files are inside the app folder. But when we generate a new component using Angular CLI, all the files that make up a component will be grouped by a folder.

So, in terms of the implementation, each component in an Angular project is physically implemented using four files:

  • A CSS file: where we define all the styles for that component. These styles will only be scoped to this component and will not leak to the outside. This is what Shadow DOM does. But not all browsers today support Shadow DOM. So, Angular uses a technique to emulate the Shadow DOM.
  • An HTML file: contains the markup to render in the DOM.
  • A spec file: includes the unit tests.
  • A TypeScript file: where we define the state (the data to display) and behavior (logic) of our component.

You will also see an app.module.ts file.  This file defines the root module of our application and tells angular how to assemble the app.

 

Creating a Component

Now that you know what a component is, let’s use Angular CLI and add a new component to this application.

Imagine we want to build an e-commerce application. On the home page, we’re going to display the list of products and below each product, we want to have a button for adding that product to the shopping cart.

So, for this exercise, we want to create a super simple component to represent each product on the home page. This component will include the HTML markup to display that product, and it’ll respond to the click event of a button to add that product to the shopping cart.

When we click this button, it also shows the number of products of this type in the shopping cart. Initially, the number should be 0. Every time we click the Add to Shopping Cart button, the number is increased. Of course, in a real-world application, there’s far more complexity involved. For example, we may want to call some back-end services to store this item in a database. But for now, let’s just focus on the fundamentals. If you understand the fundamentals well, you can always add these other details later. So, for now, forget about the server-side, databases and other complexities.

Ok, we’re ready to create a component. We can manually create all those four files by hand, but there is a faster way. We can use Angular CLI!

Generating a Component Using Angular CLI

Run the following command in the terminal, inside the project folder:

ng g c product

Here, g is short for generate, c is short for component and product is the name of our component. Now, if you look at the project folder, inside the src/app folder, you should see a new folder called product. Expand this folder. You should see the following files:

  • product.component.css
  • product.component.html
  • product.component.spec.ts
  • product.component.ts

Open product.component.ts. This is what you should see:


import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-product',
  templateUrl: './product.component.html',
  styleUrls: ['./product.component.css']
})
export class ProductComponent implements OnInit {
  constructor() { }

  ngOnInit() { 
  }

If this code looks complex to you, don’t worry! I’m going to make it super simple. It’s actually far easier than you may think!

For now, I want you to note the value of the selector property. It’s app-product. This is a CSS selector. So app-product represents an element by this name. With this, we can extend the HTML vocabulary. Anywhere we add this app-product element, Angular will render the HTML markup of ProductComponent inside that element. So, let’s add this element to the template for our AppComponent.

Using a Component

Open up src/app/app.component.html. Replace all the markup with the following:

<app-product></app-product>

Now, our application includes a tree of components:

  • App
    • Product

At the root of this tree, we have our AppComponent. This component includes a child component: ProductComponent. 

Save the changes. Back to the browser, now, you should see this:

Our ProductComponent has a simple template that includes “product works!”. We can modify product.component.html and add some complex markup here. For example, we can use Bootstrap 4 cards to render the product inside a card.

But for now, we don’t want to waste our time and make our application pretty. Our focus is on understanding Angular. We can always come back to the template for ProductComponent and improve it.

Examining an Angular Component

You successfully generated and used a component. Now, let’s examine this component in detail. So, open up product.component.ts. Here is the code for reference:

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-product',
  templateUrl: './product.component.html',
  styleUrls: ['./product.component.css']
})
export class ProductComponent implements OnInit {
  constructor() { }

  ngOnInit() { 
  }

Inside of this file, we have a TypeScript class called ProductComponent.

What is a Class?

A class is a fundamental building block of many object-oriented programming languages. It’s a container for a bunch of related functions and variables.

So, unlike vanilla JavaScript where all our functions and variables are hanging from the global namespace, we put them in containers called classes. With these classes, we don’t pollute the global namespace and as a result, we won’t have one function overwriting another function with the same name. Because these functions are now in separate containers (classes). Also, because each class includes a bunch of highly related functions and variables, our code is more organized and maintainable.

In object-oriented programming terms, we call these functions and variables that reside in a class, methods and fields/properties respectively. Fields and properties are technically different but they are often used interchangeably. A field is like a variable where we store some data. A property looks like a field from the outside, but internally, it is a function around a field that gives us read or write access to that field. If this sounds confusing, don’t worry about it now. I’m planning to publish a separate post about TypeScript. For now, you can assume fields and properties are the same, even though they are not!

Example of a Class

So, in product.component.ts, we have a class called ProductComponent. This class has 2 functions (methods): constructor and ngOnInit.

export class ProductComponent implements OnInit {
  constructor() { }

  ngOnInit() { 
  }

Constructor is a reserved keyword in TypeScript. A method by that name is a special method in a class. This method is called automatically when we create an instance of that class.

ngOnInit is a special method in Angular. Angular calls this method when it creates an instance of this component and displays it to the user in the browser.

For this exercise, we don’t have to worry about either of these methods. So, delete both of them. You should also delete implements OnInit in front of the class name. For now, don’t worry about it, but basically, it tells Angular that this class has some initialization code that should be executed before this component is displayed to the user.

So, your code should look like this:

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-product',
  templateUrl: './product.component.html',
  styleUrls: ['./product.component.css']
})
export class ProductComponent {
}

Component Metadata

So, you’ve seen that we implement a component using a TypeScript class. But a class on its own is just a class. It only includes some data and logic for a view. It doesn’t include any HTML markup or CSS styles. In order to attach these to this class, we need to promote this class to a component. We can do this by using the @Component() decorator function on top of this class (lines 3-7):

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-product',
  templateUrl: './product.component.html',
  styleUrls: ['./product.component.css']
})
export class ProductComponent {
}

With this, we can attach metadata to this class that Angular understands. This @Component() decorator function is defined in Angular and you can see we’re importing it on line 1. It takes an object with the following properties:

  • selector
  • templateUrl
  • styleUrls

You’ve seen the selector in action. It associates a new HTML element to this component. With this, we can extend the standard HTML vocabulary. So, now we have a new custom element (app-product) that we can use anywhere in our application. When Angular sees that element, it’ll place the HTML markup of our ProductComponent inside that element.

The other 2 properties (templateUrl and styleUrls)  are self-explanatory. They specify the path to the HTML template and CSS file(s) for this component.

Property Binding

In Angular, unlike vanilla JavaScript or jQuery, we don’t work directly with the DOM. So, we don’t write code like this:

$("#myElement").text("something")

Instead, we use property binding. Let me show you how that works.

In our ProductComponent, let’s add a new field:

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-product',
  templateUrl: './product.component.html',
  styleUrls: ['./product.component.css']
})
export class ProductComponent {
   title = 'USB Stick 8GB';
}

This title field contains the title for our product. In a real-world scenario, we get this title from a database somewhere on the server. So we don’t hardcode it here. But for now, let’s not worry about this and see property binding in action.

Now, open up product.component.html. Replace all the markup there with:

<p>{{ title }}</p>

This special double curly brace syntax you see here is what we call interpolation in Angular. Fancy name again, right? This basically tells Angular to replace what we have between curly braces with the value of the title field in our component.

This syntax is a shorthand for the actual property binding syntax we have in Angular. The code you wrote above is equivalent to the following code:

<p [innerHtml]="title"></p>

What is this? Very simple! In vanilla JavaScript, we can simply get a reference to an element in the DOM and set its innerHTML property like this:

var el = document.getElementById("myElement");
el.innerHTML = "USB Stick 8GB";

So, every DOM element has a property called innerHTML. In our Angular application, we’re using the square bracket syntax to bind a property of a DOM element to a field/property in our component:

<p [innerHtml]="title"></p>

So, at run-time, Angular will set the innerHtml property of this paragraph to the title field we defined in our component. And more importantly, if the value of our title field changes in the future, Angular will automatically update the view (DOM) for us! This is property binding in action. We have bound the innerHTML property of this element to the title field of our ProductComponent.

A Simple Exercise

Now, here is a simple exercise for you. I want you to extend our product component and display the number of USB sticks in the shopping cart below the name of this product. So, stop reading and make any necessary changes in the code. Then, come back here and see my solution.

Ok, so you should have added a new field in ProductComponent:

export class ProductComponent {
   title = "USB Stick 8GB";
   itemCount = 0; 
}

And used interpolation or property binding syntax to render it in the template:

<p>{{ title }}</p>
<p>{{ itemCount }}</p>

Event Binding

Similar to property binding, we have another concept in Angular called event binding. With property binding, we bind properties of DOM elements to fields/properties in our component. With event binding, we bind events of DOM elements (such as clicks) to methods in our component. So, for example, when the user clicks on a button, a method in our component will be called.

We’re going to extend our product component and add a button to increase the number of USB sticks in the shopping cart. So, modify product.component.html as follows:


<p>{{ title }}</p>
<p>{{ itemCount }}</p>
<button (click)="addItem()">Add</button>

Note the difference between property and event binding syntax. We use square brackets for property bindings and parenthesis for event binding. With this code, whenever our button is clicked, Angular calls the addItem() method in our component.

So, let’s implement this method in our component. Open up product.component.ts:

export class ProductComponent {
   title = "USB Stick 8GB";
   itemCount = 0; 

   addItem() { 
      this.itemCount++;
   } 
}

Here, we’re simply incrementing the itemCount field. Now, save the changes and go back to the browser. Test this application by clicking the Add button. You can see the count gets updated immediately. This is the beauty of property and event binding in action!

As I explained, Angular watches our itemCount field. When its value gets changed, Angular updates the DOM immediately.

What you’ve seen far is just the tip of the iceberg. There is far more to property and event binding and Angular in general. It’s impossible to cover it all in one blog post. If you’re serious about learning Angular, I have a complete course with 30 hours of high-quality videos. This is equivalent to a book with more than a thousand pages!

Recap

Let’s quickly recap what you’ve learned in this post:

  • Angular is a framework for building client apps with HTML, CSS and TypeScript.
  • It gives our applications a proper, maintainable and testable structure.
  • At the core of every Angular application, we have a tree of components.
  • Each component encapsulates the state (data), the HTML markup and the behavior for a view.
  • At a minimum, a component is implemented using a class. This class may include a bunch of fields for displaying data and methods, which will be called in response to events raised from the DOM events.
  • A component may have an external template stored in a separate HTML file.
  • It may also include one or more external stylesheets.
  • A component also has a selector. That tells Angular where in the DOM to place this component.
  • We use the property binding syntax (square brackets) to bind properties of DOM elements to fields/properties in our components.
  • When the value of these fields/properties change, Angular automatically updates the DOM (view).
  • We use the event binding syntax (parenthesis) to bind events of DOM elements to methods in our component.
  • Angular automatically calls these methods to handle events raised from the DOM elements.

 

Once again, if you want to learn everything about Angular from the basic to the advanced topics, I encourage you to enroll in my complete Angular course. This is far easier and faster than jumping from one tutorial to another. With this course, you can learn all these concepts in one place, step-by-step and you’ll build and deploy real e-commerce app with Angular and Firebase at the end of the course.

 

If you’ve enjoyed this tutorial, please show the love by sharing it with others. Thank you!

 

Tags:
Comments

What is Unit Testing and Why You Need to Learn It

In this post, I’m going to give you a brief introduction to unit testing and its benefits. So, let’s get started!

What is unit testing?

Unit testing is the practice of writing code to test your code and then run those tests in an automated fashion.

Here is an example. Imagine you have this function somewhere in your code. It’s a basic calculate function that takes an input and depending on some conditions, it returns different values.

public float CalculateTax(int input) 
{
    if (x) return ...;
    if (y) return ...;
    return ...;
}

If you want to test this function manually, you have to run your application, perhaps you have to login, or maybe do a few clicks here and there to get to a page where this function is used. Then, you have to fill out a form, submit it and verify if this function returned the right result. And then you have to repeat all these steps, each time using different values in your form.

Manual testing is expensive!

As you can see, this is very time-consuming.  This workflow to test this function may take several minutes every time! Now to make matters worse,  this is not the only function in your application. In a real application, you have tens or hundreds of functions like this! As your application grows in size and complexity, the time required to manually test all the different bits and pieces increases exponentially. So, that’s why we use automated testing.

Unit testing

With automated testing, you create a separate project for writing tests. In that project you’ll write code and directly call this function with different inputs and verify that this function returns the right output.

var result = CalculateTax(1);
Verify(result == 1.5f);

We refer to these types of tests as unit tests. With unit tests, we test a unit of the application in isolation without its external dependencies such as files, databases, web services, etc.  Tests that include these external dependencies are called integration tests, and that’s the topic for another post.

Unit tests are repeatable!

The good thing about unit tests is that they are repeatable. You write them once and run them a million times! So, every time you change your code, every time you commit your code to a repository, and before deploying your application. With this approach, you can test all the execution paths in this function in a fraction of a second! You can write several hundreds or thousands of unit tests for various parts of your application, and run them all in just a few seconds.

Unit tests help you deploy with confidence!

If you properly cover your code with a comprehensive suite of tests, you can run these tests before deploying your application to the production. If you’ve broken something that used to previously work, you’ll know straight away. With unit tests you can catch more bugs before deploying our application and this means you can deploy with confidence.

Have you ever been in a situation where you deployed your application, left the office thinking everything is working, and then got a call from your boss or an end-user, telling you that one of the major functions of the application is not working? Then you had to go back to the office and you thought that was a quick fix, but you ended up staying there till midnight!

That’s why you should write tests: to reduce the number of defects or bugs that will go in the production. Note that I’m not saying that with unit tests you’re gonna release bug free software. That’s not true! But you can certainly reduce the number of bugs and improve the quality of your software.

Unit tests help you refactor with confidence!

Refactoring means changing the structure of your code without changing its behaviour. If you extract a few lines of a method into a separate private method, that’s refactoring. If you rename a method, that’s refactoring too. You’re changing the structure of your code to make it cleaner and more maintainable, but you’re not changing the functionality.

When you don’t have unit tests, every time you refactor your code, you have to manually test every part of the application that could be affected by your refactoring. And this is very painful because first of all, it’s time consuming, and second, as your application grows, you may forget about the parts that need to be tested! With unit tests, every time you refactor your code, you run your tests and make sure you didn’t accidentally break anything that used to previously work.

Unit tests help you write better code!

When writing tests, you’re forced to think about the edge cases of every function in your application. You write tests for these functions, giving them various inputs and make sure they behave as you expect. This will help you produce better quality software with less defects. A lot of bugs in our applications are the result of unforeseen edge cases. One of your functions receives an input that you forgot to predict and boom! It blows up!  With unit tests, you make sure that every function works with different inputs under varying circumstances.

Also, applications written with unit testing in mind often have cleaner and more maintainable source code. That means smaller functions with a clear responsibility and few parameters.

Benefits of unit testing

So, to recap, unit tests help you:

  • Test your code frequently and in less time
  • Catch more bugs before deploying
  • Deploy your application with confidence
  • Refactor your code with confidence
  • Write cleaner and maintainable code

You need to have unit testing on your resume!

If you’re a senior developer, you must know how to write unit tests! If you don’t know, you’re probably more of an intermediate-level developer even if you have a senior position at your company.

If you’re a junior/intermediate-level developer and want to become a senior developer, you must have unit testing on your resume to get a better job. Most good companies with good programmers practice unit testing these days.

Unit testing C# code

I’m currently working on a comprehensive course on unit testing for C# developers. In this course, I’ll take you from the ground and teach you how to write unit tests for your C# code. I’m planning to release this course by the end of October. If you’re interested to get this course with an early-bird discount, drop your email and join my mailing list. I won’t spam you, and you can unsubscribe at anytime.

 

What is your story with unit testing? Drop in the comments below and let us know! 

 

If you enjoyed this post, please share it with others!

Tags:
Comments

The art of asking “coding” questions

One question (or more accurately, comment) that I frequently get on my YouTube videos is:

… is not working!

Examples: “npm install is not working”, “interpolation is not working”, etc.

“It’s not working” is not helpful! It doesn’t tell me or others about the problem you’re facing.

What error do you get? Have you tried to Google the exact same error message? If not, did you know that if you do that, 90% of the time, you can find the answer to your question within minutes? In fact, 90% of the time, the first link on Google search result is a link to a page on StackOverflow, where someone else faced the exact same problem!

3 tips that make you a better developer

Tip 1: Learn the art of asking ‘programming’ questions. Be specific about why “it’s not working”!

Tip 2: Learn to find the answer to your question yourself. You cannot always reach out for help every time “it’s not working”. Successful programmers are independent. Linus Torvalds, the creator of Linux, even wrote his own editor and assembler! Now, you don’t need to do this to be independent, but a Google search takes only a few seconds and helps you become less dependent on other developers in your team.

Tip 3: Read about rubber duck debugging. It works!

If you enjoyed this article, please share it with others.

Comments

6 Essential VSCode Extensions for Angular Developers

In this post, I’m going to list my top favorite Visual Studio Code (VSCode) extensions for building Angular applications. If you know a great extension that is missing here, please let us know using the comment box below the post.

Installing an Extension

If you know how to install an extension in VSCode, feel free to skip this section. Otherwise, launch VSCode, and open the Extensions tab from the left side bar. Here, you can see the list of installed extensions. You can also search for other extensions. Once you find an extension, simply click the Install button. Then, reload VSCode and you’re good to go.

TypeScript Hero

This is by far my absolute favorite extension! You no longer have to manually import types in TypeScript. TypeScript Hero automatically imports the types for you as you write code. When pasting some code from somewhere else, you can also add all the missing import statements in one go!

Another useful feature of this extension is that it allows you to sort and remove the unused import statements. You also get code completion and several other useful features. Highly recommended!

Angular Language Service

This extension provides a rich editing experience for Angular templates. Imagine you have a field in your component as follows:

course = { 
   title: 'The Complete Angular Course', 
   author: { 
      name: 'Mosh Hamedani'
   }
} 

With this extension, you’ll get auto-completion in your HTML templates:

Autocompletion

Bracket Pair Colorizer

This extension allows matching brackets to be identified with colors.

Bracket

Move TS

As your application grows, you may want to break it down into smaller and more maintainable modules. You’ll have to move files and folders around. But what happens to all your import statements? They break! So, that’s what this extension is for. With Move TS extension, you can simply move files/folders around and this extension will automatically update your import statements.

Material Icon Theme

Do you like to have pretty icons in the project explorer? Install this extension!

Angular TypeScript Snippets

Another useful extension developed by John Papa that boosts your productivity when building Angular applications. It gives you a bunch of code snippets that allow you to quickly generate code. There are snippets for creating a component, service, directive, etc. You may argue that now we can easily create these artifacts using Angular CLI and that is absolutely right. However, this extension gives you some useful HTML snippets as well:

Angular TypeScript Snippets

You can find the complete list of snippets provided by this extension here.

What is your favorite extension that you frequently use? Use the comment box below and let us know.

If you enjoyed this article, please share it with others.

Tags: ,
Comments

Get paid to work with Me!

I constantly get requests about creating new courses and with 24-hour days I’m constantly behind my schedule. There are courses that many of you have been awaiting for a long time!

So, to speed things up, I’m looking for a passionate teaching assistant who can help me produce new courses faster and support my existing students. This will be a part-time job with the potential to go full-time.

 

Requirements

In order to be considered for this position:

  • You should be a US citizen
  • You should be fluent in English and have excellent writing skills
  • You should be a great communicator
  • You should have a passion for learning and teaching new things

 

Responsibilities

As a teaching assistant, you’ll help me with one or more of the following tasks. This depends on your capabilities and interests.

Creating materials for my future courses
I’ll give you some direction about a course topic and your job will be to come up with the structure for a course as well as the detailed materials for each lecture. This includes the script, slides, examples, and exercises. I’ll use these materials to create new videos.

In order to be considered for this, you should have a fair amount of understanding of the given topic and have excellent writing skills (for writing the script).

Writing blog posts
This involves writing a clean, professional and properly formatted post on a given topic. You should have excellent writing skills and pay great attention to the readability and formatting of these posts.

Answering the questions on the discussion boards
You should have a fair amount of experience on a given topic (e.g. C#, Angular, etc) and be able to answer students’ questions. You don’t have to be an expert in the given topic but willing to research and guide students in the right direction.

Reviewing the upcoming courses
Once I record and edit my videos, you’ll have to watch each lecture and make sure all the videos are edited properly, all the supplementary materials are there and the course is ready to go live.

 

Apply

To apply, fill out the following this Google Form. Since I may be receiving a large number of applicants, I won’t be able to respond to each of you individually. So, I’ll reach out only to eligible applicants.

Comments

Common Angular Errors

In this post, I’m going to list the most common errors you may encounter while getting started with Angular. For each error, I’m going to explain what it means and how to solve it.

This post is a work in progress and I’m planning to add more errors. If there is an error you encounter often, please let us know by dropping a comment.

Error 1: ‘ng’ is not recognized

When creating a new project with Angular CLI, you may receive the following error:

'ng' is not recognized as an internal or external command.

This error is simply telling you that Angular CLI is either not installed or not added to the PATH. To solve this error, first, make sure you’re running Node 6.9 or higher. A lot of errors can be resolved by simply upgrading your Node to the latest stable version.

Open up the Terminal on macOS/Linux or Command Prompt on Windows and run the following command to find out the version of Node you are running:

node --version

If you’re running an earlier version of Node, head over to nodejs.org and download the installer for the latest stable version.

Once you have installed Node 6.9+, you need to install Angular CLI globally:

npm install -g @angular/cli

Note the -g flag here. This tells NPM that you want to install this package globally so you can run it from any folders on your machine.

Error 2: node_modules appears empty

When you run ng serve, you may receive the following error:

node_modules appears empty, you may need to run `npm install`.

Our Angular applications use a bunch of 3rd-party libraries. These libraries are stored in the node_modules folder inside your project folder. When you create a new project using Angular CLI, these third-party libraries should be installed automatically. However, if you’re using a corrupted or a buggy version of Angular CLI, these libraries are not installed. So, you need to manually install them.

To solve this error, run npm install from the project folder. This command will look at package.json in your project folder. This file includes the list of dependencies of your project. NPM will download and store these dependencies in the node_modules folder.

 

If you found this post helpful, please share it with others.

If there is an error you’d like me to add to this post, please let me know using the comment box below.

Tags:
Comments

Layered Architecture in ASP.NET Core Applications

One of the viewers of my YouTube channel asked me an interesting question. He mentioned in a typical layered architecture, he sees ASP.NET MVC building blocks (Controller, View, and Model) as part of the presentation layer. These days, however, a lot of modern applications are built with Angular/React on the client and ASP.NET Core (Web API) on the server. So, what is the presentation layer in this kind of architecture? Let’s see!

With this stack, we have the following layers:

  • Presentation
  • Service
  • Business Logic/Application Core
  • Data Access/Persistence

Presentation Layer

Your Angular components, their templates, and the models you define in your Angular app are all presentation layer artifacts.

Service Layer

The confusing thing about this layer is that the term “service” is overloaded and it means different things to different people. In the context of a layered architecture, it wraps an application and exposes the application functionality in terms of a simple API that the user interface can talk to. This is the classic definition. Think of it as the glue between the presentation and business logic layers.

Now, in our modern stack, our logical service layer is physically composed of two parts: one part is on the client (Angular HTTP services) and the other part is on the server (ASP.NET Core controllers). These Angular services and ASP.NET Core controllers are very cohesive. The methods on these services (eg CourseService.getCourses()) talk directly to the endpoints exposed by your ASP.NET Core controllers.

Business Logic Layer

In your ASP.NET Core controllers, you often use repository interfaces (ICourseRepository), domain classes (Course) and services (PhotoService). All these are part of the business logic layer. They represent the core of an application irrespective of any presentation or persistence frameworks.

Note that here I’m talking about repository interfaces and not their implementations. These implementations are part of the data access/persistence layer.

Also, note that the services we have here are responsible for orchestration. For example, when adding a photo to a course, first, you need to store that photo in the file system (or some other kind of storage), and then you need to add it to the database (using a repository interface). Here is an example:

// Store the file first 
var uploadsPath = Path.Combine(host.WebRoot, "uploads");
if (!Directory.Exists(uploadsPath))
    Directory.CreateDirectory(uploadsPath);

var fileName = Guid.NewGuid().ToString() + Path.GetExtension(file.FileName);
var filePath = Path.Combine(uploadsPath, fileName);

using (var stream = new FileStream(filePath, FileMode.Create))
{  
    file.Copyto(stream);
}

// Add a record to the database
var photo = new Photo { FileName = fileName };
repository.Add(photo);
unitOfWork.Complete(); 

You wouldn’t write all this logic inside an ASP.NET Core Controller. Imagine, tomorrow you decide to use a different framework. You want to re-use as much code as possible. By encapsulating this code in a service (PhotoService.AddPhoto()), you can switch from ASP.NET Core to a different framework with less effort.

But wait for a second…

Now, that strongly-opinionated developer comes and says: “But who does replace ASP.NET Core with something else? How often does that happen?” Let’s say never! By moving all this logic from a controller into a service, you put the responsibility where it really belongs. The result is cleaner, slimmer, easier to read and easier to test controllers.

Imagine a restaurant where the chef does it all. He’s at the door, welcoming guests, giving them a table, taking their order, then going in the kitchen, chopping the vegetables, cooking, washing the dishes, then coming out and giving the bill to the guests. Would you go to that restaurant? I hope not!

In a good and organized restaurant, there are a few people each focusing on only one job. The waiters/waitresses are purely responsible for welcoming the guests and giving them the bill. The chef is purely responsible for cooking. He or she doesn’t wash the dishes! By the same token, you should have classes that do only one thing and do it well. This is what we call separation of concerns. You should put the responsibility where it really belongs, even if you’re never going to change the presentation or persistence framework of your application.

So, once again, all your domain classes (Course), repository interfaces (ICourseRepository) and application services (PhotoService) are part of the business logic layer. They represent the core of your application completely decoupled from any presentation and persistence frameworks. This is what Uncle Bob defines as Clean Architecture.

Data Access Layer

This layer is all about persistence. Here we have implementations tightly coupled to Entity Framework (or other frameworks) for persisting and retrieving data. If you’re using Entity Framework, your DbContext belongs in this layer. So do UnitofWork and Repository implementations.

Splitting a Project

Now, a common (and bad) practice I’ve seen some developers do, is that they blindly split an ASP.NET project into multiple class libraries, one for each layer. And with this, they assume just because they have a class library called MyProject.BLL or MyProject.DAL, they have properly layered their application. But that’s not necessarily right.

What matters is the direction of dependency and coupling between classes, not folders or projects. You can easily organize your classes into folders and projects but these classes can be poorly coupled to each other, which results in spaghetti architecture. Read my blog post on the topic:

Should you split your ASP.NET MVC/Core projects?

 

If you learned something from this post, please share it and drop your comments/questions below.

Tags: , , , , ,
Comments

4 Common Mistakes with the Repository Pattern

As part of my new ASP.NET Core course, I’ve been encouraging my students to post their code to GitHub. While reviewing various solutions, I’ve encountered a few common mistakes in the implementation of the repository pattern.

One repository per domain

You should think of a repository as a collection of domain objects in memory. If you’re building an application called Vega, you shouldn’t have a repository like the following:

public class VegaRepository 
{
}

Instead, you should have a separate repository per domain class, like OrderRepository, ShippingRepository and ProductRepository.

Repositories that return view models/DTOs

Once again, a repository is like a collection of domain objects. So it should not return view models/DTOs or anything that is not a domain object. I’ve seen many students using AutoMapper inside their repository methods:

public IEnumerable<OrderViewModel> GetOrders() 
{
     var orders = context.Orders.ToList();

     return mapper.Map<List<Order>, List<OrderViewModel>(orders);
}

Mapping is not the responsibility of the repository. It’s the responsibility of your controllers. Your repositories should return domain objects and the client of the repository can decide if it needs to do the mapping. By mapping the domain objects to view models (or something else) inside a repository, you prevent the client of your repositories from getting access to the underlying domain object. What if you return OrderViewModel but somewhere else you need OrderDetailsViewModel or OrderSnapshotViewModel? So, the client of the repository should decide what it wants to map the Order object to.

Save/Update method in repositories

Yet another very common mistake! As I’ve explained in my YouTube video before, your repositories should not have a Save() or Update() method. I repeat: think of a repository as a collection of domain objects in memory. Do collections have a Save() or Update() method? No! Here’s an example:

var list = new List<int>();
list.Add(1);
list.Remove(1);
list.Find(1);

list.Save();    // doesn't exist!
list.Update();  // doesn't exist!

Another reason your repositories should not have a Save() method is because sometimes as part of a transaction you may work with multiple repositories. And then you want to persist the changes across multiple repositories in one transaction. Here’s an example:

orderRepository.Add(order);
orderRepository.Save();

shippingRepository.Add(shipping);
shippingRepository.Save();

Can you see the problem in this code? For each change, we need a separate call to the Save() method on the corresponding repository. What if one of these calls to the Save() method fails? You’ll end up with a database in an inconsistent state. Yes, we can wrap that whole thing inside a transaction to make it even more ugly!

A pattern that goes hand in hand with the repository pattern is the unit of work. With the unit of work, we can re-write that ugly code like this:

orderRepository.Add(order);
shippingRepository.Add(shipping);
unitOfWork.Complete();

Now, either both objects are saved together or none are saved. The database will always be in a consistent state. No need to wrap this block inside a transaction. No need for two separate calls to the Save() method!

If you want to learn how to implement the repository and unit of work pattern together, watch my YouTube video here.

Repositories that return IQueryable

One of the reasons we use the repository pattern is to encapsulate fat queries. These queries make it hard to read, understand and test actions in ASP.NET MVC controllers. Also, as your application grows, the chances of you repeating a fat query in multiple places increases. With the repository pattern, we encapsulate these queries inside repository classes. The result is slimmer, cleaner, more maintainable and easier-to-test actions. Consider this example:

var orders = context.Orders
    .Include(o => o.Details)
        .ThenInclude(d => d.Product)
    .Where(o => o.CustomerId == 1234);

Here we are directly using a DbContext without the repository pattern. When your repository methods return IQueryable, someone else is going to get that IQueryable and compose a query on top of it. Here’s the result:

var orders = repository.GetOrders()
    .Include(o => o.Details)
        .ThenInclude(d => d.Product)
    .Where(o => o.CustomerId == 1234);

Can you see the difference between these two code snippets? The only difference is in the first line. In the first example, we use context.Orders, in the second we use repository.GetOrders(). So, what problem is this repository solving? Nothing!

Your repositories should return domain objects. So, the GetOrders() method should return an IEnumerable. With this, the second example can be re-written as:

var orders = repository.GetOrders(1234);

See the difference?

What are the other issues you’ve seen in the implementation of the repository pattern? Share your thoughts!

If you enjoyed this article, please share it.

Tags: ,
Comments

Should you split your ASP.NET MVC project into multiple projects?

“Should I split my ASP.NET MVC project into multiple projects?” That’s a question that I get a lot! Almost every week! The short answer is: NO!

I’m not entirely sure how this trend started but I’ve seen some developers split an ASP.NET MVC project into multiple projects: a web project containing the presentation logic, plus two additional class libraries, often named [MyProject].BLL and [MyProject].DLL.

Tiers?

Also, it’s often incorrectly assumed that this structure makes an application multi-tier or 3-tier. What is a multi-tier application? It’s an application whose parts are physically distributed to different computers in a network. Web applications are often inherently multi-tired. In a web application we often have the following tiers:

  1. Client/Presentation Tier: That’s the piece running inside the user’s browser.
  2. Middle/Application/Logic Tier: That’s the part built with ASP.NET MVC (or other similar server-side frameworks) running in a web server.
  3. Data Tier: That’s the database, file system or any other kind of storage.

When we’re talking about ASP.NET MVC, we’re only talking about the application or middle tier. Separating an ASP.NET MVC project into three projects does not result in addition of new tiers in your architecture. You don’t deploy the DAL class library to a different computer! Most of the time (if not always) all these 3 projects (Web, BLL and DAL) are compiled and deployed in the same process on one machine; that is your web server. So, when someone visits your web site, these three DLLs are loaded inside a process (or more accurately an AppDomain) managed by IIS.

Layers vs Tiers

Layers and tiers are used interchangeably by some but they are fundamentally different. Layers are about logical separation, tiers are about physical separation: distributing pieces of a software application to different computers.

Layer is something conceptual in a developer’s head. A class library is not a layer, neither is a folder. You can put classes in a folder or a class library that belong to different layers and be dependent upon each other. This is a sign of bad architecture and coupling. Putting these classes under a folder or a class library like BLL and DAL does not immediately result in software with clean architecture and good separation of concerns.

Despite that, my argument is that these folders (BLL and DAL) can and should reside in the main web project and moving them into a separate class library does not add any values. It doesn’t magically create layers in your applications.

There are 2 cases for splitting a project into smaller projects: reusability and independently deploying those projects.

Reusability

One reason for separating a project into multiple class libraries is re-usability. I’ve yet to see the BLL or DAL part of a web application re-used in another application. This is what text books from 90s used to tell us! But most if not all modern applications are too specific and even in the same enterprise I’ve never seen the same BLL or DAL parts re-used across multiple applications. Most of the time what you have in those class libraries is purely to serve what the user sees in that particular application, and it’s not something that can be easily re-used (if at all).

Deployability

Another reason for separating a project into multiple class libraries is about deployability. If you want to independently version and deploy these pieces, it does makes sense to go down this path. But this is often a use case for frameworks not enterprise applications. Entity Framework is a good example. It’s composed of multiple assemblies each focusing on different areas of functionality. We have one core assembly which includes the main artefacts, we have another assembly for talking to a SQL Server database, another one for SQLite and so on. With this modular architecture, we can reference and download only the parts that we need.

Imagine if Entity Framework was only one assembly! It would be one gigantic assembly with lots of code that we won’t need. Also, every time the support team added a new feature or fixed a bug, the entire monolithic assembly would have to be compiled and deployed. This would make this assembly very fragile. If we’re using Entity Framework on top of SQL Server, why should an upgrade because of a bug fix for SQLite impact our application? It shouldn’t! That’s why it’s designed in a modular way.

In most web applications out there, we version and deploy all these assemblies (Web, BLL and DAL) together. So, separating a project into 3 projects does not add any values.

Use Cases for Physical Separation

So, when do you actually need to physically separate a project into multiple projects? Here are a couple of scenarios:

1- Multiple presentation layers: Let’s say you’ve built an order processing application. This application is a desktop application used by staff at your organization. You decide to build a web interface for this application so the staff can access it remotely. You want to re-use the existing business logic and data access components. As I explained earlier, one reason for physical separation is re-usability. So, in this case, you need to physically separate this project into three projects:

  • OrderProcessing.Core (contains both the BLL and DAL)
  • OrderProcessing.Web
  • OrderProcessing.Desktop

Note that even here I don’t have two projects (BLL and DAL). I have one project, OrderProcessing.Core, that encapsulates both the business and data access logic for our order processing application.

So, why didn’t I separate this project into two separate projects (BLL and DAL)? Because the whole purpose of this DAL is to provide persistence for what we have in BLL. It’s very unlikely that it’ll be used on its own in another project.

Also, following the dependency inversion principle of object-oriented design, the dependency should be from DAL to BLL, not the other way around. So, this means, everywhere you reference the DAL assembly, you should also reference the BLL assembly. In other words, they’re highly cohesive and inseparable. When you separate things that are cohesive, you run into issues later down the track.

2- Multiple applications under a single portal: Another use case that one of the readers suggested is where you have multiple small applications that are hosted in a single portal. So, from the end user’s point of view these applications are not separate; they are all different domains of the same application. But from development point of view, each application is independent from the others. Each application can have its own persistence store; one can use Excel, another can use SQL Server, and the other can use Oracle.

In this scenario, it’s likely that these applications are developed by different developers/teams. They’re often independently developed, version and deployed, hence the second reason for physical separation.

For this scenario, we could have a solution with the following projects:

  • OrderProcessing.Core (a class library)
  • Shipping.Core
  • CustomerSupport.Core
  • MainPortal (an ASP.NET MVC project)

Once again, you don’t see the BLL/DAL separation here. Each class library (eg OrderProcessing.Core) includes both the business and data access logic for its own domain.

The Bottom Line

Here are a few things I hope you take away from this article:

  • Layers are not tiers.
  • Tiers are about physical distribution of software on different computers.
  • Layers are conceptual. They don’t have a physical representation in code. Having a folder or an assembly called BLL or DAL doesn’t mean you have properly layered your application, neither does it mean you have improved maintainability.
  • Maintainability is about clean code, small methods, small classes each having a single responsibility and limited coupling between these classes. Splitting a project with with fat classes and fat methods into BLL/DAL projects doesn’t improve the maintainability of your software.
  • Assemblies are units of versioning and deployment.
  • Split a project into multiple projects if you want to re-use certain parts of that in other projects, or if you want to independently version and deploy each project.

 

As always, keep it simple!

If you enjoyed this post, please share it with your friends.

Tags: , , ,
Comments

Announcing my upcoming Xamarin Forms course

I’m excited to let you know that I’ve recorded and edited 7.5 hours of high quality content for my upcoming Xamarin Forms course.

Xamarin logo

In this course, I’ll take you on a pragmatic and step-by-step journey and teach you how to build native mobile apps for Android, iOS and Windows using Xamarin Forms and C#.

In particular, you’ll

  • Learn and understand the fundamentals of Xamarin Forms and its architecture
  • Build user-interfaces with XAML and code
  • Work with images
  • Present data in beautiful, interactive lists
  • Implement multi-page apps with navigation, tabs, master/detail pages
  • Build form and setting pages
  • Store and retrieve data from a variety of sources (file system, SQLite database and RESTful services)
  • Implement Model-View-ViewModel (MVVM) architectural pattern

This course, just like my other courses is packed with real-world examples, exercises and best practices. Not only will you learn how to use Xamarin Forms, you’ll also learn first-class tips to make your code cleaner and more maintainable.

Lectures also have downloadable source code so you can code-along with me while watching the videos.

 

Prerequisites

All you need to know in order to take this course is C#. At a minimum, you should be comfortable with classes, interfaces, events, delegates, lambda expressions and a bit of LINQ. If you struggle with any of these features, I highly recommend you to take my following C# courses to strengthen the fundamentals:

C# Classes, Interfaces and Object-oriented Programming

C# Advanced Topics

If you have any familiarity with XAML-based frameworks (such as WPF or Silverlight) it’s a bonus but not a requirement.

 

Get the course with a huge discount

The price for this going to be $150 but my subscribers can get it for only $20. If you’ve received this post in your mailbox, that means you are a subscriber. So you don’t have to do anything further. Otherwise, simply join my mailing list to get my upcoming Xamarin Forms and any of my other courses with big discounts.

 

Frequently Asked Questions

Do I need a Mac to take the course?

Not at all! You can use use Visual Studio on Windows to build and deploy apps to Windows and Android. You need a Mac only to build your app for iOS. And this involves simply adding a new project to your Visual Studio solution, setting it as the start up project and building it. That’s it! You don’t need to write any extra code.

So, no, you don’t need a Mac to take this course or learn Xamarin Forms in general.

 

Do I need to know about Xamarin.Android and Xamarin.iOS libraries?

Again, no! Xamarin Forms provides a simple, unified API for you to build cross-platform mobile apps. When you build your app for Android or iOS, it will internally use Xamarin.Android or Xamarin.iOS to map the common user interface elements to their corresponding native equivalent.

You need to know about Xamarin.Android or Xamarin.iOS only if you want to build custom user-interface elements.

 

When this course is coming out? I’m impatient and can’t wait! 

It’ll be live in mid September or a bit earlier.

 

So, if you want to get the course for only $20, join my mailing list now. Once the course goes live, I’ll send you an email with a coupon.

 

Preview

Tags: ,
%d bloggers like this: