DEV Community

Cover image for Ng-News 24/40: Angular Myths, Signal Input Migrator
ng-news for This is Angular

Posted on

Ng-News 24/40: Angular Myths, Signal Input Migrator

Dmytro Mezhenskyi debunks outdated Angular myths in his latest video, highlighting how the framework has evolved. Matthieu Riegler announced new migration scripts in Angular 19, streamlining the switch to the input function and signal queries.

Common Angular Myths

One side-effect of Angular’s current pace is that things that used to be true in the past may no longer apply. In his latest video, Dmytro Mezhenskyi dives into common myths about Angular and sheds light on how things have changed over time.

He tackles misconceptions like Angular being slow or always having a huge bundle size, and explains newer updates, such as the myth that dirty marking does not trigger change detection.

If you’ve been working with Angular for a long time, it might be time to re-evaluate some design decisions.

Signal Input Migrators & Video

On the Angular 19 front, Matthieu Riegler from the Angular team announced a new migrator that automatically replaces @Input() decorators with the new input function for property binding. There’s also a migrator for signal queries like viewChild and contentChild.

You can already try these features by using the next version of Angular. These migration scripts are easy to run and safe, even though they modify source code.

Lastly, if you want to learn more about Signal Inputs before migrating, Igor Sedov has published a video that gives a detailed overview.

Top comments (3)

Collapse
 
spock123 profile image
Lars Rye Jeppesen • Edited

Thank you.
I'm mostly following the V19-Next releases, anxious when they will flip the switch for "default standalone" flag.

Collapse
 
ng_news profile image
ng-news

You mean you just follow them or do you also use them in production?

Collapse
 
spock123 profile image
Lars Rye Jeppesen

We don't use v19-next versions in public production sites, but internally we have projects that use the .next releases.

I just look forward to removing a bit of clutter in the components.
It helps that we now have a tsconfig setting that enforces always standalone components, but removing the "standalone: true" in components would de-clutter things a bit.