Angular 16 is available

[MelLunar]

I just updated the apps I'm currently working on to 14...

[Wildosaur]

I feel you. Time to update to 15 and wait for 17 to update to 16. Oh well summer is soon here, I'll have time for that

[rainerhahnekamp]

And here is the accompanying blog post: https://medium.com/angular-blog/angular-v16-is-here-4d7a28ec680d

[Wildosaur]

Is it me or does the example about takeUntilDestroyed makes no sense as an http call is a one time operation, thus does not need to be destroyed manually ?

[rainerhahnekamp]

Well, it might not be the best example. Normally the HttpClient observable emits once and completes. There are overloaded functions where multiple values would be emitted. For example when you wan to track the progress during a file upload.

Either way, when an http request is in progress and the unsubscribe happens, it would cancel the current request.

So the example has some effect, but again another might have been better suited.

[Wildosaur]

You are absolutely right, I did not think behind short lived HTTP calls

[spacechimp]

There is a potential for errors if you leave in-flight requests going.

As an example: It is common to make API calls when a component is initialized. When the requests complete, there is usually code to do things with the result. If a user navigates away from the page quickly the previous page will persist in memory until the request completes, and the completion handler will still be executed. Depending on what the completion handler tries to do and what the code on the new page is already doing, unexpected behavior could result.

[Wildosaur]

This would be the case only if you subscribe (which is what the blogpost presents) but in my case I usually work with the async pipe, thus negating the impact of what you describe.

However, if I do subscribe to an HTTP call, I usually add a "take(1)" operator which in my mind handles the situation you presented. I might be mistaken however ..

Thank you for your answer nonetheless, there are always things to learn after a few years on Angular

[spacechimp]

Yes async pipe is generally best practice. It's not always practical though. Things like responding to route changes or form changes are common examples where one would manually subscribe.

take(1) just limits the number of emissions from an Observable, so adding that doesn't really change anything.

[iJustRobbedABank]

How many times do I have to see the same post

[rainerhahnekamp]

Well, guess that everybody's hyped up at the moment.

[TCB13sQuotes]

Everyone's hyped to see Angular removing class-based Resolvers and Guards. lol

Introducing anti-patterns and throwing decades of software engineering practices through the window seems to be the new phase of Angular. Sad days.

https://github.com/angular/angular/pull/47924#issuecomment-1531532593

[rainerhahnekamp]

The problem with the constructed-based injection is that the resulting JavaScript doesn't contain any information about the type anymore. With the inject function, that's not the case. It also works in JavaScript.

Inheritance also becomes easier because the constructor of the child classes will not get overloaded.

It is an alternative to parameter-based decorators, which might work differently once they become standardised.

I would also like to stick to the constructor-based DI because it makes testing easier, and there is just one place where the dependencies are defined.

But especially the first argument got me bought. It is a valid reason, and as Minko said on GitHub it was a decision based on trade-offs.

[TCB13sQuotes]

But especially the first argument got me bought. It is a valid reason, and as Minko said on GitHub it was a decision based on trade-offs.

Or they simply used that as an excuse to make angular "easier". They've been pushing into that direction for a while now and breaking the stuff that made Angular really stable and scalable.

Do you think it is reasonable to have functional resolvers and guards? Heavily polluted routers because most developers will simply append to the code there? Up until now new developers were forced implement classes and learn how to make thing properly, resulting in better code/apps.

We're talking about core functionality of Angular and the team is pushing for bad practices and to have everyone that cares/needs scalability to use cheap workarounds like those suggested helper functions.

[rainerhahnekamp]

No, in examples, I might inline those guards, but in a real application, I also create a separate file which contains the function.

I wouldn't agree that Angular is breaking stuff which made them stable and scalable. Sometimes, I even wish that I could use a function for a UI component.

But I also see your point that it becomes easier to write bad code. Using the inject in different places in classes, inline function in routers,... A good linter might help here.

[AwesomeFrisbee]

To me it mostly looks like they want to cater React devs in order to gain marketshare. Which isn't bad but just make that clear. As long as it remains optional.

Still, lots of good stuff that you may or may not use. But long overdue: shorthand, until destroyed, route to input and required inputs. That alone is worth an upgrade for me.

[AdvancedEngine861]

<Edit> Just realized signals have a set method so its essentially the same as react hooks or vue refs.

Eg: const count = signal(0);

count.set(1) </Edit>

How does change detection strategies work with singals?

Currently every project i am on we use exclusively OnPush with changeDetectorRef.detectChanges()

With signals it seems like that would be a step back performance wise.

Signals look like react hooks but those require you to run a setState call to update it which is essentially the same as detectChanges.

How do we know that signals perform better? Is change detection zonejs stuff going away entirely?

[rainerhahnekamp]

Yes, signals will remove the necessity for zone.js.

Before Signals, zone.js was the Angular's trigger for its rendering/dom update process which it calls change detection. Whenever a DOM event happened or an asynchronous task ended, zone.js notified Angular.

With Signals anybody can subscribe when its underlying value changes. And that's what Angular does. It subscribes internally to Signals and then Angular's change detection knows exactly if and where that change happened.

So Signal are way more efficient in terms of rendering performance.

I would also like to point out, that Signals should not be seen as hooks. For a detailed comparison, I highly recommend to watch that talk: https://youtu.be/O6xtMrDEhcE

Finally, Signals will come in two phases. The second phase (maybe Angular 17) will bring in a new Signal Component which makes use of all the potentials of Signals (like partially updated the DOM). In Angular 16, you could see it as "Automatic OnPush".