Refactoring to Angular Pipes

Refactoring to Angular Pipes

Derived from photo by Bodey Marcoccia / flickr.com, CC BY-SA

Angular pipes are often overlooked in their simplicity. If you are familiar with filters in Angular 1.x, they are conceptually similar. At their core, they convert a set of inputs to display text in the UI. And while there are other ways to accomplish this, you may find that by using pipes you can reduce the amount of code in your components.

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

The prior post demonstrates how to create a component using Angular Material. The component class contains a TODO comment to convert mapping logic into a pipe. This post shows how to create the pipe:

// TODO: move to own pipe or directive
private mapToDisplayDateText(date: Date): string {
    // TODO: Make today's date mockable, convert to UTC
    const todaysDate = new Date();
    const isToday = areSameDate(todaysDate, date);
    const yesterdaysDate = addDays(new Date(), -1);
    const isYesterday = areSameDate(yesterdaysDate, date);

    const dayText = isToday ? 'Today' : isYesterday ? 'Yesterday' : formatDate(date, 'dddd, MMMM, D, YYYY');
    const lastCompletedDate = `${dayText}, ${formatDate(date, 'h:mm A')}`;

    return lastCompletedDate;
}

Why Use Pipes

Admittedly, I'm a little torn on using pipes. In their pure form, the concept is straightforward: take a set of inputs and return the display output as a string. A pure JavaScript function can also accomplish the same result in a component. I sometimes view pipes as conceptual overhead that you don't necessarily need to learn when starting with Angular. The concept count is already so high for many developers. Why add pipes to the mix?

This post explores how encapsulating this mapping logic in its own UI-based wrapper, a pipe, reduces component complexity in two ways. First when mapping in the component, you are responsible for determining if a value has changed or not before mapping (or you decide not to check this at all). When using a pipe, Angular's change detection evaluates the value to determine if mapping is required.

Second, using a pipe can reduce model complexity. For instance, this example formats a date in a custom way. This date may be rendered in different ways depending on where it is shown. When mapping in the component, each component is responsible for mapping this date into the correct string format and the component is responsible for two pieces of state, the original value and the display value (or multiple display values). When this logic is encapsulated in a pipe, the view declaratively defines how the data should display and the component is only responsible for one piece of state, the date object.

Initially, I recommend sticking with pure pipes. They are more performant out of the box because they adhere to the default (and fast) Angular change detection behavior where only values and object references are compared. If you find the need to detect changes at a deeper level of an object, there are probably better ways to handle this outside the scope of a pipe – and this article.

This post isn't attempting to recreate the documentation, please read that here. Rather, this is more of a case study.

Creating the Pipe

In the initial component implementation, the pipe formats the date and replaces the day of the week text when the day is either today or yesterday. This is how the component class is written with the formatting logic in the component:

import { Component, OnInit } from '@angular/core';
import { formatDate, areSameDate, addDays } from '../utility';
import { Routine, RoutinesViewModel, RoutineViewModel } from './models';

@Component({
  selector: 'app-routines',
  templateUrl: './routines.component.html',
  styleUrls: ['./routines.component.css']
})
export class RoutinesComponent implements OnInit {
  private routines: Routine[] = [
    {
      name: 'Morning',
      lastCompletedDate: new Date()
    },
    {
      name: 'Social Media',
      lastCompletedDate: new Date(2017, 8, 23, 19, 55)
    },
    {
      name: 'Bedtime',
      lastCompletedDate: new Date(2017, 8, 5, 21, 16)
    }
  ];

  viewModel: RoutinesViewModel = {
    routines: []
  };

  ngOnInit() {
    this.render();
  }

  trackRoutine(routine: RoutineViewModel) {
    return routine.name;
  }

  // TODO: move to own pipe or directive
  private mapToDisplayDateText(date: Date): string {
    // TODO: Make today's date mockable, convert to UTC
    const todaysDate = new Date();
    const isToday = areSameDate(todaysDate, date);
    const yesterdaysDate = addDays(new Date(), -1);
    const isYesterday = areSameDate(yesterdaysDate, date);

    const dayText = isToday ? 'Today' : isYesterday ? 'Yesterday' : formatDate(date, 'dddd, MMMM, D, YYYY');
    const lastCompletedDate = `${dayText}, ${formatDate(date, 'h:mm A')}`;

    return lastCompletedDate;
  }

  private render() {
    const viewModel = {
      routines: this.routines.map(routine => {
        const routineViewModel: RoutineViewModel = {
          lastCompletedDate: this.mapToDisplayDateText(routine.lastCompletedDate),
          name: routine.name
        };

        return routineViewModel;
      })
    };

    this.viewModel = viewModel;
  }
}
<md-toolbar color="primary">
  <span>Routines</span>
</md-toolbar>

<md-nav-list>
  <md-list-item *ngFor="let routine of viewModel.routines; index as i; trackBy: trackRoutine">
    <a>
      <div md-line>
        <span class="mat-title">{{ routine.name }}</span>
      </div>
      <div md-line>
        <span class="mat-subheading-2">{{ routine.lastCompletedDate }}</span>
      </div>
    </a>
  </md-list-item>
</md-nav-list>

<a md-fab class="add-routine-button"><md-icon>add</md-icon></a>

This is the pipe and the component after refactoring:

import { Pipe, PipeTransform } from '@angular/core';
import { formatDate, areSameDate, addDays } from '../utility';

@Pipe({ name: 'todayAwareDate' })
export class TodayAwareDatePipe implements PipeTransform {
  transform(date: Date, todayText = 'Today', yesterdayText = 'Yesterday') {
    // TODO: Make today's date mockable, convert to UTC
    const todaysDate = new Date();
    const isToday = areSameDate(todaysDate, date);
    const yesterdaysDate = addDays(new Date(), -1);
    const isYesterday = areSameDate(yesterdaysDate, date);

    const dayText = isToday ? todayText : isYesterday ? yesterdayText : formatDate(date, 'dddd, MMMM, D, YYYY');
    const lastCompletedDate = `${dayText}, ${formatDate(date, 'h:mm A')}`;

    return lastCompletedDate;
  }
}
import { Component, OnInit } from '@angular/core';
import { Routine, RoutinesViewModel } from './models';

@Component({
  selector: 'app-routines',
  templateUrl: './routines.component.html',
  styleUrls: ['./routines.component.css']
})
export class RoutinesComponent implements OnInit {
  private routines: Routine[] = [
    {
      name: 'Morning',
      lastCompletedDate: new Date()
    },
    {
      name: 'Social Media',
      lastCompletedDate: new Date(2017, 8, 23, 19, 55)
    },
    {
      name: 'Bedtime',
      lastCompletedDate: new Date(2017, 8, 5, 21, 16)
    }
  ];

  viewModel: RoutinesViewModel = {
    routines: []
  };

  ngOnInit() {
    this.render();
  }

  trackRoutine(routine: Routine) {
    return routine.name;
  }

  private render() {
    this.viewModel = {
      routines: this.routines
    };
  }
}
<md-toolbar color="primary">
  <span>Routines</span>
</md-toolbar>

<md-nav-list>
  <md-list-item *ngFor="let routine of viewModel.routines; index as i; trackBy: trackRoutine">
    <a>
      <div md-line>
        <span class="mat-title">{{ routine.name }}</span>
      </div>
      <div md-line>
        <span class="mat-subheading-2">{{ routine.lastCompletedDate | todayAwareDate }}</span>
      </div>
    </a>
  </md-list-item>
</md-nav-list>

<a md-fab class="add-routine-button"><md-icon>add</md-icon></a>

There are a couple points to note. First, notice how much less code is in the component. Component code bases can grow very large. If possible, moving mapping logic out of a component generally improves the component's maintainability over time. Second, there used to be two models, one represented the 'entity' or server-side data model and the other represented the model for the view or 'view model'. This distinction may come back later but for now notice that the component no longer must keep track of the date object and the displayed date string. There is just one model, Routine with one date property.

Like how Angular Material creates an NgModule per component, the same convention can be followed for pipes. This is the NgModule for the TodayAwareDatePipe:

import { NgModule } from '@angular/core';

import { TodayAwareDatePipe } from './today-aware-date.pipe';

@NgModule({
  exports: [TodayAwareDatePipe],
  declarations: [TodayAwareDatePipe]
})
export class TodayAwareDateModule { }

It is imported into the RoutinesModule:

// other imports ...
import { TodayAwareDateModule } from '../pipes/today-aware-date.module';

@NgModule({
  declarations: [
    RoutinesComponent
  ],
  imports: [
    CommonModule,
    MdToolbarModule,
    MdListModule,
    MdIconModule,
    MdButtonModule,
    TodayAwareDateModule
  ],
  exports: [
    RoutinesComponent
  ]
})
export class RoutinesModule { }

Tip: Use the Angular v4 TypeScript Snippets Visual Studio Code extension to quickly create both pipes and NgModules.

To view the full repository, check out the branch for this post in the Bebop Routines project on GitHub.

Conclusion

In this example, you saw how to refactor a component's mapping logic to a re-usable pipe. This helps the component's maintainability by reducing both logic and state. Also, the pipe leverages Angular change detection to ensure the mapping logic is only executed when necessary.

Are you using pipes today? How have you found them to be the most useful? Let me know your thoughts and questions in the comments.

Creating the First Screen with Angular Material

Creating the First Screen with Angular Material

Derived from photo by Andy Melton / flickr.com, CC BY-SA

The last post showed how to prototype the Routines App UI using Adobe XD. This post focuses on building the first screen using Angular Material. Before working on the UI, generate a new project using the Angular CLI. If not familiar with the CLI, this is a good resource with which to get started.

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

This is a summary of decisions made and lessons learned while creating this screen:

  • Angular Material documentation has everything needed but it took me some time to get the whole mental model, hopefully this post will help anyone else getting started
  • Unlike Bootstrap, Angular Material's CSS doesn't attempt to canvas the whole screen with default CSS and it's more likely you will have to explicitly opt-in than opt-out of the Angular Material theming
  • While the Angular Material setup takes some time, using the components is straightforward by following the examples in the documentation

Adding Angular Material Dependencies

Getting started with Angular Material requires new npm packages, referencing CSS themes, and referencing fonts for Roboto typography and Material icons. First, install the required npm packages for Angular Material:

npm install @angular/cdk && @angular/material

The @angular/material package is somewhat self-explanatory and contains the modules and CSS required to use Angular Material components. The @angular/cdk is interesting. The CDK stands for component developer kit. This is a set of primitive components with defined functionality and API. Using these, anyone can apply custom visual design and extend with custom functionality. Some of the Angular Material themed components are built on top of CDK counterparts. For more information, see the documentation for the CDK data-table.

Next, add references for the Roboto font and Material icons font. These assets are common to the Material design language and Google makes them available on their CDN. Add the following lines in the <head> element of the src/index.html file:

  <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
  <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500" rel="stylesheet">

Angular Material currently includes four pre-built theme options for its components:

  • deeppurple-amber.css
  • indigo-pink.css
  • pink-bluegrey.css
  • purple-green.css

To create a custom theme, Angular Material provides a set of SCSS variables and mix-ins. For now, I'm choosing a pre-built theme. To apply, simply include the link to the pre-built CSS file in the src/styles.css file:

@import '~@angular/material/prebuilt-themes/deeppurple-amber.css';

By referencing the pre-built theme in the styles.css file, the Angular CLI bundles this and other referenced CSS together in one file.

If familiar with CSS frameworks such as Bootstrap, you may be used to the framework applying an extensive set of global styles to the page. Angular Material very deliberately tries to isolate its styles to the Angular Material components. For instance, if you add a regular HTML button to the screen without adding any Angular Material specific markup to it, it renders as the browser would.

Similarly, this also means that CSS used to reset browser-default margins are not applied. The first thing I noticed when starting to add the components to the UI is that I had a default padding around my body element. I found the most straight-forward way to handle this is to apply CSS resets as needed in the styles.css file. At this point, I have only needed to remove the default <body> margin and padding:

/* resets */
body {
  margin: 0;
  padding: 0;
}
/* end resets */

Adding Components

Essentially, this screen has three components: a header, list, and a button. Each of the components in Angular Material is contained within its own NgModule so each of the respective NgModules must be included as an import in the NgModule utilizing the components.

In addition, some of the Angular Material components depend on Angular animations. These are imported using the BrowserAnimationsModule. While I haven't seen any issues using the BrowserAnimationsModule in the component's NgModule versus the application's NgModule (or even removing it altogether), I decided to keep it in the application's NgModule to align with the documentation for now. This is the code for the app.module.ts file:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    BrowserAnimationsModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

For the RoutinesComponent, create a new folder called routines. In this folder are five files:

  • model.ts – type definitions for model objects
  • routines.component.css – the RoutinesComponent CSS
  • routines.component.html – the RoutinesComponent template HTML
  • routines.component.ts – the RoutinesComponent class
  • routines.module.ts – the NgModule to export the RoutinesComponent

Starting with the RoutinesComponent class, there are several things that happen here to create a static UI. First, take a look at the code:

import { Component, OnInit } from '@angular/core';
import { formatDate, areSameDate, addDays } from '../utility';
import { Routine, RoutinesViewModel, RoutineViewModel } from './models';

@Component({
  selector: 'app-routines',
  templateUrl: './routines.component.html',
  styleUrls: ['./routines.component.css']
})
export class RoutinesComponent implements OnInit {
  private routines: Routine[] = [
    {
      name: 'Morning',
      lastCompletedDate: new Date()
    },
    {
      name: 'Social Media',
      lastCompletedDate: new Date(2017, 8, 23, 19, 55)
    },
    {
      name: 'Bedtime',
      lastCompletedDate: new Date(2017, 8, 5, 21, 16)
    }
  ];

  viewModel: RoutinesViewModel = {
    routines: []
  };

  ngOnInit() {
    this.render();
  }

  trackRoutine(routine: RoutineViewModel) {
    return routine.name;
  }

  // TODO: move to own Pipe or Directive
  private mapToDisplayDateText(date: Date): string {
    // TODO: Make today's date mockable, convert to UTC
    const todaysDate = new Date();
    const isToday = areSameDate(todaysDate, date);
    const yesterdaysDate = addDays(new Date(), -1);
    const isYesterday = areSameDate(yesterdaysDate, date);

    const dayText = isToday ? 'Today' : isYesterday ? 'Yesterday' : formatDate(date, 'dddd, MMMM, D, YYYY');
    const lastCompletedDate = `${dayText}, ${formatDate(date, 'h:mm A')}`;

    return lastCompletedDate;
  }

  private render() {
    const viewModel = {
      routines: this.routines.map(routine => {
        const routineViewModel: RoutineViewModel = {
          lastCompletedDate: this.mapToDisplayDateText(routine.lastCompletedDate),
          name: routine.name
        };

        return routineViewModel;
      })
    };

    this.viewModel = viewModel;
  }
}

The component references several models from models.ts. There is a data structure for Routine which I consider more of a domain entity that represents the 'real-world' routine object. Also, there are a several models that represent the data structure of the UI or 'view models'.

The RoutinesComponent has a render method that maps the domain entity to the component's viewModel property. The viewModel property is the main data structure with which to bind the template. To track the items in the list, the class has a trackRoutine function.

The mapToDisplayDateText method should be moved but it's temporary purpose is to create a custom display format for the date. You will also notice some helper functions for Date objects imported from a utility folder.

This component and the required Angular Material NgModules are configured with the RoutinesModule in the routines.module.ts file:

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { MdToolbarModule, MdListModule, MdButtonModule, MdIconModule } from '@angular/material';

import { RoutinesComponent } from './routines.component';

@NgModule({
  declarations: [
    RoutinesComponent
  ],
  imports: [
    CommonModule,
    MdToolbarModule,
    MdListModule,
    MdIconModule,
    MdButtonModule
  ],
  exports: [
    RoutinesComponent
  ]
})
export class RoutinesModule { }

In addition to the MdToolbarModule (representing the header), MdListModule, and MdButtonModule, there is a re-usable icon module for the button's icon, MdIconModule. Beyond these imports, most of the Angular Material code is in the RoutinesComponent HTML template in routines.component.html file:

<md-toolbar color="primary">
  <span>Routines</span>
</md-toolbar>

<md-nav-list>
  <md-list-item *ngFor="let routine of viewModel.routines; index as i; trackBy: trackRoutine">
    <a>
      <div md-line>
        <span class="mat-title">{{ routine.name }}</span>
      </div>
      <div md-line>
        <span class="mat-subheading-2">{{ routine.lastCompletedDate }}</span>
      </div>
    </a>
  </md-list-item>
</md-nav-list>

<a md-fab class="add-routine-button"><md-icon>add</md-icon></a>

The header is the MdToolbar using the md-toolbar selector. The template uses the color attribute to apply the theme's primary color to the background. For more information on this component, check out the toolbar documentation.

The routine list is made up of the MdList and MdListItem components. A simple ngFor creates each list item. Within each list item, Angular Material's typography CSS classes mat-title and mat-subheading-2 apply the theme's font sizes. Read more about the MdList and MdListItem in the corresponding documentation.

Finally, the button in this case is an MdAnchor component with the md-fab attribute. There are several styles of buttons with their own selectors. To apply the icon, there is an MdIcon component. The MdIcon component's image is configured in the element's content, in this case add. These icons correspond to the list of Material Icons referenced from Google's CDN in the index.html file.

The button is the only component in this screen that has custom CSS to position it fixed in the bottom right of the screen. The CSS for this is in the routines.component.css file.

Read more about the button components here and the icon component here.

One final note is to include the RoutinesModule in the AppModule and the AppComponent template. To see how this fits together, look at the first-angular-material-screen branch in the GitHub repository.

End of the First Round

This being my first time using Angular Material, I found some snags. Hopefully this post helps you avoid the same. Overall, I like my experience with the library so far and I look forward to implementing more advanced scenarios as this application progresses. Have you given Angular Material a try? What do you think? Leave your thoughts in the comments.

Prototyping with Adobe XD and Angular Material

Prototyping with Adobe XD and Angular Material

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

This is a summary of decisions made and lessons learned while creating this prototype:

  • Adobe XD is free during the beta period and provides both wireframing and prototyping capabilities
  • Adobe XD comes with a set of Material Design Assets with which to build prototypes
  • Prototyping helps developers understand design considerations before potentially coding themselves into a corner
  • The Material Design assets provided by Adobe XD must be modified in some cases to match what Angular Material provides
  • Prototyping is a great way to start understanding Material Design for those who have never used it

Why Adobe XD?

When designing an application from scratch, it's tempting for developers to dive right into code. However, this often leads to dead ends and rework. Going through the process of wireframing and prototyping helps to understand design problems before investing in their development.

Wireframing is laying out the screens and UI elements. Prototyping is organizing the transitions or flows between these screens and states. Drawing on paper is a low-barrier method to wireframe and prototype. I have done this but I tend to miss the ability to copy and paste repeated UI. There are many software tools that do only wireframing OR prototyping but a much smaller selection accomplish both tasks. One of these applications is Adobe's relatively new Experience Design (XD) product.

There are several reasons I chose to use Adobe XD for this exercise. First, it's made by Adobe which is synonymous with 'professional design tools' and I can assume there is a large base of users from which to find examples, training, and support. Second, Adobe XD is currently free during the beta period. Adobe's Creative Cloud, while exceedingly capable, is arguably expensive at around $50 per month with an annual commitment. Not doing a lot of design work, it becomes difficult to justify this expense. When it's free, however, why not try it? Finally, Adobe XD comes out of the box with Material Design elements (and others) that I leveraged to make my prototype.

To get started, Adobe XD has a built-in tutorial. This was enough to orient me to the major features. However, you can read more about Adobe XD here.

Why Angular Material?

Why choose Angular Material? To start, I wanted to use an existing design language. My main skill is development and so I wanted to leverage existing design work to get my application off the ground as quickly as possible. Material design is a design language based off a set of patterns and principles. Frameworks have adapted these patterns to existing technologies. Angular Material, for instance, has adapted Material Design for Angular.

Angular Material is a set of Angular components built to fit the Material Design language. In addition, Angular Material represents some of the best thinking on how to implement UI component libraries for Angular-based applications. By using this library, I expect to better understand best practices for creating my own re-usable UI components.

Finally, I think Material Design looks good. I find applications built with Material Design to be useable and feel playful. However, I don't know much about it. I don't use many Google applications regularly. By creating a prototype, I can research how these UI components are combined to create an application.

Take the playful aesthetics and combine this with pre-built components, design principles, and prototyping support, and the choice to use Angular Material and Adobe XD makes sense.

Wireframing

Adobe XD offers sets of Material Design, iOS, and Windows assets called UI Kits. When selecting a UI Kit from the menu, Adobe XD opens a new window with a project containing all the assets. From there, you can copy and paste the assets you want to use in your own project.

To start, I copied a view of the Safari browser from the iOS UI Kit. This helps ground the fact that this application will be running in a browser. Next, I opened the Material UI Kit. These assets are designed to mimic native Android apps. To adapt the assets to Angular Material, I opened the Angular Material web site side-by-side with the Angular Material UI KIt. I adapted the existing assets to match what was available in Angular Material. For instance, I combined a text input and menu to recreate the Angular Material select component.

This is what the Material UI Kit gives you out of the box:

Adobe XD Material UI Kit Input

Adobe XD Material UI Kit Menu

This is my own composite to roughly match the Angular Material select:

Angular Material select component

The first screen, referred to as an artboard, takes the most time to create. From there, you can duplicate screens and modify them to wireframe the rest of the application more quickly.

Duplicate artboards worfklow

I didn't spend a lot of time on the initial design, enough to get acquainted with the tool and create the first set of interactions. You can see the current state of the prototype here. Also, visit the Adobe XD documentation to learn more about the program's features.

This is the full set of initial artboards.

Initial application artboards

Prototyping

After the artboards are created, Adobe XD makes it easy to prototype interactions by linking artboards together with transitions.

Adobe XD transitions

Simply select the element that triggers the transition and link it to the target artboard representing the new state.

Adobe XD link transitions

Once all the artboards are linked, you can 'play' the prototype. When in this mode, the artboards are not editable. The user clicks the onscreen elements and Adobe XD displays the linked artboard with the selected transition. This allows the user to get a feel for how the application behaves.

Adobe XD Transition Animation

I almost skipped creating a prototype because I already had an idea of how the screens would flow together. However, the process to create the prototype took very little time and it was somewhat gratifying to see the prototype 'working' even if in a rudimentary state.

Especially if designing this application for other users than myself, the prototype would allow me to perform usability testing. The testing would provide valuable design feedback to incorporate before investing in development effort.

Takeaways

Not being very familiar with Material Design, I had a chance to research how the Angular Material components fit together in an application. Furthermore, I became better acquainted with the various components that Angular Material offers.

I found Adobe XD to be a very capable tool and will consider using it for other application ideas going forward. It was easy to get started and I could become more efficient using the tool with more experience.

I look forward to seeing how Adobe XD evolves overtime and using it more in the future. Have you given it a try? Leave a comment below sharing your experience.

Sprint Planning in Visual Studio Team Services

Sprint Planning in VSTS

Derived from photo by Dafne Cholet / flickr.com, CC BY

Getting started in Visual Studio Team Services (VSTS) eventually leads to planning a sprint. This post discusses how to configure a sprint in VSTS and schedule work for this iteration.

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

This is a summary of decisions made and lessons learned while creating this project in Visual Studio Team Services (VSTS):

  • Chose two weeks for the initial sprint duration and because I am a team of one, I may have varying sprint durations in the future to fit my schedule. While VSTS supports varying sprint durations, teams generally operate better with a consistent schedule.
  • Set the sprint capacity to later compare to scheduled work. Although VSTS capacity is set per day in hours, this number can be calculated from week-based or sprint-based capacity estimations.
  • Estimated backlog items using a modified Fibonacci sequence, roughly based on hours to start but will be used to comparatively size future product backlog items.
  • Estimated tasks in hours and added the Original estimate and Completed work fields to the task work item template for tracking this information as well.
  • Verified the scheduled work against the configured capacity and adjusted the scheduled work to fit the sprint capacity.

Configure the Sprint

The first thing to determine is the duration of sprints. If working on a large team, predictable sprint durations are helpful to keep everyone on the same page. However, for a project with one developer, I am going to determine sprints more on my own availability. I have been working recently in two-week increments, but alternating these iterations between code-related projects and other personal projects. So, while I may have a sprint that lasts two weeks, I may not schedule the next sprint until two weeks after the end of the previous. Also, I try to squeeze in a "week off" to my schedule occasionally where I try not to focus on achievement but rather rest and spend time with friends and family. The point is that while large teams may benefit from predictable sprint durations, Visual Studio Team Services allows for flexible durations if that works better for you and your team.

To set the dates, go to the Work section of the team project. VSTS provides a default list of iterations named Sprint 1, Sprint 2, etc. Choose Sprint 1 to view the page for that iteration. Look towards the top right of the screen and you will see a link to Set dates. Click that link and this dialog appears:

Edit iteration dialog

Set the start and end date for the sprint. Optionally, change the sprint name. I decided to go with sprint names that correspond to famous jazz musicians of the bebop era. Press Save and close to save the sprint.

Tip: The Iteration settings are also available from the Settings menu in the top navigation. Select Work, then Iterations to modify the full iteration list.

Full iteration list

Set Capacity

Capacity is another tool for scheduling work. By setting the capacity for people working on the project (even if only yourself), it helps determine if the team is committing to too much or too little work for the sprint. The VSTS sprint burndown chart also uses this number to visualize progress.

The first step is to determine how many hours per day or week everyone can commit to the project. I have roughly 14 hours per week to devote during this sprint. On the page for the current sprint, select the Capacity tab:

Capacity tab

Enter the capacity per day. Since I can do 14 hours per week, I entered in 2 hours per day. This field allows for decimals to accommodate the daily number for any week-based or sprint-based capacity estimations. For instance, if a teammate could only work 20 hours for the entire sprint, divide 20 hours by the number of days in the sprint (14) to arrive at a daily capacity of 1.43.

By default, VSTS does not count weekends as working days. Being a personal project, the weekends are prime time for getting things done so I wanted them to count towards the capacity. To enable them, click on the gear/settings icon in the top right of the team's work page and then find the settings for Working days. Enable the checkboxes for those days to include them in the capacity.

Working days settings

Estimate Product Backlog Items and Tasks

To improve my estimation skills, I'm estimating my work in VSTS. This isn't entirely necessary but I find tracking this over time leads to a better understanding of what can be accomplished in each sprint. I use two different estimation systems for product backlog items and tasks.

For product backlog items, I like using a modified Fibonacci sequence like what's found on a planning poker deck. The modified sequence progresses as 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, etc. The product backlog item estimates do not reflect hours, but are sized relative to each other. I happen to use hours as a baseline when starting out. For instance, because this is my first sprint and first estimates, the three backlog items estimated equal 24 (8 each). This is roughly equivalent to my sprint capacity which is 28. This can be confusing for some because the units of measure are close (sizing versus hours) but not the same. I like having that loose association but I must remember that when estimating backlog items, I'm thinking about how they compare to other backlog items, not how many hours they will take. For instance, if I start thinking that a backlog item is 10 hours, I would force myself to estimate it as either an 8 meaning that it is roughly equivalent to the amount of work done for a complete product backlog item or I would decide that it is indeed larger and estimate at 13 which is the next largest number in the modified Fibonacci sequence.

Once the backlog items have been estimated, choose one or more for the sprint backlog by setting the sprint property in the product backlog item itself. I decided to take one product backlog item off my product backlog and added two new ones to the sprint and estimated them. The two new backlog items represent blog posts discussing the project work.

Once I have the backlog items that I think I can accomplish during the sprint, I start to break them down into tasks. These tasks are estimated in hours which will be matched to the sprint capacity. By default, the scrum process template in VSTS gives one field for task estimation, Remaining Work. This field is used to calculate the burndown chart as the sprint progresses. I decided to also add the Original estimate and Completed work fields to my task work items to get a better understanding of how well (or not) I estimate a task. These fields already exist in VSTS and simply need to be added to the work item template. This documentation provides details on customizing work items. Be sure to assign each task to yourself or the person scheduled to implement the work during the sprint. Look at the board view for the sprint and this is how each backlog item appears:

Product Backlog Item on Kanban board

One final thing to do before finalizing the sprint plan is to check the capacity screen one more time. On the right-hand side, there are bullet graphs representing each team member's capacity and the amount of work scheduled for them. If the bars are green, you are good to go. If they are red, it means an individual has more estimated work than capacity and you should consider adjusting the workload.

Capacity Screen

Get to Work

Now it's time to get started working through the sprint backlog. Use the Kanban board to easily visualize the sprint work. As work is accomplished, update each task with the time remaining and time completed.

Finally, refer to the sprint burndown chart to see if you are on track to reach your goals. Happy coding!

Creating a Project in Visual Studio Team Services

Starting a Personal Project in Visual Studio Team Services

Derived from photo by Ignacio Palomo Duarte / flickr.com, CC BY

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete listing of posts here.

This is a summary of decisions made and lessons learned while creating this project in Visual Studio Team Services (VSTS):

  • VSTS is free for teams up to 5 users
  • Started with a backlog to outline ideas for the application
  • Only entered items related to the first milestone which is a minimum prototype to validate the application's usefulness
  • Chose Git source control for my VSTS project because of personal preference and because it will be easier to publish the source code publicly to GitHub while maintaining day-to-day work in VSTS
  • Chose the Scrum process template for the VSTS project because the work item flow is slightly simpler given that I am both the developer and the user
  • Created Feature work items for items that, when complete, demonstrate value to the user
  • Created Backlog Item work items for items that benefit the engineering or design process

Creating the Project in Visual Studio Team Services

First, understand that Visual Studio Team Services (VSTS) is free for teams of up to five developers (and unlimited for work item access). This includes free private source control repositories, agile work management, build credits, and more. Check out all the free stuff here.

In VSTS, I created a new project named Bebop. There are two main decisions to make when starting the project, the type of source control to use and the work item template. I chose Git source control because I have grown to really like the ease at which I can create branches and work with multiple repositories. For instance, even though the source code will primarily live privately in VSTS, I will post it publicly to GitHub and Git makes it easy to distribute in this way.

For the process template, I chose the Scrum template. The work item status flow requires slightly less steps which is preferable given that I am the developer and customer at this point. Also, I prefer the terminology of Backlog Item over User Story for organizing work. As a developer, there are many times where system changes are made for performance or security reasons and I find writing user stories such as "As a 'user', I expect my software to be secure…" unnecessary. There are dozens of different ways to approach this configuration so do what's best for your team and project. Here is more information regarding the various process templates built-in to VSTS.

Creating the Backlog

Upon developing the backlog, I started the list in OneNote and then later moved it to Visual Studio Team Services (VSTS). It doesn't really matter the tool when starting, the initial backlog is simply a list of items that need to get done. I also thought of a couple milestones and only added items related to the first. The first milestone is to deliver the minimum feature set that can prove whether my idea for the app will even work in real-world usage. The initial list of backlog items is specific to this goal.

When brainstorming the items, there were two large categories in mind. The first category relates to which items I need to put in place to deliver the demo application. These are things like source control, deployments, etc. I also included in the list to create a prototype design. Before writing any code, it helps to take the initial bucket of features and mock out the user interface and interaction design to help avoid designing into a corner during coding. For these items, I created a Product Backlog Item work item.

The second category of backlog items were the actual features themselves. For these items, I create a Feature work item. Don't worry if you decide to use the work item types differently later as you can change the type if needed. I like to be granular when breaking down features and functionality on the backlog. While there are no deadlines, per se, estimating and tracking these work items is valuable for developing estimation skills and smaller backlog items help enable better estimations. There are other insights that VSTS will give based off these estimations such as a burndown chart for each sprint.

For now, I focused on getting the work into the system which amounts to nothing more than filling out the title of the work item. It will be an ongoing process to refine the list and further schedule it for implementation. This is what the initial list looks like in VSTS:

Backlog Screenshot

In the next post, I'll look at how I'm going to schedule this work in VSTS and organize it into sprints. The process of creating a backlog in VSTS is simple yet there are subtle decisions to make in organizing the work. What are your preferences for creating a backlog in VSTS?

Introducing Project Bebop

Introducing Project Bebop

Derived from photo by Loren Kerns / flickr.com, CC BY

Today starts a new journey on angularfirst.com. Welcome to Project Bebop.

Going forward, each post will detail successes and challenges using Angular, Visual Studio, ASP.NET Core, and Azure in the context of a real application. Being a side-project, helmed by one developer who is also the primary customer, this won't reflect all the considerations of an enterprise application. However, where possible, I will use enterprise-grade development techniques during development.

The goal is that you will gain insight into the benefits and challenges of adopting new technologies and techniques in Angular, Visual Studio, ASP.NET Core, and Azure. More importantly, you will see how these pieces fit together. This is the area that I find the most interesting and plan to focus on these integrations. Developers can't always start from a blank slate and are forced to adopt technologies in an unconventional and/or incremental way with their existing code base. I will get to cover these tradeoffs with examples that you can see in real-time.

The project itself is a personal take on a To-Do application. I'm surprised that given the amount of To-Do applications on the market, I still end up falling back to tools like OneNote and Excel to organize my life. So, I'm going to build one for my own needs and the goal is that anyone else who finds it interesting will be able to use it too.

To be clear, though, the primary goals are learning and sharing. This is an exercise in product development for the lone developer and I'm looking forward to sharing the journey.

This is the list of blog posts related to the project:

The NgModule ‘forRoot()’ Convention

The NgModule forRoot Convention Hero Image

Derived from photo by Boris Tassev / flickr.com, CC BY-SA

The NgModule forRoot() convention is a curious one. The naming explains how to use it but not what it is or more importantly why it's necessary to import an NgModule in this way.

This post peeks beneath the API to help you understand this design and get the most out of the convention.

The NgModule forRoot() Convention

There comes a point when developing in Angular when an NgModule requires a call to its forRoot() method when importing. The most notable example of this is with the RouterModule. When registering this module at the root of an Angular application, importing the RouterModule looks like this:

import { RouterModule, Routes } from '@angular/router';

const routes: Routes = [
    { path: '',   redirectTo: '/index', pathMatch: 'full' }
];

@NgModule({
  imports: [
    RouterModule.forRoot(routes)
  ],
  ...
})
export class AppModule { }

This convention is also used in ngx-bootstrap and was previously used in Angular Material. The convention implies that a given module must be registered with the root NgModule of an application while invoking the forRoot() method. What is so special about this method that it needs to be called at the root of an application as opposed to any other NgModule?

For starters, what does the forRoot() convention return? Generally, the return type for this method is an object conforming to the ModuleWithProviders interface. This interface is an accepted NgModule import and has two properties:

interface ModuleWithProviders { 
  ngModule: Type<any>
  providers: Provider[]
}

Put simply, the forRoot() method returns an NgModule and its provider dependencies. What does this have to do with the root NgModule? Maybe nothing. In fact, while this convention implies that it must be imported at the root of the application, in many cases you can import it in a non-root NgModule and it will work – GASP!

Putting that aside for a moment, this is how the ModalModule in ngx-bootstrap uses the forRoot() convention:

import { NgModule, ModuleWithProviders } from '@angular/core';

import { ModalBackdropComponent } from './modal-backdrop.component';
import { ModalDirective } from './modal.component';
import { PositioningService } from '../positioning';
import { ComponentLoaderFactory } from '../component-loader';

@NgModule({
  declarations: [ModalBackdropComponent, ModalDirective],
  exports: [ModalBackdropComponent, ModalDirective],
  entryComponents: [ModalBackdropComponent]
})
export class ModalModule {
  public static forRoot(): ModuleWithProviders {
    return {ngModule: ModalModule, providers: [ComponentLoaderFactory, PositioningService]};
  }
}

Notice how the ModalModule does not declare any providers in the @NgModule decorator but does so in the static forRoot() method.

Why is the Root NgModule Important?

Even though importing the additional providers of the forRoot() method theoretically works in child NgModules, registering it at the root of the application helps in a number of ways.

First, consider how Providers are injected differently than components and directives. Typically, when decorating a class with @Injectable and registering as a provider in an NgModule, this class is created once and that one instance is shared amongst the entire application. When Angular bootstraps the root NgModule, all available imports in all NgModules are registered at that time and made available to the whole application – they are global. This is why providers registered in a child NgModule are available throughout the whole application.

Components and directives on the other hand are instantiated multiple times, once per instance in the markup. In addition, these items are scoped to the NgModule in which they are imported to prevent naming conflicts where two components might have the same selector for example. Because of this difference in dependency injection (DI) behavior, the need to differentiate an NgModule containing components and directives from a ModuleWithProviders containing components, directives, and providers is helpful which is where the forRoot() method makes that distinction.

Dependency injection, however, doesn't always work this simply. There are times when all the application's NgModules are not available during the bootstrap process. Lazy-loading is such an example. When lazy-loading an NgModule during routing, the providers registered in the lazy-loaded NgModule and its children aren't available during the bootstrap process and Angular is unable to register them at that time. Therefore, they are added as providers only when the route is loaded and furthermore they are scoped to be injected starting at the lazily-loaded NgModule and its children. If there are multiple lazy-loaded NgModules attempting to register the same providers, each of these nodes of the NgModule tree end up with different instances. By importing the providers at the root, it helps ensure that all lazy-loaded NgModules get the same instance of the provider and is why forRoot() is named as such.

Be sure to read more about the nuances of Angular's dependency injection in the documentation.

When to Use the forRoot() Convention

As a consumer, use it when a library dependency requires it. Import the module at the root of the application and register with the forRoot() method to import the providers globally. In other NgModules, use the appropriate non-root form of the import when necessary to import the components and directives.

In the case of both Angular Routing and ngx-bootstrap, this convention helps share providers amongst multiple instances of directives and components to achieve a global concern for the application. For example, ngx-bootstrap uses this convention for the modal dialog component. While there may be many modal instances defined in the markup of an application, the modal takes over the entire UI hence all instances of the dialog should understand how they affect this global concern.

In the case of routing, there is only one window.location for the application so even though there may be child routes and various instances of router-outlet components, they all need that one global dependency of the window's location so that they can work together.

In both cases, the consumer of the modal dialog or router does not need to know how these items communicate and manage shared concerns. In this way, the forRoot() method abstracts away the necessary provider registration.

In short, consider using the convention when you have multiple custom components or directives that all take a dependency on a global UI concern and need to work together to manage this global state. To be clear, the forRoot() convention is a form of coupling which should only be used after careful design consideration.

It's best to avoid using this convention with third-party libraries. For instance, don't try to bubble up all the NgModule dependencies of the application using this convention. The providers returned by the forRoot() method should be internal dependencies that work exclusively with the other components included in the ModuleWithProviders. Third-party dependencies should be treated like npm peerDependencies and imported and registered in the root NgModule directly so that other components can more easily share the same dependencies and help ensure all consumers reference the same package version when npm versioning resolves.

Takeaways

In summary, the forRoot() convention represents a way to import an NgModule along with its providers using the ModuleWithProviders interface.

When a feature NgModule exports components and directives that require sharing the same custom provider instances, consider registering these providers in the root NgModule with a forRoot() method. This can help ensure that all child NgModules have access to the same provider instances without requiring the consumer to handle the provider registration explicitly.

For more information on implementing the forRoot() convention, there are some additional implementation ideas found in the Angular documentation.

Please leave a comment below sharing your experiences using the forRoot() convention.

When to Use ES2015 Modules Instead of Angular Dependency Injection (and When Not to)

When to Use ES2015 Modules Instead of Angular Dependency Injection Title Image

Derived from photo by fdecomite / flickr.com, CC-BY

This post discusses some of the nuances between ECMAScript 2015 module dependencies and Angular's dependency injection system. These are design considerations and while you may decide not to use the approaches discussed, the goal is to provide you with a context in which to make more thoughtful decisions about how to use dependencies throughout your Angular application.

A Tale of Two Dependency Systems

When building an Angular application, there are two main dependency systems at play. The first is EcmaScript 2015 (ES2015) modules. This is the system used when creating an import statement or exporting an object. This system uses string identifiers to obtain dependencies via URL or npm package name.

import { platformBrowser } from '@angular/core';

The other dependency system is Angular's dependency injection (DI) system which is built on top of the ES2015 module system. Unlike the static nature of ES2015 dependencies, these dependencies are configurable when the application bootstraps. They are typically defined as a provider in an NgModule.

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule
  ],
  providers: [
    ShoppingCartService
  ],
  bootstrap: [ 
    AppComponent 
  ]
})
export class AppModule {

}

While not entirely a one-to-one relationship, consider the idea that ES2015 module dependencies are hard dependencies meaning they cannot easily change upon running the application. On the other hand, Angular provides a more loosely-coupled dependency structure that is more easily configured at runtime.

Note: There are in fact more than two dependency mechanisms if you consider npm module resolution where version numbers can influence the resolution of ES2015 modules or a bundler like webpack which can conditionally swap ES2015 dependencies based on configuration. This would be tooling-based configuration whereas this post focuses on code-based configuration.

Angular Dependency Injection (DI)

At a high level, Angular reads the NgModule metadata during the bootstrap process and creates an injector capable of providing these dependencies through the class constructor of components and services throughout the application. Please read more about Angular's dependency injection in the documentation to understand the full details. This post refers to Angular dependency injection at a high level.

To look at an example, consider an e-commerce application with a digital shopping cart. Imagine a mini-view of the cart while the user is browsing product pages and a separate, detailed view when it's time to check out. The logic to calculate the quantity of items in the cart is the same for each view. Therefore, both pieces of the UI may depend on a ShoppingCartService to calculate the total quantity of items in the cart. This service is provided to the components through dependency injection.

shopping-cart.service.ts

import { Injectable } from '@angular/core';
import { CartDetail } from './shopping-cart.model';

@Injectable()
export class ShoppingCartService {
  getTotalQuantity(cartDetails: CartDetail[]): number {
    if (!cartDetails) {
      return null;
    }

    const total = cartDetails.map(carDetail => carDetail.quantity)
      .reduce((previous, current) => previous + current, 0);

    return total;
  }
}

shopping-cart.component.ts

import { Component } from '@angular/core';
import { CartDetail } from './shopping-cart.model';
import { ShoppingCartService } from './shopping-cart.service';

@Component({
  selector: 'app-shopping-cart',
  templateUrl: './shopping-cart.component.html'
})
export class ShoppingCartComponent {

  shoppingCart: CartDetail[] = [
    { productName: 'Hammer', quantity: 1 },
    { productName: 'Purple Shorts', quantity: 26 },
    { productName: 'Web Shooter', quantity: 2 }
  ];

  totalCartQuantity = this.shoppingCartService.getTotalQuantity(this.shoppingCart);

  constructor(private shoppingCartService: ShoppingCartService) { }
}

Consider the number of steps involved in registering and using this dependency in a component through Angular's DI:

  1. Create the ShoppingCartService class
  2. Import and decorate the dependency with the @Injectible() decorator
  3. Import the dependency into the appropriate NgModule
  4. Register the service as a provider
  5. Import the dependency in the component's ES2015 module
  6. Add it as an argument in the component's constructor
  7. Use the dependency

That's quite a bit of code to implement the default DI recommendation. This isn't a criticism, just an observation. Because this implementation uses the ES2015 module standard and includes the added TypeScript benefits, these steps are reasonable in pursuit of loosely-coupled dependencies.

Note: The Angular CLI can help you avoid having to write some of this code by hand.

While Angular's dependency injection implementation comes with many benefits, it's worth considering an alternative.

Using ECMAScript 2015 (ES2015) Module Dependencies

Instead of creating a class and registering it with an NgModule, consider writing a more generic piece of code that can map and calculate a total from an array of objects. Create a function called mapArraySum in its own ES2015 module. Look at the steps for using this function in a component:

  1. Create the mapArraySum function
  2. Import the dependency in the component's ES2015 module
  3. Use the dependency

mapArraySum.ts

export function mapArraySum<T>(array: T[], mappingFunc: (item: T) => number): number {
  if (!array) {
    return null;
  }

  const total = array.map(mappingFunc)
    .reduce((previous, current) => previous + current, 0);

  return total;
}

shopping-cart.component.ts

import { Component } from '@angular/core';
import { CartDetail } from './shopping-cart.model';
import { mapArraySum } from './mapArraySum';

@Component({
  selector: 'app-shopping-cart',
  templateUrl: './shopping-cart.component.html'
})
export class ShoppingCartComponent {

  shoppingCart: CartDetail[] = [
    { productName: 'Hammer', quantity: 1 },
    { productName: 'Purple Shorts', quantity: 26 },
    { productName: 'Web Shooter', quantity: 2 }
  ];

  totalCartQuantity = mapArraySum(this.shoppingCart, item => item.quantity);
}

Wow, this is a much simpler approach. Furthermore, the dependency is completely decoupled from anything Angular-specific like @Injectable. Which implementation should you use? There are several considerations that should factor into this decision.

When to Consider Using ECMAScript 2015 Modules

The reason the ShoppingCartService is probably not a good candidate for straight ES2015 module dependency management is twofold. First, the UI of a shopping cart is generic enough where you may want to re-use the shopping cart UI components in multiple applications. These applications may employ different shopping cart logic. Second, the checkout process is prone to business changes and totaling a cart may change very much depending on promotions, shipping rates, or other business rules. You may find that calculation can no longer be done on the client and must involve a call to the server.

Potentially, it makes sense to employ both implementations where the ShoppingCartService exists as a loosely-coupled dependency yet its implementation leverages the generic mapArraySum function.

shopping-cart.service.ts

import { Injectable } from '@angular/core';
import { CartDetail } from './shopping-cart.model';
import { mapArraySum } from './mapArraySum';

@Injectable()
export class ShoppingCartService {
  getTotalQuantity(cartDetails: CartDetail[]): number {
    const total = mapArraySum(this.shoppingCart, item => item.quantity);
    return total;
  }
}

Before detailing what criteria indicates a potential candidate for ES2015 dependency management, remember that when in doubt the safer choice is to use Angular's dependency injection. In the end, it provides much greater flexibility if you ever need it.

These criteria potentially identify code suitable to use ES2015 dependency management:

  1. Pure functions with stateless logic (e.g. calculations, validations, mapping data structures)
  2. No external dependencies (e.g. HTTP requests)
  3. Generic functionality (e.g. language-level functionality, contract-based data mapping)
  4. Throw-away code for prototyping purposes

Given these criteria, and other than rough prototypes, what type of code specifically does this cover? This type of code can go by many names, but falls into the category of utility functions. This is code that helps you do things that you repeatedly do in any JavaScript application. It's the code you get sick of writing over and over. A simple example is a function that checks if an object is null or undefined.

export function isNullOrUndefined(value: any) {
    const isNullOrUndefined = value === null || value === undefined;
    return isNullOrUndefined;
}

This is a one-liner, but consider building on it:

export function isAnyNullOrUndefined(values: any[]) {
    // this would be more lines without support for .some()    
    const isAnyNullOrUndefined = values.some(value => isNullOrUndefined(value));
    return isAnyNullOrUndefined;
}

// another common example
export function isEmptyString(value: string) {
    const isEmptyString = !isNullOrUndefined(value) && value.length === 0;
    return isEmptyString;
}

What about a function that adds all the numbers in an array and rounds to a specific number of decimal places? This logic is prone to errors or inconsistencies in implementation. Do you round before or after you add? How do you guard against precision errors? These are all things a developer shouldn't have to keep revisiting while building an application. How do you perform a deep clone or a deep compare of two objects? These are all examples of common logic that developers use again and again.

Could you still put this logic in an Angular service and inject it into a component? Absolutely. The point is that you have another option that might prove more simple, elegant, and/or re-usable. Ultimately, choose what's best for your team and your project.

Use ES2015 Modules to Abstract Hard Dependencies

You may have been thinking during the last section, "Aren't there utility libraries to use for these types of utility functions?". There are and developers use them every day. The question is, should your application take a hard dependency on these libraries?

Based off the information thus far, this functionality can probably safely exist as an ES2015-based dependency. However, you can partially ease the coupling by abstracting the specific framework or library reference to within a library under your control. In this way, if you decide for examples that lodash's deep compare function is no longer required because of an emerging ECMAScript standard, you can easily replace it in one place without affecting the rest of the application.

Consider an isEqual module:

isEqual.ts

import * as _ from 'lodash.isequal';

export function isEqual(target: any, comparison: any) {
    const isEqual = _.isEqual(target, comparison);
    return isEqual;
}

app.component.ts

import { isEqual } from './app-utility/isEqual.ts';

@Component({
    selector: 'my-app',
    template: './app.component.html'
})
export class AppComponent {
    foo: any;

    onSomeEvent(newFoo: any) {
        if (isEqual(this.foo, newFoo)) {
            return;            
        }

        console.log('foo is new');
        this.foo = newFoo;
    }
}

So instead of repeatedly coupling your components to third party libraries, depend on your own utility library where you can replace or remove third-party utility libraries as necessary.

Conclusion

Again, this post is intended to help you think more deeply about the dependencies in your Angular application. There are many different approaches to handling these designs. What approaches do you use to manage dependencies in your applications?

Google I/O 2017 Talks for Angular Developers

Google I/O 2017 Talks for Angular Developers

In keeping with conference season, here is a list of videos for Angular developers from Google I/O 2017. While Google is arguably the most important company to the open web between Google Search and Chrome, they have other large platforms targeted at backend and native mobile developers. The breadth of Google's offerings can make it difficult to find the resources targeted at the front-end, Angular developer.

This is a collection of videos from this year's conference separated by category. While there are only a few Angular-specific videos (for more, look at the ng-conf 2017 list here), there are many sessions looking at the broader web platform, progressive web applications (PWA), and web components with Polymer. In addition to these core technologies, there are also videos listed for other technologies that are relevant or are becoming relevant for Angular developers like AMP and AR/VR.

Enjoy the below curated list of videos. To view all the videos from Google I/O, check out the playlist on YouTube.

Keynotes

General Web Platform

Progressive Web Applications

Web Components and Polymer

User Experience, Accessibility, and Design

Firebase

Artificial Intelligence and Machine Learning

Virtual Reality and Augmented Reality

That's the list. If you have a favorite, let everyone know in the comments.

Build 2017 Videos for Angular Developers

Build 2017 Videos for Angular Developers

After watching approximately six hours of keynote videos from Microsoft's Build Conference 2017, it's clear that no single company produces more software for developers than Microsoft. There are tools for virtually every platform. There are SDKs for Windows, Xbox, and Office. You can even use Visual Studio to develop an extension for Visual Studio.

With so many developer products, how do you determine which is relevant to you? That question is the inspiration for this post.

The following is a categorized list of videos from Build 2017 that are most relevant to an Angular web developer. The usual suspects are here including TypeScript, Visual Studio 2017, Visual Studio Code, Progressive Web Apps (PWA), ASP.NET, and Node.js. Going further are newer technologies such as Azure Serverless products, brand-new Cosmos DB, Mixed Reality, Artificial Intelligence offerings, and the debut of Fluent Design.

For the full list of all 450 videos, visit the event page on Channel9. Also if you find a favorite video absent from the list, please leave a comment.

Angular and Front-End

Tooling

Visual Studio Code

Visual Studio 2017

More Tooling

ASP.NET

Node.js

Azure – Serverless

Keynotes

Mixed Reality

Azure – Cosmos DB

Microsoft Graph

Fluent Design

Artificial Intelligence (AI)

Bot Framework

Cognitive Services

More AI