Let's see what angular 8 have for us
Angular 8.0.0 is here!
This release is mostly about Ivy and also the option to give it a try, but in
addition, it contains a couple of features and breaking adjustments. Hopefully,
the upgrade should be quite easy since the Angular team composed a whole lot of
schematics which is going to do the heavy lifting for you.
Angular 8.0 now supports TypeScript 3.4, and also requires it, and that means
you’ll want to update.
You can checkout out what TypeScript 3.3 along with TypeScript 3.4 brings on the
Ivy is obviously a huge portion of the launch, and it took all their campaign
from the team this previous month. There’s so much to say about Ivy that I wrote
a dedicated article about it.
TL;DR: Ivy is the brand new compiler/runtime of Angular. It’ll enable very cool
features in the future, but it’s currently concentrated on not breaking existing
There are no real profits to do so today, however, you can give it a try to find
out whether nothing breaks on your program. Because, at some point, probably in
v9, Ivy is going to be the default. So the Angular team expects that the
community will anticipate the change and provide feedback and that we’ll catch
all the remaining issues prior to v9.
We tried it several of our apps and caught a few regressions, thus we’d strongly
advise not to use it kindly in production.
If you are feeling adventurous, you may add “enableIvy”: true in your
angularCompilerOptions, and restart your application: it currently uses Ivy!
Check our article and the official guide for more info.
As for Ivy, we composed a committed article about the best way best to construct
your Angular applications with the new Bazel service.
The AbstractControl course now offers a new way markAllAsTouchedas well as the
present markAsDirty, markAsTouched, markAsPending, etc..
Like markAsTouched, this new system marks a control as touched but in addition
all of its descendants.
The FormArray class now offers a clear approach, to swiftly remove all of the
controls it contains. You had to loop over the controllers to eliminate them one
//’customers’ is initialized with 2 users Const users fb.array([user1, user2]); users.clear(); // users is currently vacant
Router Lazy-loading with import() syntax
New syntax has been introduced to announce your lazy-loading paths, using the
import() syntax out of TypeScript (introduced in TypeScript 2.4.
This is now the preferred way to announce a lazy-loading course, and also the
string form was deprecated. This syntax is similar to the ECMAScript regular and
Ivy will just encourage this.
/admin/admin. loadChildren: () => import(‘. /races/races. Module’).then(m => m.RacesModule)
A schematic supplied by the CLI will migrate your declarations for you,
therefore this should be painless for those who operate ng update
@angular/cli. Take a look at our article
regarding Angular CLI 8.0 to find out more about this particular.
To assist people migrating from AngularJS, a whole lot of things have been added
into the place solutions in Angular.
PlatformLocation offers access to this hostname, interface, and protocol, and
also a fresh getState() method allows to get the history.state. Even a
MockPlatformLocation can be available to facilitate testing. All this is really
beneficial if you’re utilizing ngUpgrade, otherwise, you likely won’t need
The service worker registration has a new option that allows specifying if the
registration ought to take place. Formerly, the support employee was waiting for
its program to be stable to register, to prevent slowing the start of the
program. But if you were starting a recurring asynchronous task (like a polling
process) on application bootstrap, the application was never steady since
Angular considers an application to be stable when there is no pending task.
Hence that the service worker never registered, and you also needed to manually
work around it. Together with the newest registrationStrategy choice, you can
now let Angular manage this. There are several values possible:
RegisterWhitstable, the default, as clarified above
register immediately, that doesn’t await the app to be stable also registers the
Service Worker right away
register delay:$TIMEOUT using $TIMEOUT function as the number of milliseconds to
wait until the registration a function returning an Observable, to define a
customized strategy. The Service Worker will then register when the Observable
accelerates its first value.
For example, if You Would like to register the Service Worker after 2 seconds:
Providers: [ ServiceWorkerModule.register (‘/news-worker. Js’,’ enabled: environment.production, registrationStrategy:’’registerDelay:2000' ), //… ]
Maintaining a Service Worker
It’s now also possible to bypass the Service Worker for a specific request by
incorporating the new-bypass header.
Notable and breaking changes
A couple of things have changed also need a little work from the part. A few of
the adjustments are pushed by Ivy, and will there be to prepare our software.
But the cool thing is the Angular team wrote schematics to make our life
Simply run ng upgrade @angular/heart along
with the schematics will update your own code. What exactly do these schematics
do? Let’s find out!
The ViewChild and ContentChild decorators currently must have a new alternative
called static. Let me explain why using a very simple example using a ViewChild:
Let’s get that element in our part and log it in the lifecycle hooks ngOnInit
Makes sense because AfterViewInit is called while the template initialization is
However, in Actuality, if the queried element is static (not wrapped in an
ngIfor an ngFor), then It’s available in ngOnInit too:
This wasn’t documented advocated, but that is how it now works.
With Ivy, however, the behavior changes to be consistent:
ngOnInit() console.log ('nit static’, this.staticDiv); // undefined (changed) ngngAfterViewInit ( console.log(‘after view init static’, this.staticDiv); // div
A brand new static flag has been released not to break Present applications, so
if you want to keep the old behavior even when You switch to Ivy, it is possible
@ViewChild(‘static’, inactive: true ) static: ElementRef;
along with the behavior will be just like the current one (the element is also
available in ngOnInit).
Note that if you include inactive: authentic on a lively element (wrapped in a
condition or a loop), then it will not be available in ngOnInit nor in
Static: false is going to be how Ivy acts by default.
To not break existing software and also to ease the migration, then the Angular
team wrote a Treaty that automatically assesses your program, and adds to the
static flag. It even offers two strategies:
One based on your own templates, which will ensure that your program works (so
it is inclined to mark questions as static even when they aren’t). You are
certain that it works, but it exposes you to issues should you wrap your static
component in a condition or a loop afterward.
One based on your use of the
question, which can be more error-prone (as it is harder for your schematic to
figure it out), but will not mark the queries as static when they don’t need to
be. So most inquiries will possess static: fictitious, which is going to be the
default option in Ivy.
The first approach is used by default if you operate ng update because it is the
safest, however, you can try the usage strategy by using
NG_STATIC_QUERY_USAGE_STRATEGY=true ng update.
You are able to have a look at the official guide to find out more.
That is exactly what the migration seems like (using failure in 1 component):
— — — Static Query Migration — — —
With Angular version 8, programmers will need to
explicitly specify the time
of ViewChild along with ContentChild questions. Read more about this here:
Some queries were not able to be migrated automatically. Please move those
manually and apply the right timing.
For more info on how to choose a flag,
⮑ home/home.component.ts@43:3: undefined
Note that this only issues ViewChild along with ContentChild, not ViewChildren
along with ContentChildren (which will work exactly the same fashion in Ivy and
DOCUMENT token moved from
@angular/common. You can manually change it in
your application, but a provided schematic will take care of it for you.
Deprecated web worker package
@angular/platform-webworker package enabled running your Angular
application in a Web Worker. As this proved trickier than expected (for building
the application, SEO…), and not that good performance-wise, the package has been
deprecated and will be removed in the future.
Deprecated HTTP package removed
@angular/http has been removed from 8.0, after being replaced by
@angular/common/http in 4.3 and officially deprecated in 5.0, 18 months ago.
You have probably already migrated to
@angular/common/http, but if you didn’t,
now you have to: the provided schematic will only remove the dependency from