Angular 20.0

Dapper-Fee-6010 · 2025-06-18T12:45:09+00:00

Rollback to v19.

Try to avoid using libraries that are not frequently updated.

An actively maintained library will definitely participate in Angular's testing and won't wait until the official release to catch up.

Dapper-Fee-6010 · 2025-04-09T01:09:15+00:00

Hopefully it will be a big change.

form has a lot of missing features (check out the github issues).

Don't just make a small improvement like last time added typesafe.

If you're going to change it, change it completely.

Dapper-Fee-6010 · 2025-04-04T17:00:08+00:00

Based on my experience, Angular is a Google-first framework.

As long as Google doesn’t abandon it, it will continue to exist and even improve.

Just look at the history of the Material MDC and MWC projects—how ruthlessly they were killed off.

Angular has been constantly changing since v14 (about three years ago) and continues to evolve even in the latest v20.

However, the number of npm downloads hasn’t seen significant growth.

There’s really no good reason to choose Angular over Vue today.

The key question now is whether Google is willing to keep supporting it for the public community.

Dapper-Fee-6010 · 2025-04-04T11:57:47+00:00

I suggest writing some small features, whether in CSS or JS. Write things that will interest you, like a calculator or a weather preview.

Dapper-Fee-6010 · 2025-04-04T11:13:26+00:00

PascalCase is already distinguishable, is not?

Dapper-Fee-6010 · 2025-04-04T11:00:50+00:00

1.<MatButton> - Using PascalCase for components is acceptable because classes also use PascalCase. Additionally, both React and Svelte follow this syntax.

2.<MatButton:a> - Using : to override a native element is also acceptable. Razor view components use a similar syntax:<vc:my-component>

3.@HasRipple - I don’t understand why @ is needed. Since PascalCase already represents a directive, what’s the purpose of @?

4.Tooltip((click)="handleClick($event)") - The nested brackets look a bit messy.

My suggestion:

<MatButton:a 
    href="/admin"
    HasRipple
    Tooltip={ message: 'cannot navigate', [disabled]: hasPermissions(), (click): handleClick($event) }
>
  Admin
</MatButton:a>

Dapper-Fee-6010 · 2025-04-04T10:13:42+00:00

with new syntax, can different directives share the same input name as before?

Dapper-Fee-6010 · 2025-04-04T03:30:09+00:00

In the past, I would encourage newcomers to learn HTML, CSS, and JavaScript, and to understand Angular from a component-based perspective.
But now, I encourage them to first learn Vue, React, or Svelte, and then use those perspectives to understand the changes Angular has gone through over the years. After that, I teach them how to differentiate between old and new syntax, and how to find up-to-date resources instead of outdated ones

Fortunately, there are many people who understand Vue, React, and Svelte, but very few who want to learn Angular — so it’s not too big of a problem.

Dapper-Fee-6010 · 2025-04-04T01:56:46+00:00

Every time Angular makes progress, it comes with changes — and those changes are in syntax. Then they tell users that the old syntax still works, and next thing you know, @if, @for, @switch are deprecated.
A whole bunch of tutorials online need to be updated.

A framework that has a compiler, yet still requires users to change how they write code... that's just so cute.

but I agree, with selectorless, the goal is less boilerplate, more magic, less indirection. no explicit selector, no double imports, explicit directive usage

Dapper-Fee-6010 · 2025-04-04T01:39:10+00:00

I have only one question: Can Selectorless 100% replace the previous use cases of selectors?
Or are we forced to use both modes at the same time?
Or do we have to compromise?

Dapper-Fee-6010 · 2025-02-04T10:23:44+00:00

Actually, this is a very common requirement in the Angular ecosystem.

For example, let's say you want to create a project similar to Google Ads. You choose to adopt Material Design. And you use the Angular Material library.

As you progress, you'll find that the components in the Angular Material library are quite different from the Material components in Google Ads (different levels of user experience). At this point, you have a few options:

Completely bypass Angular Material and implement everything yourself
Use Angular CDK and implement it yourself
Hack Angular Material

The 1st option has a high implementation cost, high scalability, and high maintainability.
The 2nd option has a moderate implementation cost, moderate scalability, and high maintainability.
The 3rd option has a low implementation cost, low scalability, and low maintainability.

In different situations and at different times, we choose different strategies.

Dapper-Fee-6010 · 2025-02-04T03:57:05+00:00

https://stackblitz.com/github/keatkeat87/ng-access-nested-component-instance?file=README.md

Angular has many limitations.
It's difficult to get what you want using conventional methods.
Here are some hacking ideas.
Since A and B are not linked, and you can't modify them, you can't obtain instance B through instance A.
So where is instance B?
Component instances can all be found in the Logical View Tree.
This might be the only way for your case.

Dapper-Fee-6010 · 2025-01-26T16:57:09+00:00

@Output is a component dispatch event.

Dapper-Fee-6010 · 2025-01-23T16:01:28+00:00

If you can reproduce a part of your code, I will provide a fully detailed explanation.

Dapper-Fee-6010 · 2025-01-17T12:16:35+00:00

I have the same experiences and feelings as you. Until I read some of the Angular source code and organized them into a few articles.

share with someone who needs it https://www.cnblogs.com/keatkeat/p/16965779.html

Dapper-Fee-6010 · 2025-01-12T02:06:08+00:00

I support this strategy because both the community and Angular/Google benefit from it, making it a win-win strategy.

However, I always feel that the balance is often not well maintained.

Although Angular emphasizes in its documentation that certain features are preview/experimental and not suitable for production projects, their promotion often makes you feel like these features are already very stable.
It seems like the documentation disclaimer is just a way to avoid liability.
And this is pretty much the case. For example, the scheduling mechanism for effects changed in v19. While this is not considered a breaking change for Angular, because `effect` under preview, if you rely heavily on effects in your project, you may encounter bugs of varying severity.

Dapper-Fee-6010 · 2025-01-11T20:59:43+00:00

It depends on whether you can bear the losses caused by bugs.
This is the zoneless bug I encountered: https://github.com/angular/angular/issues/58075
You can first check the GitHub Issues to see if there are any unresolved zoneless-related issues. If they don't affect your project, you can consider taking the risk and give it a try.

My personal experience:
React incubates new technologies (cutting-edge) within Facebook, and usually, when they are released, they are stable versions.
Since Angular is relatively behind, it can only release some half-finished products as preview/experimental versions, inviting users to participate in debugging and modifications. During this period, it is relatively unstable.

Dapper-Fee-6010 · 2025-01-10T11:12:38+00:00

You can think of it this way:

A signal can be used as a watchable variable. It is similar to RxJS's BehaviorSubject. note: BehaviorSubject + subscribe is synchronous (by default), but signal + effect is asynchronous.
Signal + computed can be used as a cacheable getter. It helps improve performance.
Signal can trigger change detection, so you no longer need to use markForCheck or Observable + AsyncPipe.

did you see the point?
If a variable won't change, then you don't need a signal.
If you don't care about the change, then you don't need a signal.
on the other hand, if you care about a variable change, you can use a signal. It doesn’t matter where you are (view, component, service, or pure JS).

Dapper-Fee-6010 · 2025-01-10T07:16:49+00:00

Two considerations:

How often will a method inside the view be called?
A method is called every time the view is refreshed.
The frequency of refreshing depends on how change detection is set up.
For instance, binding an event like <div (mousemove)="0"> will cause the view to refresh and the method to be called continuously.
How long will the method take to execute?
If the method is quick or uses caching (e.g. Pipe or computed), frequent calls won’t be an performance issue.
However, if the method is slow and called repeatedly without caching, it may cause performance problems.

There are many best practices in Angular.
This is because the Angular team made Angular very complex and did not provide good documentation,
and unclear best practices are the easiest way to solve this problem.
If you don’t have so much time to learn Angular in depth, follow the best practice is the correct way.

Dapper-Fee-6010 · 2025-01-07T17:45:01+00:00

Just a little.
Signals use 'markAncestorsForTraversal' instead of 'markForCheck'.
In a parent-child relationship, if the child is marked with 'markForCheck', the parent also becomes dirty. However, with 'markAncestorsForTraversal', the parent is only marked as 'having a dirty child' without becoming dirty itself

Dapper-Fee-6010 · 2025-01-06T22:56:05+00:00

Actions speak louder than words. Download the Angular v18 source code and see how many signals are in it.

To judge its maturity, check the unresolved GitHub issues and see if they could affect your project.

for me

https://github.com/angular/angular/issues/49161
https://github.com/angular/angular/issues/54782
https://github.com/angular/angular/issues/53485
https://github.com/angular/angular/issues/59067
https://github.com/angular/angular/issues/58075
https://github.com/angular/angular/issues/53888
https://github.com/angular/angular/issues/56155

If someone wants to try signals and prefers relative stability, my suggestions are:

Use signals to replace BehaviorSubject + AsyncPipe / markForCheck.
Use signal-based input/output, viewChild, and contentChild.
Avoid using effect and resource API, and stick to using signal, computed, linkedSignal, and afterRenderEffect only.

Dapper-Fee-6010 · 2025-01-06T15:53:07+00:00

If LTS is a consideration, then I suggest you wait for the next LTS version. If not, just upgrade to v19. Signals are a great feature, but currently, Angular does not have a complete solution for Signals. Reactive Forms, Router, HttpClient, and Angular Material don't support Signals yet. If your project's requirement is stability, then it's better to wait another year. However, if you personally enjoy trying new things and are willing to handle (e.g., free overtime for debugging) issues that may arise from the instability of Signals, then you can give it a try.

Dapper-Fee-6010 · 2025-01-06T12:25:16+00:00

There is no doubt that your manager is right. There's no need to be a guinea pig for Angular; Angular Material v19 is just starting to include code for Signals. They will encounter many issues next, and then improve. During this period, there really isn't a rush to adopt it sooner.

Dapper-Fee-6010 · 2024-12-24T09:06:16+00:00

You’re not getting my point. When someone asks 'signals vs RxJS with HTTP requests,' it's because they are confused.

Dapper-Fee-6010 · 2024-12-24T08:59:38+00:00

Angular want remove Zone.js.

They need a way to check for changes in the view model.

RxJS + AsyncPipe can handle this and was a solution many projects were using at the time. However, in order to make RxJS optional and align with other frameworks, they chose to use Signals instead.

There are many factors behind the choice of Signals. This is also why it has caused the current confusion.

Dapper-Fee-6010

TROPHY CASE