We are excited to announce that our free Nx Workspaces course has been updated to cover Nx version 6 and above! The latest version of Nx aligns with the Angular CLI version 6, which brought about some changes to the workspace files, structure and command options. This course now includes all of that, providing a great way for you and your teams to get up and running with the current version of Nx.

Nx is a set of extensible dev tools for monorepos that has first class support for Angular, React, and NodeJS applications.

In this updated course you will learn how to create new Nx Workspaces with Nx 6 or upgrade an existing Angular CLI 6 workspace to an Nx Workspace. You will also learn how to add apps and libs to the workspace and how to serve and build apps within the workspace.

Learn More About This Free Course

We also have a few blog posts that cover what’s new in Nx version 6.x:

• Announcing Nrwl Nx 6.0
• Nrwl Nx 6.1: Better Dev Ergonomics, Faster Builds
• Nrwl Nx 6.2: Angular 6.1 and Better State Management
• Nrwl Nx 6.3: Faster Testing with Jest

If your company or team is experiencing challenges with architecting and engineering Angular applications at scale, the team at Nrwl can help! Visit https://nrwl.io to learn more and to get in touch.

Nrwl has been started by ex-Googlers and Angular team members Victor Savkin and Jeff Cross. We are a distributed company with folks all over North America and offices in Toronto and New York. Some of our recent open source projects include Angular Console and Nx.

Learn more about open positions at Nrwl here.

Free Nx Workspaces Course Updated for Version 6 was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last month we announced Angular Enterprise Playbook and our first free course, Nx Workspaces. This month we have another free course that we are publishing that takes a look at what is coming in the Angular version 6.0.0 release and showcases some of the updates since the version 5.0.0 release.

Angular v6: What is Coming and Updates Since v5

Angular Enterprise Playbook is one of the ways we help enterprise teams learn and adopt established best practices to build Angular apps at scale. To be successful in that arena, an important practice is to embrace the Angular semantic version release cycle. However, it’s not always easy (or efficient) for teams to be constantly monitoring the planned milestones and change-logs for Angular.

We are putting together a course that will deliver that information to you, ahead of the code release, that highlights the stuff teams will benefit from and might be impacted by. And we are making this course available while we are in the process of completing it so you will be able to receive the content as soon as it’s published.

This new free course, Angular v6: What is Coming and Updates Since v5, will cover a preview of what is upcoming as well as a detailed look at the minor releases that have come out since the release of version 5.0.0. It will also touch on the release strategy in more detail to get a better understanding of the versioning and what to expect with each release.

Feedback Wanted

We are always looking for feedback on the content we create. Each of the lectures has comments enabled, so please leave feedback there to let us know what we can do to make this a useful resource to you. Or if you have general feedback about Playbook, please submit a form with your suggestion here: https://goo.gl/forms/Tl3BSEwsW1lMbPe43

Coming Up

We will continue to publish additional videos to this course as they are completed and get them to you ahead of the Angular version 6.0.0 release. And again, keeping teams informed is an important part of that puzzle that we aim to fill in as Angular moves forward, so expect similar courses as versions of the platform progress.

Visit angularplaybook.com to get started.

This blog is brought to you by Nrwl.io. → Enter to win a ticket to ngAtlanta, with Nrwl’s random ticket draw! 🍀😊

Angular Enterprise Playbook Course — Angular v6: What is Coming and Updates Since v5 was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

Justin Schwartzenberger is a Product Manager and Educator on the Nrwl team. He is also the host of AngularAir, a weekly videocast about all things Angular.

Nx helps organize domain specific applications and libs into a mono repo powered by the Angular CLI. There are several benefits that this provides, one of which is the modularization of code. Let’s take a look at how that is accomplished with Nx and how it leads teams to form reliable patterns.

Documentation on Nx can be found at nrwl.io/nx

A workspace created by Nx comes structured with an apps and a libs directory. New Angular apps can be created by running the ng g app <name> command and new libs by the ng g lib <name> command.

Say we are ready to start building our first app, what we call the customer portal, and we start by creating a new Angular app in the workspace. And let’s say we know we are going to use routing so we leverage the routing flag when we do so.

ng g app customer-portal --routing

Pretty straight forward. Then we add some navigation markup and a footer. We have plans for a “message of the day” in the nav and we are ready to implement the service logic for it.

So we start thinking about where in the app folder structure we are going to put that. Do we create a core directory since this will be core application functionality? Or do we create a shared directory because we will be using it across feature modules and “shared” implies the intent better? Oh, and if we do go with one of those, should we create a nested backend directory since we feel we will have more than one code file for that?

Let’s tell that planning voice in our head to zip it, we’ve got this!

Nx provides us a place to put it and a way to create it. Ready to build out that backend service code?

ng g lib backend-provider

Tip: the g is an alias for the generate command

Since it’s so easy to create a new Angular module lib in the workspace and there is an organizational pattern for where those libs go, we can remove the decision making and manual file creation from the equation and get to implementing the code.

And once we have made a home for this code, it’s easy to start adding to it:

ng g service backend -a=backend-provider

ng g class helpers -a=backend-provider

Tip: the -a is the alias for the app option that tells the schematic which Angular CLI app to add it to (and libs get created as app entries in the Angular CLI configuration)

And these libs give us an isolated domain of code. With the index.ts file for each lib we can control the public api of our modules. Export what we want to allow to be imported, leave out the rest.

Then we can use it in the app with the short path that is mapped for us by Nx:

Okay, the backend logic is implemented and being used to get that “message of the day” in our application. Now we’re ready to add our first feature module to display orders. And that voice in our head kicks in and starts again with the “should I create a features directory in the app and nest in there…”.

And we yell “silence, we are Nx’ing!”

Time for a new feature module? We’re on it. We can even set it up to be lazy loaded by passing the routing and lazy flags, and we can use the parentModule flag to add the route to the loadChildren in that customer-portal app:

ng g lib orders --routing --lazy --parentModule=apps/customer-portal/src/app/app.module.ts

From there we build out the components within the lib. Then we can add a router link in our customer-portal app so our users can get to it and we are off and running with our feature. And the nice thing about this is the additions to our app are minimal.

As we start to build out our workspace code this way we can start to see the advantages of putting our Angular application code within lib modules. If our application domain consists of a customer portal app to begin with and we add an admin app later on, our lib code is already organized in a spot outside of the customer portal app. So we don’t have to fuss with any file/folder restructuring and we can implement more rapidly.

When we add that admin app we can use the existing BackendProviderModule code in the same fashion that we did for the customer portal app.

When we need to refactor the BackendService and change a method name we can use our editor/IDE and it will update all usages in all apps/libs within our workspace. And if we commit and roll out that change and a critical code issue arises, we can rollback the commit and re-deploy with fairly minimal effort. The fact that we have an application domain mono repo makes these possible.

And reuse of that orders feature module across apps is simple too. But let’s say that the orders feature module is specific to the design of the customer portal app, but the order details component that it will have is something that can be used by both apps.

We can create an Angular module lib for that component (no need for routing on this one):

ng g lib order-details

ng g component order-details -a=order-details --export

Then we can import that module into the orders feature module and to the admin app. And if we need to make a change to it down the road, well, it’s the same story as those earlier changes to the BackendService. Low friction to implement and a clear and fast rollback process if needed.

Nx gives us some set patterns out of the box to organize our workspace code in a way that encourages modularity and it provides schematics to make the setup of those modules fast.

If you haven’t checked out Nx yet, head over to nrwl.io/nx to learn more about it and how to get started using it.

Justin Schwartzenberger provides training and guidance at Nrwl — Enterprise Angular Consulting.

If you liked this, give it a clap (or a few) so other people will see this here on Medium. Follow @schwarty to read more about Angular.

How Nx Helps to Encourage Teams to Modularize Code was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

Another year of AngularConnect came and went, and once again the level of content and community engagement was of the highest of quality. This year the entire Nrwl team was on location delivering workshops, talks and Q and A sessions. It was great to spend time with other amazing Angular community members, talk shop (and a lot of Nx) and watch some really solid and inspiring talks.

DYK: A group of Narwhals is called a “pod”

With the recent release of Angular Version 5 there was a lot of excitement around improved performance (both runtime and build time improvements), from service workers and pre-rendering to build optimizations within the Angular CLI. And of course, there were plenty of talks covering good practices and conventions.

Let’s do a quick recap of what the Nrwl team covered and point out some other picks.

Nrwl Talks

Jeff Cross provided encouragement for teams to start pre-rendering their Angular applications and guidance as to when and where to pre-render in his Pre-Rendering Strategies talk.

Ayşegül Yönet took us into the land of augmented and virtual reality in her Exciting World of WebVR talk, outlining both and examining how cameras and scenes are implemented.

Victor Savkin covered one of the most requested topics in the Angular community right now, illustrating the benefits of state and different strategies for implementation in his talk on State Management Patterns and Best Practices with NgRx.

Nrwl Workshops

We had two workshops that we ran at the start of the conference. Victor taught the one on Upgrading From AngularJS to Angular: An Incremental Approach. Jeff and I delivered the one on Building High Performance PWAs (Progressive Web Applications). Workshops are one of the services we provide for our clients and are something we are passionate about, so it was great to get the opportunity to deliver these to members of the community at AngularConnect. Both the upgrade and the PWA workshops are available as private workshops to Nrwl customers, so shoot us a note at hello@nrwl.io if you’d like to train your team!

Picks

Of course, the Nrwl team wasn’t the only ones providing content for the community during AngularConnect. All of the talks this year were amazing, and here are a few that I recommend you catch (or start out with):

• Purely Fast by Minko Gechev (a must watch for all Angular devs)
• Advanced Angular Concepts by Alex Rickabaugh
• Angular Elements by Rob Wormald
• Components are the New Thin Clients by Bonnie Brennan and Lukas Ruebbelke
• Day One Keynote by Jules Kremer and Igor Minar
• Manage Your Huge Codebase like a Boss by Jeff Whelpley

You can also check out all of the talks from both days on the AngularConnect YouTube channel.

AngularConnect 2017 and the Nrwl Pod was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re at it again, increasing our brain trust of Angular experts. In fact, increasing it by an order of magnitude with the announcement that Ayşegül Yönet will be joining Nrwl.

Now there’s a good chance you have seen Ayşegül present at many of the Angular conferences over the years, being that she actively shares her knowledge and experience with the community. And that knowledge and experience is vast, covering JavaScript and Web Development with a focus on Angular, WebVR and Data Visualization. Ayşegül is a Developer Expert at Google for Web Technologies and Angular and most recently worked as Senior Software Engineer for Autodesk Play, a 3D and VR authoring tool that is currently in beta.

Oh, and did we mention how much Ayşegül enjoys helping others? Beyond the conference talks, she has been graciously devoting time to making software skills attainable to traditionally underrepresented groups in the software industry. She prepared curriculums and taught workshops for Girl Develop It in San Francisco and has led Women Who Code meetups teaching JavaScript to various levels of students. She also mentored in the Last Mile Project in San Quentin Prison, Black Girls Code and the Computer Clubhouse organizations. Ayşegül even spent time in recent years helping to transform survivors of human trafficking into software professionals when she was CTO of AnnieCannons.

Our mission here at Nrwl is to help teams be successful on ambitious Angular projects and provide them with access to unparalleled expertise. We couldn’t be more proud to have Ayşegül on board to help us deliver on that mission. If you want to get to know Ayşegül, say hi on Twitter (@AysSomething), or check out some of her work:

1. Introduction to working with D3.js (SFHTML5)
2. Creating WebGL Components with Angular (AngularConnect)

Ayşegül Joins Nrwl was originally published in Nx Devtools on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve used ngrx, the reactive extensions library for Angular, you are probably familiar with the fact that the suite of @ngrx packages has a store-devtools scoped package that provides a way to debug your state store and dispatched actions. And if you have used the store-devtools you are probably familiar with the fact that you need to import the result of a call to StoreModule.instrument() in your root Angular NgModule after you import the store in order to wire up the store-devtools to your app.

Note: Examples are for @ngrx/store-devtools version 4.0.0 and above

This is great for dev time. But when it comes time to build for production we don’t want that instrumentation in the NgModule that we ship. Now we can solve this in a few different ways. We could have a different NgModule that we bootstrap for dev and for prod, or we could have a helper method that returns an array of imports based on some configuration.

But if we are using the Angular CLI there is an easy way to tackle this. We can make use of the built in environment support. A new project generated by the Angular CLI comes with 2 environment files out of the box, environment.prod.ts and environment.ts, that will be used when serving/building for prod and dev respectively.

environment.prod.ts

export const environment = {
  production: true,
}

environment.ts

export const environment = {
  production: false,
}

Use environment to conditionally wire up store devtools

We can add a property to that environment const that can be an array of imports that we want to add to our root Angular NgModule and leave that empty for the prod version:

environment.prod.ts

export const environment = {
  production: true,
  imports: []
}

And then put the instrumentation in the one for the dev version:

environment.ts

import { StoreDevtoolsModule } from '@ngrx/store-devtools';

export const environment = {
  production: false,
  imports: [
    StoreDevtoolsModule.instrument({maxAge:5})
  ]
}

Then we can hop over to our single root Angular NgModule for our application and use the environment.imports property we set up:

app.module.ts

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { StoreModule } from '@ngrx/store';
import { environment } from '../environments/environment';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    StoreModule.provideStore(/* reducer here */),
    // Note that you must instrument after importing StoreModule
    environment.imports
  ],
  bootstrap: [AppComponent]
})

export class AppModule { }

Because the Angular CLI handles swapping in the appropriate environment file pre-build we are able to leverage that environment const to get things included in our app. And not only things, but typed things like class types that we need to bring in via an import statement. This is super powerful for not only situations like this with the @ngrx/store-devtools, but for many other cases we may need to handle in our Angular applications.

One final note here, we can name that property whatever we want and even craft that environment const with a nested object structure. So there is nothing forcing us to name it imports. We could have called it ngrxImports or even nest it at rootImports.ngrx or something along those lines. We have total control over it so we can really leverage it to construct any type of solution we need!

Have a Lynda.com or LinkedIn Learning account?

Learn the essentials of Angular (version 2+) Watch Now
Learn Angular Reactive Forms Watch Now

Using ngrx store-devtools with the Angular CLI was originally published in Schwarty Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been to a ton of tech conferences over the past several years. Always in search of more personal knowledge, more growth and more exposure to new things. They can be a great source for these. Yet, they always feel like there is an aspect that is missing…that they could be more than what they are.

I think this stems from the fact that they are typically a one-way data flow. You attend a 2–3 day conference, jump from session to session receiving content, eat lunch/snacks with a herd, attend a mingle party, then head back home to your work cycle. You take notes on things to look into, code to try and new people to follow on Twitter. A good solid source of information and knowledge.

But, you know, you were this close to other devs for those two days. Other devs that are doing the same things you do, talking the same shop and imagining the same architectural solutions. But the condensed conference schedule and rapid pace of content delivery left you little to no time to network.

I sense that Ng-Cruise will be a different experience.

Tracy Lee | ladyleet on Twitter

Just in! @ngcruise shirts! #youcancruisewithus #ngcruise // @josepheames @gerardsans @EmberSherpa #angularjs

Now, I’ve never been to a conference on a cruise before. Hell, I’ve never even been on a cruise. But when this one was announced I felt I had to find a way onto that boat. It was going to be an opportunity to not only gain more Angular knowledge but to also engage in what could be a meeting of the minds type of moment.

I feel like it’s setting up to be more of a week long Angular collaboration and discussion with the addition of some focused sessions that will serve as conversation starters. Here are the 3 main points that I think Ng-Cruise has going for it that make it one of the more valuable returns on investment for your conference attendance plans of 2017:

• It spans five days
• The crowd will be lighter and the speakers will be available
• The setting is conducive to thought and theory discussion

The cruise sets sail on a Monday and returns on a Friday. The session content is dispersed over that time, with plenty of time available around it to interact and engage. This means that even with that 2 day warm up it may take you to start making new connections and feel comfortable interacting with other devs, you will have a whopping 3 more days to actually follow up on those new connections and get down to business discussing Angular.

This time span is going to be key. Other conferences leave you feeling rushed to squeeze everything in. On the cruise, time will be removed from that equation.

I feel like the attendee size of Ng-Cruise will be smaller than most conferences, making it easier to connect with not only other attendees but also with the speakers and organizers. Everyone will be hanging out together for those five days, not just bumping into one another in the hallway from 8–6 at the conference center. Connections will be easier to make, discussions will have ample time to flourish.

And then there’s the setting. The Caribbean. Sure, everyone has their own vision of paradise and the tropics may not be that. But, it does have a natural way of eliciting a sense of “chill out ’cause there ain’t nothin’ else goin’ on around here right now” that one really doesn’t get when they attend a conference in the city. I think that this setting is going to activate the brain and the soul. I feel that the discussions that go down during the cruise will generate ideas, approaches and theories that can impact the future of Angular and the future of the web.

So, I will be on that boat. In fact, I will be doing a talk on that boat. And while I am stoked to be able to present and to share that content…I am super geeked up to spend 5 days collaborating with fellow devs, immersing myself in Angular with no other distractions. I can’t wait to do more than just one-way stream content. I’ll be on that boat, with an open socket the whole time. I think it’ll be worth while for you to find your way on and connect!

ngcruise.com
May 29, 2017!
Tickets are still available!

A Ng-Cruise Value Proposal: Why You Should Be On That Boat was originally published in Schwarty Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Version Note:

This post is based on Angular version @2.0.0-rc.5 (with NgModule)

and the new Angular forms api package version 0.3.0

Language Note:

Examples are in TypeScript

Check out the live example of this code on Plunker

First things first, vendor and bootstrap it up

The old forms api has been deprecated with the intent of removing it in the future. To use the new api we need to bring in a new package.

The first difference we encounter with the new forms api is that there is a separate scoped package for forms: @angular/forms.

The old forms were included in the common scoped package. The move to a separate scoped package is probably a good thing, as it allows us to decide if we want to include the extra payload in the platform when we spin it up for our app. That being said, I can't recall working on an app that didn't have at least some type of HTML form markup. But choices are good, and being able to be explicit on what we choose to deliver in our apps with the platform is a win for us!

This means we need to grab the Angular forms scoped package and add @angular/forms to the list of ones we need to load. How to do this will depend on how you are handling your vendor scripts and module loading, but if you are using npm and systemjs it would look something like this:

package.json

{
  ...
  "dependencies": {
    ...
    "@angular/forms": "0.3.0",
    ...
  }
}

system-config.ts

...
const barrels: string[] = [  
  // Angular specific barrels.
  ...
  '@angular/forms',
  ...
];
...

Or, if you are using the latest webpack version of the angular-cli all you need to do is add it to the package.json file.

We also need to make use of the new modules available for forms. There are two, one for the template driven approach and one for the model driven approach (reactive):

• FormsModule (template)
• ReactiveFormsModule (model)

Since we are focusing on the model (reactive) approach we need to add that one to our module imports property. If you have an AppModule it would look something like this:

import { NgModule } from '@angular/core';  
import { BrowserModule } from '@angular/platform-browser';  
import { ReactiveFormsModule } from '@angular/forms';

import { AppComponent }  from './app.component';  
import { OrderFormComponent } from './order-form.component';

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

Change that component class model code

Next we need to make some modifications to the component classes where we were previously setting up our form representation using the newly deprecated ControlGroup. Since forms type stuff is now in its own barrel, we need to update the import statement to import from @angular/forms instead of @angular/common.

import { FormBuilder } from `@angular/forms';

All of the new forms api stuff is going to come from this barrel. Any additional things we need to bring in will come from this import statement. And speaking of those form things, the three essential building blocks for forms, Control, ControlGroup and ControlArray have been renamed.

• Control is now FormControl
• ControlGroup is now FormGroup
• ControlArray is now FormArray

So using the model driven approach to build out a form representation using a new form group and adding blocks to it would now look like:

import { Component } from '@angular/core';  
import { FormGroup, FormControl, FormArray } from '@angular/forms';

@Component({
  ...
})
export class OrderFormComponent {  
  orderForm: FormGroup;

constructor () {
    this.orderForm = new FormGroup({
      customerName: new FormControl(null),
      syrups: new FormGroup({
        vanilla: new FormControl(null),
        caramel: new FormControl(null),
        hazelnut: new FormControl(null)
      }),
      specialRequests: new FormArray([
        new FormControl(null)
      ])
    });
  }

onSubmitForm () {
    console.log(this.orderForm.value);
  }

onAddSpecialRequest () {
    this.orderForm.controls
      .specialRequests.push(new FormControl(null));
  }

onRemoveSpecialRequest (index) {
    this.orderForm.controls['specialRequests'].removeAt(index);
  }
}

But, if you were making use of the FormBuilder class the transition is even easier! That class remained mostly the same. So if you were using the methods on FormBuilder to craft your form representation then your changes are minimal:

import { Component } from '@angular/core';  
import { FormGroup, FormBuilder } from '@angular/forms';

@Component({
  ...
})
export class OrderFormComponent {  
  ...

constructor (private formBuilder: FormBuilder) {
    this.orderForm = formBuilder.group({
      customerName: formBuilder.control(null),
      syrups: formBuilder.group({
        vanilla: formBuilder.control(null),
        caramel: formBuilder.control(null),
        hazelnut: formBuilder.control(null)
      }),
      specialRequests: formBuilder.array([
        formBuilder.control(null)
      ])
    });
  }

...

onAddSpecialRequest () {
    this.orderForm.controls
      .specialRequests.push(this.formBuilder.control(null));
  }

...
}

Give that template new directives

Finally we need to update the component template markup to handle form directive changes.

Some of the key directive changes are as follows:

• Instead of ngFormModel use formGroup (on the <form> element)
• Instead of ngControl use formControlName (for named form controls)
• Instead of ngControlGroup use formGroupName (for named form groups)
• Instead of ngControlGroup use formArrayName (for named form arrays)

So our template HTML will now look like:

<form [formGroup]="orderForm" (ngSubmit)="onSubmitForm()">  
  <label for="name">Your Name</label>
  <input id="name" type="text" formControlName="customerName">
  <p>Add syrups</p>
  <ul formGroupName="syrups">
    <li>
      <input id="vanilla" type="checkbox" formControlName="vanilla">
      <label for="vanilla">vanilla</label>
    </li>
    <li>
      <input id="caramel" type="checkbox" formControlName="caramel">
      <label for="caramel">caramel</label>
    </li>
    <li>
      <input id="hazelnut" type="checkbox" formControlName="hazelnut">
      <label for="hazelnut">hazelnut</label>
    </li>
  </ul>
  <section>
    <p>Any special requests?</p>
    <ul formArrayName="specialRequests">
      <li *ngFor="let item of orderForm.controls.specialRequests.controls; let i = index">
        <input type="text" formControlName="{{i}}">
        <button type="button" title="Remove Request" 
          (click)="onRemoveSpecialRequest(i)">Remove</button>
      </li>
    </ul>
    <button type="button" (click)="onAddSpecialRequest()">
      Add a Request
    </button>
  </section>
  <button type="submit" [disabled]="!orderForm.valid">
    Place Order
  </button>
</form>

That it?

I'd say that covers the most common changes we have to make to migrate to the new forms api. There are a few more specific changes (for things like radio controls, working with validation in the template, etc.). Maybe those will get covered in an upcoming blog post. :)

Check out the live example of this code on Plunker

Migrating model driven forms to the new forms API in Angular 2 was originally published in Schwarty Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Version Note:

This post is based on Angular version @2.0.0-rc.4

Language Note:

Examples are in TypeScript

Why would we want to check for @Output binding?

Let’s say we are creating a confirmation toolbar component that will have a confirm and cancel button and we wanted those buttons to be optional for implementors of our component. Meaning that we want the ability to use the component in multiple ways:

<confirmation-toolbar  
  (confirm)="onConfirm()"
  (cancel)="onCancel()">
</confirmation-toolbar>

or

<confirmation-toolbar  
  (confirm)="onConfirm()">
</confirmation-toolbar>

or

<confirmation-toolbar  
  (cancel)="onCancel()">
</confirmation-toolbar>

And then in our confirmation toolbar component template we wanted to conditionally render the buttons depending on if the outputs were wired up:

<ul>  
  <li *ngIf="showConfirm">
    <button (click)="onConfirmClicked()">
      Confirm
    </button>
  </li>
  <li *ngIf="showCancel">
    <button (click)="onCancelClicked()">
      Cancel
    </button>
  </li>
</ul>

We would need to find a way to set the showConfirm and showCancel properties for our component. Now we could create corresponding @Input decorators for those, but then we would be putting it on the implementors of the component to add additional bindings to use the component.

How to work it

We can avoid all that noise by checking for @Output bindings in our component. Outputs are set up as EventEmitters, which are Observables. That means we can check to see if there are any subscribers and act accordingly.

Now just like @Input bindings, @Output bindings are not made available to the component until the ngOnInit lifecycle event or after.

So to check for @Output wire up in our component classes we can do the following:

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

@Component({
  selector: 'confirmation-toolbar',
  template: `
    <ul>
      <li *ngIf="showConfirm">
        <button (click)="onConfirmClicked()">
          Confirm
        </button>
      </li>
      <li *ngIf="showCancel">
        <button (click)="onCancelClicked()">
          Cancel
        </button>
      </li>
    </ul>
  `
})
export class ConfirmationToolbarComponent implements OnInit {  
  @Output() confirm = new EventEmitter();
  @Output() cancel = new EventEmitter();
  showConfirm = false;
  showCancel = false;

ngOnInit () {
    this.showConfirm = this.confirm.observers.length > 0;
    this.showCancel = this.cancel.observers.length > 0;
  }

onConfirmClicked () {
    this.confirm.emit(null);
  }

onCancelClicked () {
    this.cancel.emit(null);
  }
}

And with that, we have made use of checking the @Output wire up without needing some corresponding @Input used for configuration, keeping the usage of the component minimal and elegant!

Checking for Angular 2 @output wire up was originally published in Schwarty Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Angular 2.0.0-rc.2
https://github.com/angular/angular/blob/master/CHANGELOG.md

Here are some of the fixes I’m excited to see:

• forms: radio buttons with different names should not share state (6dc88f5), closes #7051
  
  Before this fix we weren’t able to have multiple radio button groups in a single form because the values of all radio inputs would get reset when one was selected.
• http: respect custom Content-Type header in XHRConnection (#9131) (537e99b), closes #9130
  
  Always good to have the correct content type headers going across the wire in our API calls!
• router: opening links in new tab (fa2ce81), closes #5908 #6806 #7749 #8806 #8821
  
  Before this fix a ctrl+click or a middle mouse click would not open up a new tab in a browser. A good fix. There are some fundamental actions users are accustom to doing in the browser. Disrupting those can lead to confusion an angst about your application.

And here are some of the features I found interesting:

• animations: Any and every bit of them! Been anxiously awaiting these.
  
  Check out the Animations documentation in the Developer Guide section of the angular.io website.
• common: DatePipe supports ISO string (abc266f), closes #7794
  
  One of our engineers, @rich_code, actually implemented this in our code base a while back. Now he gets to do the best type of code refactoring there is…code deletion!
• forms: compose validator fns automatically if arrays (61960c5)
  
  So no more need to use Validators.compose() to chain together validators when using the FormBuilder.control method or creating a new FormControl. I dug through the source code and it doesn't appear that this is also supported for validator composition for FormGroup or FormArray objects. Not sure if this is intended to be left out or if we will get that in the future...
• ViewEncapsulation: default ViewEncapsulation to configurable (f93512b), closes #7883
  
  Now we have a way to set the default view encapsulation mode from the top down for all components in our app if we don’t want to roll with the ViewEncapsuation.Emulated mode that comes out of the box.

Lots of fixes/features in RC2. Add these to the API changes that are in the works for forms and the router and we find ourselves working on top of “shifting sand” (as my buddy @maindg likes to say). And here I thought the RCs would bring stability as we closed in on the final release. Oh well, such is the life in the rapidly changing domain of web development!

Some cool things that dropped in Angular 2 RC2 was originally published in Schwarty Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.