Angular 4 Directives Overview


If you missed our last Angular post please check it out here.

Not much has changed in terms of directives for Angular 4 so this post will be a general directive overview mentioning Angular 4 directive changes where appropriate.

Under the hood, a directive in Angular is just a plain JavaScript class that is decorated with the @directive decorator. In Angular, we have 3 different types of directives.

These are:

  • Component Directives
  • Structural Directives
  • Attribute Directives

An attribute directive tends to change the look and behavior of an element. Whereas a structural directive will manipulate the DOM and add or remove elements depending on what action the structural directives apply.

A Component Directive uses the shadow DOM to create encapsulated visual behavior that is typically used to create UI widgets.

Some directives go beyond the scope of this post but be sure to check out this awesome Angular + Typescript book by Yakov Fain for additional information.

Attribute Directives

We will start with attribute directives and how this interacts with our DOM and data.

We can also differentiate a component from a directive using this handy table provided for here.

You can create your own attribute directives or you can use Angular’s built in directives.


A fairly simple illustration of a basic attribute directive, ngClass is added into our component element and its value is given as a class.

As you can see, we can use the ngClass attribute to assign a class based on styles that we had specified in our styles array.


In short, ngFor is a directive that outputs an array element, iterating through each element inside it.

For multiple classes, we can create an array and put those classes inside it to apply to our iterative list. We can then combine this with the aforementioned *ngFor.

The let key is part of the Angular template syntax. It creates a local variable that can be referenced anywhere in that specific template. let also creates the index i and keeps it as a reference to the current whiskey. All this is done under the hood of this directive.

What if we wanted to style the first and last item in our ngFor directive? This is actually made relatively easy by using let again to assign the first items to variable first and last to variable last.

To be as efficient as possible, ngFor will attempt to not remove and recreate these DOM elements and instead to reuse and recycle when possible. This helps with performance and prevents significant slowdown in our DOM.


ngSwitch provides us with a structural directive similar to a switch loops in JavaScript and our other Object Oriented language counterparts.

Here is a simple example that combines input button events with ourSwitchCase loop. Based on the number that value returns which is changed depending on which button is clicked, one of the divs with the *ngSwitchCase will be displayed.


NgIf adds or removes an element or elements from a sub tree based on the condition specified.

If the expression assigned to ngIf evaluates to a falsy value then the element is removed from the DOM, otherwise a clone of the element is reinserted into the DOM.

This would be similar to how the display: none property behaves in CSS.

The NgModel directive allows us to provide two way data binding to our HTML element. Whatever we type in the input field will reflect in our name element. In our sample Plunker we had to import and declare our FormsModule in order for this to work. The name attribute should also have the same value as our ngModel.

Creating our own Attribute Directive

I will be going over the fantastic introduction to creating our own directives from Angular University.

We can also create our own custom directives in Angular. In this case, this directive can be applied to any HTML element on the page and will hide this element when it is clicked.

Firstly, we need to import our Angular Directives from Angular core library into your component file.

We then need to then initialise our directive meta data decorator with the selector property of our choice. In this example its HideElement.

We then want specify the CSS classes that we want to use for the fade out transition.

And we also need an action to occur when the element is clicked so we will create a function called toggle.

We than want to use a click event that will trigger the function “Toggle” that will add or remove this fade out css class but we will not be using Angular’s (click) event so how exactly will we accomplish this?

Well, we will use the Angular directive HostListener from Angular Core. Using a Host Listener, Angular will invoke the decorated method (in this case toggle) when the our html element emits the event (when clicked).

In order to access and change properties of the Host Element we must use the HostBinding Decorator. This will check the host binding properties once a change is detected.

For a more detailed explanation of creating your own Angular directives check out this tutorial from Rangle.

If this helped you out be sure to check out our resources page for more recommended reading material on Angular.

Angular 4 Released – Why a 4th version?


Another version of Angular?

Angular 4 was fully released on 17th March. In this post, I hope to address any confusion or niggling worries regarding how this affects current Angular projects and how exactly these changes could benefit your next project.

Here are the official changes.

If you are baffled as why there is already a 4th version of Angular I covered semantic versioning in a previous post here.

Flat ES Modules

Most of the changes in Angular 4 comprise of performance improvements for the framework. Perhaps the most significant one is the introduction of Flat ES Modules that treeshake your application for you.

During the ng-build process, the compiler deems certain code unnecessary  because it has no usages. The compiler then removes this code in order to reduce file size and to make the application more lightweight.

Backwards compatibility

Since the scheduled announcement of Angular 4, the Angular team have been reassuring everyone that this change will not affect the way your current applications run. When upgrading your application to Angular 4, there will be a seamless transition for the most part.

This seems to be the case as I have only experienced one issue and this is with the AngularFireBase package which the developers for it has stated that they haven’t made it fully compatible with it yet .

If you have experienced this issue you can also follow this excellent tutorial by Coursetro to get Firebase working with Angular 4.

This tutorial is very insightful and solved my Firebase issue.

You may also experience a similar situation with some of your libraries and packages but the core features from Angular 2 seem to function just fine.


The way animations are imported has been cleaned up for Angular 4. Instead of importing the various types of animations such as state, keyframes, trigger etc,

 You now specify an import that contains tools and assets for animations in one package. This isn’t much but it does feel less cumbersome to set up an animation for a component.

The browser animations modules should also be added to your app.module.ts file for this to function properly.

Check how to do that here


 When using the ngIf directive we never had the ability to add an else clause to the statement. This has been addressed in Angular 4, we can use the element <ng-template> to specify the name of our else condition by specifying it after the # symbol.

Please note that <template> is now deprecated and is replaced by <ng-template> 

Email Validation

Perhaps one of the handiest changes, an email validation directive was added to input elements. This saves us from having to manually create regular expressions to validate a users email address.

Simply add this to an input field element just like you would for the required directive and our email input field will automatically have validation.

This is actually quite a useful feature as it applies an email validating regular expression pattern to our element using just one keyword.

You can, of course still create your own custom expressions for validating emails and other input fields.

I hope this post has reassured you that this new version of Angular isn’t as significant as the version increment might make it sound. Some nice changes here lets us utilise some conditions and statements a bit more as well as cleaning up some of the imports.

Be sure to check our resources page for more Angular, TypeScript and JavaScript reading material.

Sass in Angular


in Angular

If you missed our last Angular post please check it out here.

So SASS (Syntactically Awesome Style Sheets) are an already  well established and renown pre-processor for CSS. It allows the developer to create modular CSS where classes can nested inside each other. To summarize is benefits, it allows you to write less and customize more.

It also has a whole host of features including variables for colors, urls, fonts etc, while also having, mixins, extending/inheritence and operators.

You will write all your SASS code in a .scss extension file. The compiler will then output this into a css file based on the nested structure of your classes.

Having already seen the structure of Angular’s component based architecture you might wonder what exactly is the best way to implement SASS to an existing project.

And although I could show some of Sass’s great features, I will concentrate on whats important in the context of an Angular application.

You can check a great SASS intro here.

And here is a great book resource for learning Sass and Compass if you wanted to really hone your Sass skills.

Sass Structure

There are many different application you can use to get going with Sass you can pick your own preference here.

I personally use Koala its a nice GUI 3rd part application that looks for a scss file in a specified file directory and then compiles it to a css file.

Koala Sass
Koala Sass

Once you open Koala navigate to your desired project directory.

When you find the .scss file you want to turn into css, simply press compile once you find it in the directory. Koala will also has real-time compilation and will listen for the file changes in this folder.

It is also cross platform so it will run on Windows, Mac and Linux.

An ideal Sass structure would have folder called partials. Each file in this folder would have many different scss files that would be prefixed with an underscore.

Each file would adhere to a specific part of a website for example home, about, navigation.


All of these partials are then imported in the main .scss file ( usually called global.scss or style.scss). This one file is then compiled into a css file that is used for the whole project.

Importing partials in our style.scss file

This is deemed as one of the most efficient ways to manage the styles of your project as all your css is compiled into the one file. However, in an Angular project there are two different approaches.

Generate Sass

The easiest way to get going with SASS in an Angular project is to create a project in your command line with the styles set to scss.

This will scaffold a project for you that will contain an app.component.scss file that will automatically be compiled for you without the use of a 3rd party application like Koala.

Manual setup

If you wanted to setup up your own styling structure once you create an Angular project through the CLI you should note that
each component generated has its own css file specific for that component. So if you create a Sass file with the component’s naming convention eg home.component.scss Koala will detect this and will compile it to home.component.css.

So instead of having a partial import system we just have individual sass files that are unique to the component.

I’m sure there is an argument for using both methods but this is the method I personally use. It makes the most sense to me as it aligns with the way an Angular project is typically structured and goes hand in hand with using the Angular CLI.

Form Validation

To give a practical example of using Sass in Angular I’ll focus on styles for form validation.

For validating forms in Angular we can use preexisting classes that correspond to the state of on input field or select box.

These classes are:

  • ng-pristine
  • ng-invalid
  • ng-touched
  • ng-dirty
  • ng-valid
  • ng-untouched

These classes are self explanatory for the most part, ng-touched is applied when the input field is written in, ng-dirty is applied when

The ng-dirty classes indicates when the form has been modified by the user. The opposite of this is the ng-pristine class which is applied as long as the form has not been modified by the user.

In Sass we can add appropriate styles to these classes to indicate when an input field is empty, invalid, not yet entered etc;

Here is an example of adding relevant border colors to these input states.

Form with styling states
Form with styling states


Although styling might seem quite arbitrary in context of learning Angular. Sass allows you to be more efficient and modular when it comes to creating a beautiful Angular application. Its a very useful tool to use in combination with Angular and fits in nicely to the structure of a component.

If you are looking for anymore resources to learn Angular be sure to check our resource page here.

Angular 2 Component Data Binding with Sample Whiskey Application


In our previous Angular 2 posts, we concentrated on the setup and structure of our application. You can find that here.

If you are already familiar with component data binding you can always check out latest Angular 2 practices in ngBook.

Now, we are moving onto something a little more visually apparent using some sample Whiskey data.

Our site looks something like this:


Here is our mock whiskey catalog used as the data for displaying the 3 different whiskeys.



We want to display these whiskeys from our mock data in our whiskey-list.component.



This component contains a class that initializes our imported Whiskey and WHISKEY_CAT classes.

From here, we want to be able to click on one of those whiskeys displayed to focus on it and display it in bigger dimension right above it.

We then want the clicked whiskey to appear inside a different div in a completely different component (whiskey.details.component).

This would be considered common practice in a typical website displaying a product catalog. They would have a style transition that highlighted one products chosen in a list by the user.

When understood, this should give you a good feel of how data flows down through components in an application. It will also show you how to utilize directives, while also showing you how the process behind how an event is handled in Angular 2.

Exposing selected data.

Our variable selectedWhiskey is assigned to a TypeScript export of a our Whiskey object. Just from being declared inside the WhiskeyListComponent class, selectedWhiskey is already exposed and accessible from our whiskey.list.component html file. We can bind our selected whiskey properties to our UI. In this case image src, whiskey name and description.

But how will this component get access to the information from the clicked on whiskey? We need our application to take the properties of the item clicked on and to then pass it to our whiskey.details.component.

The @Input() decorator was added to our whiskey-details.component . @Input allows us to define an input for a given component. So our selected whiskey value can be put in as an data attribute and the value of it flows down to our component.

This is an attribute binding that passes down the value of the selected whiskey

We need to create a function to set our selected whiskey.


But what else is going on here? Well the object passed in our setSelectedWhiskey click method is referring to the singular whiskey at the current index using our *ngFor looping directive.

So when our *ngFor directive iterates through whiskeys in our whiskeyCat, whiskey is always referring to the current whiskey. When clicked the current whiskey is passed down to our whiskey-list-details.component.

We should now be able to see the selected whiskey in a different div from a our whiskey-list-details.component.

This is a very handy way of sharing a specific piece of data to another component. This is just one practical use of data sharing between components.

There are many other uses that I won’t cover here but make sure you check our resources page for any relevant reading material on Angular 2.

So to reflect back, the @Input decorator tells Angular to treat selectedWhiskey as an input binding.


This means that it has access to event data. Once this is bound to our nested component, our nested component can now receive event data for example in this case its the selected whiskey clicked.

I won’t go too far into how decorators work in general. You can get pretty far not understanding what they actually are doing past the layer of abstraction that Angular provides us.

In the case of selected Whiskey we have specified it as an input binding.

There are many different types of decorators and you should really look at Todd Motto’s post to further unmask some of their mysteries.

Overall, this is a simple example of how you would use Angular 2’s data flow decorators to control the flow of data to a nested component.

In essence, they are just a function that provides itself with instructions on what type of information it should expose it’s targeted variable.


This is a very basic version of this Angular 2 Whiskey application there isn’t a whole lot functionality here apart from the displaying the selected whiskey.

However, I plan to incrementally add bits functionality as I learn more about Angular 2 and its various techniques. I’m finding it be a very solid framework to be working with and something that I’m trying to specializing in.

The combination of TypeScript decorators and Angular directives really opens up the possibilities of your UI interacting with your data in different ways for creating feature rich applications.

Early GIT version

Here is very an early draft of this sample application for reference.

Angular 2 Upcoming Features and SemVer


Whats New?

January has been a fairly quiet month regarding big notable Angular news. This is partly because a lot of revelations were revealed in November and December, highlighting the version changes of Angular 3, and 4. Or more sensibly now called just plain Angular.

MIT License

As of January 11th, Angular 2 switched back to an MIT open source license framework. While this has no bearing on any technical aspect of Angular, it does reassure developers how they can extend and modify Angular without any worries.

The Google Angular team actually prefers the Apache 2 license for scaffolding the legality of an Angular 2 project, but it was understood that the wider community has a better understanding of the MIT license.

While hardly a major cause for celebration, this is still a nice example of Angular reacting to community feedback. In short, a better recognized certification says you can happily publish your Angular applications without restrictions.

You can see this license here.

Material IO

The Angular Material 2 beta has started, using the Angular CLI to install it. The beta provides high quality UI components using Angular 2 and TypeScript. These UI components are customizable within the Material Design specification. They also do not put a strain on the application by having low performance costs.

While Material Design definitely isn’t suited for everyone’s taste, its certainly nice to have the option as its neat, clean and has high usability Although, I think it limits creativity for UI designs to some extent.

In the context of an Angular 2 applications, functional design is incredibly important. If you value quick functional design over a design that has more visual fluidity and better creative processes, then you can’t go to far wrong implementing material design into it.

Heres some nice examples from the referenced sample application from the git.

material-design-sample light
material-design-loading bars
material-design-loading bars


Towards the end of December, Angular 2.4.0 became available. This was a stability injection that coincided with Angular’s new semantic versioning.

In case you missed this check it out here.

A major release cycle schedule was announced, pinpointing the exact times where Angular are planning its forthcoming major releases.

Also you can check out a video detailing Angular 4 and version plans here.

A deprecation policy was also introduced so that any major releases that contain breaking changes to the API will automatically be notified well ahead of time.

If one had to guess of what a deprecation issue would look in the next major versions, then we could probably look back to when packages such as uibootstrap or ng-dialog from Angular 1 etc weren’t fully compatible with Angular 2. Similar forthcoming breakages might be comparable to these kind of previous issues.

It will be interesting to see how this effects the Angular job market, as there is plenty of Angular 1.x roles still available and probably will be for a very long time.  In terms of maintaining projects and applications, many will still be developing on that version.

However,  more Angular 2 positions are being listed everyday so it is likely that some previous features might be deprecated. This might accelerate the process of some companies adapting some of the latter versions.

One of our goals at JSdiaries is to bring Angular 2 developers together and provide them with valuable information and news from the JavaScript world.

As we grow, we hope to implement a job board that will have listings of some open Angular positions. Hopefully, this will connect potential employers with some of the developers from the JSdiaries community.

Angular 2 – Module and Route Structures


In simple terms, modules are the basic building blocks of our Angular 2 application, whereas routes provide us with paths to point to specific parts of our application. These are both core to an Angular 2 application. It is important to create both with good, clean separation of concerns in mind.


A standard application has different layers of components (or functionality) that the user can navigate to. This is where our routes come into play. These routes provide url paths to direct us to these different parts of the apps functionality.

Say we are creating an application that displays a list whiskeys. When the user clicks on a whiskey in the list, we want to display a page showing the detailed information about that whiskey. That’s just one piece of the application.

How about the user wants to search for a whiskey he has previously purchased? That’s another piece of similar functionality. Because these components are closely associated with each other in terms of purpose,  it makes sense to create relevant routes in the same folder.

As a project of reference, I will be referring to my Whiskey shop application for example of the structure of its project directory. I hope to fully publish this within the next few weeks.

So for a basic application, we can just declare all these routes in our app.module.ts file (Our entry point for the application) . But what about more expansive applications with many different components to be directed to? We can then create a routing TypeScript file specific to a folder of similar components. This creates a routing system that is compartmentalized rather than declared in the one place.

For instance, say we have an actions folder containing a login, register and profile component. We can then create an  actions.routing.ts file which contains the relevant route paths.

Actions Folder Example
Action Folder Declared Roots
Actions Routing File Declared Roots

From here, we can export this routing file and include it in our App modules component.

For more detailed information on the Angular 2 router check it out here.


A module provides meta data for a particular section of your application. It is then exported and can be accessed by another component by importing it. This imports/exports system is made possible through TypeScript syntax.

The process of importing classes/components into other classes and components closely resembles something from Object Oriented languages Java, C# etc.

./ in an angular import means current directory. This is obviously something you’d be aware of while making an Angular 2 application but its nice to be reminded due to the amount of time you can waste trying to get the correct directory path.
By declaring similar components in the same module you get to have a cleaner components and separated logic. You can declare all imports that are relevant to those modules.


So as you can see we have consolidated some of our modules into groups. Our LayoutModule and ActionsModule contains more than one referenced component.

For example our LayoutModule contains all of the following modules from our layout folder. Just to note the layout folder is just name I gave the folder in this instance and is not an Angular 2 specific structure recommendation.

Layout Folder Structure
Layout Folder Structure

The components from this layout folder (FooterComponent, HeaderComponent, NavigationComponent) were declared and exported here:

This enables our app.module.ts file to be significantly cleaner because we don’t have to declare each individual component that we have in our application.

Another advantage of these components segmented by similar functionality  is the ability to remove one from declarations if the developer wants to stop the use of certain piece of that particular functionality.

So just to reiterate we should assort all our module providers routes in RouterModule Object specific to that group.

We also no longer have to declare our routes here as we have our routes declared in our specific group components.

It is also regarded as good practice to separate your routes specific to what folders they are grouped in.

This allows you to have an Angular 2 application’s app.module file to not be overloaded with path references linking to different areas of your application. Instead, these routes will be located in a location thats relevant to the components it links to.

Our application is now nearly completely compartmentalized through the grouping of our modules and routes. Different types of functionality can now be targeted and contained within these groups.


I highly recommend this YouTube Angular Series by Lyrad Digital. The series provides some very useful information step by step, with the early videos in the series covering the best practices of routes and multiple modules.

You can also check my resources page here:

Angular 2 – The future of component based JavaScript Frameworks


What is Angular 2?

Angular 2 is the latest in the growing trend of JavaScript frameworks for creating web applications. It is not an MVC framework but rather a component based framework that has been completely re hauled and revived from Angular 1. The key differences between Angular 1 and 2 are that Angular 2 is built with mobile support, heavy use of TypeScript and the $scope to glue the view and controller has now been totally removed.

The fact that Angular 2 is mobile-orientated allows Truly Native Mobile Apps to be built with technologies usch as NativeScript or Ionic.

Am I ready to learn it?

If you are eager to learn Angular 2 and have no previous experience with Angular 1 you are in luck! These frameworks differ greatly from each other so don’t be afraid to delve straight into it. There are, of course some prerequisite knowledge that I would recommend to have.


In order to create a practical application that would simulate one already in production, it is recommended to use a database instead of simulating data. You could use Node.js and MongoDB to accomplish this. By having a backend set up and ready to interact with you are enabling yourself to work on a application that is “true to life” or so to speak.

This isn’t totally necessary if you want to play around with Angular and create an application quickly. However, you will have to do this at some point as the scope of your application gets more complex so its best to establish what you will use at the beginning.


A good grasp of JavaScript fundamentals will obviously put you in a good position for starting an Angular 2 application. However, the real benefit of this is for the inevitable debugging sessions you will have to endure. In this case, knowing Vanilla JavaScript is extremely beneficial as the ability to trace and understand errors from the compiled TypeScript will allow you to solve problems much quicker.

I can’t recommend this JavaScript course any more:

Wes Bos builds 30 practical JavaScript things and with some latest ES6 practices. All these small applications built contain no additional frameworks or boiler plate code and they really indicate how much you can do without other libraries. Extremely useful down the line when debugging/implementing an Angular 2 application.


And who can forgot the beautiful TypeScript. Ah, bread and butter of an Angular 2 application. TypeScript is a superset of JavaScript and it allows you to write JavaScript in a class based or object oriented style. This code is then compiled to clean JavaScript output. This is why its important to know pure JS for debugging. Its hard to find a better introduction to TypeScript than this video by .NET Interview Preparation Videos

Similarly, if you were trying to find a more cohesive way to learn the basics of Angular 2 + TypeScript I would highly recommend checking this Angular 2 development book below by Yakov Fain.

You can also find Yakov’s blog here:

You can checkout his training workshop here:

MV* or Modular Architecture

If you have ever used a Modal-View-Controller or MV* system, then you will know the importance of separation of concerns . This basically means dividing your application’s business logic, data and visual markup into separate sections that are easy to navigate .  Angular 2 uses a component based architecture that would be comparable but not identical to this.

To create an Angular 2 component in your project directory run the command


You will now have folder called my-new-component or whatever name you specified.  

Generating New Angular 2 Component
Generating New Angular 2 Component

This folder containers the relevant typescript and styles files created in this folder. In order for us to link this new component into our app component we have to specify it in app.module.ts directives array in the @Component meta-data. We then need to put the selector of our new components into the first-apps template property in its meta data section.

App-Module Component Declaration
App-Module Component Declaration

Getting Started

Angular CLI

In order to use npm to download the Angular CLI package and install it globally on our local machine we need to install the latest version of Node.js .

You can install from their download page here.

Once installed we can type the command:

Installing this CLI allows scaffolding for our Angular 2 applications. You can see all the various scaffolding items you can create for the CLI here.

Using the command:

Your project will be created in your specified directory. It takes all configuration and prerequisite steps such as:

  • Creating our app files
  • Configuring TypeScript and Typings
  • Adding script tags for
    • Angular2
    • Rx.js
    • System.js
  • Configuring System.js
  • Creating our Angular 2 component

Using the command line interface we must also install TypeScript globally on our local machine.

We will use typescript as a subset of JavaScript in order to the define the type of member variables and class method parameters used in our application. TypeScript supports new ECMAScript standards and compiles them to older targets of your choosing (such as ES3 or ES5 . This means that you can use features of ES2015 and forthcoming  versions with our Angular 2 application.

Other Versions?

So something to really try and get your head around are these will new Angular versions.  Google has stated that all forthcoming  Angular versions will be backwards compatible with Angular 2. Will Angular 2 be irrelevant in 6 months because of forthcoming versions in Angular 3 and 4? Well this depends. Angular 4 is the next major version released, not 3. The difference between Angular 2 and 3 will not be another full core change. These new versions will now be subsequently released twice a year. So with this backwards compatibility in theory, no version will be get left deprecated from Angular 2 but we’ll just have to see how this pans out.

So while these incremented versions do cause some differences in the architecture itself. What are we supposed to call Angular as its base name if it keeps getting incremented every 6 months? This is an ongoing discussion in r/Angular2

The future of /r/Angular2 — With Angular 4 now in beta and the adoption of semver, let’s revisit the unpopular decision to name this project Angular to begin with and where to locate our future reddit home. from Angular2


Angular Talks Meetup #6

Written by Gareth Dunne @jsdiaries

The Foundry, Google

Angular Meetup is the first conference to be featured on this blog. It was a 2 hr Angular conference with four speakers. They discussed different features of Angular 2, highlighting the advancements from Angular 1, as well as some of its architectural patterns.

Angular Talks Meetup #6

Thursday, Nov 17, 2016, 6:15 PM

The Foundry, Google
Barrow St Dublin, IE

271 ng-members Went

On the 17th of November, we would like to welcome you back at the Foundry in Google Headquarters for another great lineup of Angular talks.Join us for the latest Angular 2 news, tips and tricks from fellow industry experts, plenty of networking opportunities, plus the chance to win a free ticket for dotJS Conference, or a license for a JetBrains p…

Check out this Meetup →

Introduction to Angular 2
Simona Cotin – Senior Software Engineer & Co-Organizer of AngularJS Dublin @simona_cotin

Simona, an ambassador of the group Women Who Code, she discussed the components of Angular 2. She focused on Input and Output decorators, used for emitting signals in Angular 2 applications to detect changes. Because Angular 2 is a reactive framework, change detection is of huge importance.

The flow of data from top to bottom is another important characteristic of Angular 2. What I found most interesting is that an Angular 2 application will have a faster initial render because it is compiled at run time. Another word for this is “ahead-of time” compilation.

She also mentioned other helpful tools such as the Angular CLI. This helps to scaffold the application by generating components, directives etc. I am currently using this CLI in my Whiskey shop application. I find it incredibly useful that I can generate 3 or 4 files in one component from just one command “ng generate component_name”.

There are many other cool commands that help with boiler plating some other aspects of the application.
To finish, she recommended using Protractor for end-to-end testing in Angular 2. You can find that here. 

MVC is dead!
Fabrizio Fortunato – Lead Frontend Developer at Ryanair@izifortune

Fabrizo addressed the differences in default two-way data-binding in Angular 1 and Angular 2.

It is inefficient to have constant callbacks from parent to child elements if no data needs to be reciprocated from parent to child elements. Instead, the child node can update a function that invokes methods based on the changed information.

The value of this is evident because the constant unnecessary callbacks in Angular 1 to parent elements hinder the application. This is because a one child element can be linked to multiple, ambiguous parent elements. Fabrizio also talked about how MVC is now on its way out regarding new emerging frameworks such as Angular 2.

The windowing technique  
Danilo Castro – Software Engineer at Rapid7– @daniloster

Danilo’s talk was my personal favorite, maybe because I found the content most relatable.

He focused on a window technique where the window only displays data that is inside the constrains of a specified container size. He put the question to the audience – why would you bother rendering data in a window that is not being viewed?

I found this technique intriguing and seems like such a simple way to improve performance in an Angular 2 application. The view gets restricted and recycled. Danielo showed the math formula required to calculate the limited windows that are displaying this changing information. These calculations are invoked on a scroll event in Angular 2.
See his presentation on the windowing technique here.

Building Angular 2 (from MB’s to KB’s)

Thomas Horvath – Lead Frontend Developer at Xplosion Media –@criticalpix

Thomas presented how webpack can compile our Angular 2 files and compress them into a size suitable for a production environment. In his example, his output for the Angular 2 application was reduced from 2.5mb (an unsuitable size for a typical production environment) to 150kb.

This is a significant change in the webpack module file. Possibly the most important aspect of this was webpack taking our common JavaScript code and putting it in commonJS.

This compression alone led to a significant reduction in the size of the application to be loaded in the network. Webpack also treeshakes your application to compress the size of the output. Thomas said that this is not fully functional for production environments. However when it does work, the reduction in size can reach as low as 150kb.

This event had the highest attendance of all the previous Dublin Angular events so far. I found it was very insightful to have four different perspectives on this new framework that is only really two months old.

While some of the techniques were more advanced than my current knowledge, I can see the advantages of implementing them in my Whiskey shop application, currently under development. I will be sure to feature this Whiskey shop on here soon, with the end-goal of making it open source.  Please feel free to be critical of anything I post, factually or technically. It will help getting this blog off the ground  long-term.

So feel free to  level your criticisms at me akin to folks on webdev subreddit. 🙂