Friday, February 5, 2016

Angular 1.5.0 - ennoblement-facilitation has been released!

We have just released the next major version of Angular 1, which has been in development since May last year.
The primary theme for this release was to improve the upgrade path to Angular 2.
In this release we have added features that will enable developers to write Angular 1 applications that are closer to the way that applications are structured in Angular 2.

New Features

The big feature changes to Angular 1 in this release are mostly focused around supporting Angular applications that are built from Components. But there are a number of other features that will improve your development experience.

Component-based applications

Defining component directives

While creating components in Angular has been the primary way of structuring applications for a long time, we now made it possible for you to easily define a component directive with the module.component() helper method. For example a simple component only needs to provide a template, some bindings and a controller. For the remaining directive options we set sensible defaults.

myModule.component('myComponent', {
  template: '<h1>Hello {{ $ctrl.getFullName() }}</h1>',
  bindings: { firstName: '<', lastName: '<' },
  controller: function() {
    this.getFullName = function() {
      return this.firstName + ' ' + this.lastName;
    };
  }
});
<my-component first-name="'Alan'" last-name="'Rickman'"></my-component>
Read the new component guide to find out more about this.

Lifecycle hooks

If your directive/component controller has a method called $onInit() the compiler will now call it after the component has been initialized and all its bindings have been set up. This provides a clear place to put the initialization code for your components and is similar to the ngOnInit() lifecycle hook of Angular 2.

Binding to required directives

As well as the string and array forms, you can now specify an object for the require property of directives and components. If used with bindToController, the compiler will also automatically bind these required directive controllers to your controller.
These bindings (including those of sibling directives) are guaranteed to be in place by the time the $onInit() hook is called.

Multi-slot transclusion

You can now specify that different parts of the transcluded content is rendered at different slots in the template. See the 1.5.0-beta.2 release announcement for a detailed explanation of this feature.

Default transclusion content

ngTransclude no longer overwrites its contents if there is no content to fill it. This means that you can provide default content to be shown if the user of your directive has not provided any content to be transcluded.

One-way bindings

You can now define a directive/component binding using the '<' character to indicate that the binding is one-way. In this case the compiler will only set up a watch on the outer expression and not on the internal property. This means that changes to the value of a binding inside the component will not be propagated to the outside. See the $compile API docs for more information.

Improved support for ES6 classes

We now support instantiation of native ES6 classes in the $injector and as a controller. Due to variable browser support this is a volatile feature, so be careful to test on your target browsers before going to production.

ngAnimateSwap Directive

We have introduced the new ngAnimateSwap directive, which allows you to animate a collection of DOM changes together as a single container swap. See the 1.5.0-beta.2 release announcement for a detailed explanation of this feature.

ngResource

We now have proper support for cancellable actions on resources, which means a $cancelRequest() method will be available on the return value of the request method.

ngRoute

Any promises resolved as part of a route's resolve property are now added to the scope as a $resolve property, which saves you having to inject them into the route controller.

Other Improvements

There are loads of other improvements, which you can find in the Angular changelog. Here are a few highlights:
  • You can now access the locals object that was passed to a call to $parse from inside the parsed expression, via a $locals variable.
  • You can provide $http configuration options of the $templateRequest service.
  • You can create your own custom XHR objects for the $http via the $xhrFactory service.
  • ngModel now provides ng-empty and ng-not-empty CSS classes.
  • The ngAria module is now more precise with handling of ARIA attributes and tabindex for custom controls.
  • Some new helpers are available on ngMock to ease testing:

Security Improvements

There have been a number of people who have contributed to the project over the last few releases by analyzing and identifying security issues in the Angular code base, which we have then fixed. We really appreciate the work that these people do. In particular we would like to thank Mario Heiderich, Gareth Heyes and Jann Horn and the security team at Google.

Migrating from 1.4 to 1.5

Angular 1.5 is the fastest, most feature complete and reliable version of Angular to date. We highly recommend upgrading your applications to use it.
While we tried to keep the number of breaking changes in the core to a minimum a few were unavoidable and will generally only affect very rare corner cases.
You can read about how to migrate and what breaking changes might affect your application in the migration guide.
If you find any issues with Angular while you are migrating, please report them at Github.

Thanks

Once again, Angular could not be what it is without the constant support of the literally millions of developers across the world who are using and contributing to the project, either through submitting issues and pull requests, running conferences and workshops, writing tutorials and sharing their real world experiences.

From everyone at the Angular team, we hope you enjoy developing with this latest version as much as we have enjoyed building it.

Wednesday, February 3, 2016

Angular 2 templates: Will it parse?


As part of the beta release, we eliminated the requirement for kebab-case in Angular templates and replaced them with case-sensitive names for attributes. This makes it easier for you to write Angular 2 templates that are consistent with naming conventions used in directives.

For example, where you would previously write:
  <my-widget (some-event)="someAction()" [some-property]="expression" #some-var>

You now write:
  <my-widget (someEvent)="someAction()" [someProperty]="expression" #someVar>

Case-sensitivity solves a long-standing confusing issue in Angular 1 where you needed to just know the convention for mapping template attribute names to JavaScript names.  This was an easy pit for novices and even experts to fall into.

Browsers don't differentiate tags by case. Solving the problem required Angular to do its own HTML parsing, so that we could retain the case-sensitive version, and lets us eliminate the mapping convention.

So are Angular 2 templates still valid HTML?  Absolutely.  Per the spec itself, HTML is case-insensitive.  You can freely write whatever case you like and still work with every HTML browser, tool, parser, etc. ever written.

But what if you see validation errors in your favorite tool? It's possible that your tool doesn't follow the HTML specification, or it could be a bug. We're working with tool developers to ensure a smooth experience and would like to hear about issues you encounter. Please file them here.

Just as Angular has always made it possible to create your own elements and attributes that add behaviors beyond the browser's basic set of HTML, the new HTML parser provides benefits by extending the syntax available to templates.

More Benefits

Beyond eliminating the confusion of kebab/camel-case, the HTML parser brings many additional benefits including:

  • Better error messages.  When there are errors, we can now tell you which line and column number they occur on in the template.
  • More consistent.  Whether you're on Chrome, IE, Safari, Firefox or even on the server in node.js we parse the template the same way.  We were able to drop all of the heuristic code required in Angular 1 to account for differences.
  • Enables offline compilation.  We're nearly complete with our next phase of performance optimization where we move all parsing/compiling to a build step.  To make integration with existing build systems as smooth as possible we need to parse the template using Node.js without requiring any browser.
  • Catches errors that browsers don't.  Web browsers are more lenient than the specification and auto-correct errors without telling you.  We want templates to be correct, as these HTML errors can cause real problems when browsers guess wrong.  With this new parser, we've already caught real errors in Google applications and in the Ionic 2 framework.
  • Eliminates typos during development.  You can think of the parser as an HTML validator built into your framework.  We can catch typos in your attribute or tag names and tell you before you ever deploy.
  • Better i18n support. Our new i18n support requires us to parse and understand the templates. Having a custom parser makes this job much easier, reliable and efficient.

Future Work

We're also hard at work on a CSS parser to gain the same benefits and potentially more in the realm of style sheets.  We're basing our Animations and Material Design features on this parser and we'll have early versions of them out soon.