NateDevelops

🚀 Modern Angular Baseline Tips Posted this to my team - do you agree/disagree? Anything I missed? "Lots of new tech is stable and lots of old tech is becoming deprecated so it's a good time to take stock! At this point I would go as far to say that not following any of these tips is effectively baking tech debt into the platform based on where Angular is and is intending to go. Would love to hear your thoughts though. If we're aligned, we can factor them into code review etc going forward. Control Flow/Queries • No need to use *ngIf/*ngFor/*ngSwitch anymore  → Use ﹫if/﹫for/﹫switch instead (we all know this one) • No need to use ﹫Input/﹫Output()/﹫ViewChild[ren]/﹫ContentChild[ren] anymore  → Use input()/output()/viewChild[ren]()/contentChild[ren]() instead Styles • No need to use ngClass or ngStyle anymore  → Use [class] and [style] instead. These are functionally equivalent and avoid the NgClass and NgStyle imports Modules/Imports • No need to import CommonModule anymore  → Just import the specific classes you need. In practice this tends to be things like NgTemplateOutlet or common pipes like DatePipe or JsonPipe. NgIf/NgFor/NgSwitch/NgClass/NgStyle were the reason that CommonModule used to be a standard import in components, but all of them are now deprecated • No need to use NgModules anymore. They should not be created for new components  → Components should now import what they need directly  → Module-level imports (which are rarely needed now) should be placed in the root feature component  → Module-level providers should be placed in either the root feature component or the route corresponding with that feature • No need to manually create destroy$ subjects  → Inject destroyRef and use takeUntilDestroyed(this.destroyRef) instead of takeUntil(this.destroy$) State • All new state variables should be being built with signals: signal()/computed()/linkedSignal(). • Services/repositories/general HTTP usage can still be RxJS heavy but by the time state is consumed by component templates they should be signals.  Implied here is that the AsyncPipe should no longer be used. • Signals are a declarative paradigm so we should be looking to minimise imperative code as much as possible, but sometimes it’s inevitable (e.g. updating a Reactive form pre-v21).  In this case we should use effect() to watch signals for changes or .subscribe() to watch observables for changes.  Inherently imperative events like click-handlers will continue to need imperative solutions. • To facilitate all of the above we should be looking to migrate core pieces of application state to signals when possible. As an example, I recently migrated currentUser to a signal from a BehaviourSubject. This now means any component in the application can reactively consume currentUser without any RxJS/subscriptions. Lifecycle hooks • Once all inputs in a component are migrated to input(), ngOnChanges is no longer necessary • Once all queries in a component are migrated to viewChild[ren]()/contentChild[ren](), ngAfterViewInit is no longer necessary • Once a component is using destroyRef, manual unsubscription is not needed so ngOnDestroy is not needed in a large number of cases • If a component’s state can be modelled fully in signals, ngOnInit is also not necessary In summary, in a fully modern Angular component, you should expect to encounter ngOnInit and rarely ngOnDestroy but never ngOnChanges/ngAfterViewInit. There are more but I think this is a pretty solid list that impacts our day to day."

That's a good alternative too, I like it!

@call_me_dc_ @angular Dancing with it 🥹

@angular Angular is a framework of "when," not just "what." Don’t just write code; understand when Angular decides to run it. If you master the lifecycle hooks, you’ll stop fighting the framework and start dancing with it.

Think back to when you started 🐣 What is the one piece of advice you’d give to a developer just starting their Angular journey today? Share your wisdom and help a newcomer grow.

@bjeaurn @angular Love this! Also "explicit types are unit tests for your variables" is a line that redefined the way I looked at types. Yes it's verbose to type out what can be inferred just as it's verbose to type out unit tests but both have their place! Give the control to the developer

@angular Maybe a completely different take; Types are your friend. Don’t lie to the compiler. Learn to embrace that defining the shapes of your objects helps prevent bugs and makes your code that much more readable.

I haven't found an auto-formatter that is sufficiently configurable, so I just use organise imports/auto semi-colons and format the rest by hand 😅 AI picks up the formatting of the project so it doesn't cause me too much grief! I have started the "Let's all use Prettier!" thing at 3 different companies and always backed out when we realised what we couldn't change

@NateDevelops @PrettierCode Thanks, what do you use instead of prettier?

I was too excited not to try it! Now the code element has formatting with @PrettierCode. tbh, it was easier than I thought! Alongside this small feature, other small features were done, like opacity (not hidden) edges behind the workspace edges, sticky lines, and improved grids. Many new small features are coming as well! Thanks, @sercan, for the formatting idea. 🔥

I haven't found an auto-formatter that is sufficiently configurable, so I just use organise imports/auto semi-colons and format the rest by hand 😅 AI picks up the formatting of the project so it doesn't cause me too much grief! I have started the "Let's all use Prettier!" thing at 3 different companies and always backed out when we realised what we couldn't change

Declarative programming = easier to reason about code = less bugs on new features/refactors Signals = reactive primitives = state dependency chains = more efficient/relevant change detection = performance gains

@angular As of now I'm in a phase where i am convincing my clients to migrate from angular 16 to 20, but they are having the same thoughts , If the app is working then let it work. Any good suggestions to convince them?

Signals continue to transform how we handle reactivity. 🚦 If you’re currently migrating an older project to Signals, what has been your biggest "aha!" moment so far? Tell us about your migration journey below.

@MichaelSmallDev No way! My original comment was actually inspired by injectQueryParams which has the same limitations haha Incredible news, thanks for sharing ❤️

@NateDevelops Well well well, ngxtension just reading our minds lol. ngxtension's signals for routes already so good, but this is even better. github.com/ngxtension/ngx… github.com/ngxtension/ngx…

I just want a signal of URL params/queryParams/fragments that isn't tied to the component tree 😭 I assume this still isn't possible? I was hoping we could statically analyze the route configs and still keep the variable names without needing to be within a component to access them?

Present tense seems more generalisable to me. It conveys that the emission is an event not a state. To test that idea, hold up the name against an inbuilt EventEmitter (click). Would (clicked) make sense, probably, but I think (click) is nicer because it is stateless Of course you can consume state from outputs, but I would say they are more akin to observables (event is the primary use case, state is secondary) vs signals (state is primary, event is secondary)

How do you name your @angular outputs? I keep working on an upcoming Angular agent skills collection, including best practices. Past tense = "something happened" (event notification) Present tense = "do this specific thing" (action delegation)

github.com/angular/angula… @marktechson am I core team member now?? 😂

We’re planning to make OnPush the new default Change Detection Strategy in v22. Also, ChangeDetectionStrategy.Default would be renamed to Eager. Check out the RFC and let us know what you think: github.com/angular/angula…

@SantoshYadavDev @coderabbitai Plot twist: 45,000 lines of JSDoc comments

Should I merge it? @coderabbitai WDYT 😄

Bought my @angularbelgrade ticket - May 7th, super cheap if you buy before Jan 31st! Anyone else going/thinking of going?

@Armandotrue Let's hope we're rich by then and I'll come join you in your yacht and we can talk about the good ol' days 😂

@NateDevelops Ideally LLMs write the website and then finally other LLM-powered bots consume the website lmao 🤣

Many discussions around LLM coding tools go like this: - coding tools are garbage, they never solve the problem for me, it's just hype! - you're using it wrong, I defined constraints, invoked other tools for review, made it work step by step, explained the architecture, provided the right context and it did a stellar job! Maybe there is a lesson there 🤔

True! But I guess the aspect I find interesting is that who judges whether an LLMs output is good? It's the human on the other side. It's a subjective, individual assessment. The same output can be good or bad to different people. That's why I think the smaller the chunk and the bigger the direction by the human user the more likely the user will subjectively evaluate the output as "good" (as it's just closer to what they had in mind, not that it's better in an objective sense) We all know LLMs can one-shot a website but if they can why don't those v1s ever make it to production? It might be good enough for a handful of people but usually the human wants control over the smaller details. Food for thought! You're right though, I probably trivialised the AI thinking element still being amazing, thanks for pointing that out 😁

I guess it is not as sharp of a distinction as you say, but I get the idea. Coding agents (well LLMs under them) can "think", and sometimes better than humans. But yet again, mistakes are unavoidable. It's not an "AI thing", it's an "everything thing", any system can fail, and the more complex it or the task at hand is, the more probable a mistake becomes, and then you need it to go back. Will we able to just prompt ourselves out of any situation? Well, maybe, but not right now. And if not, could we fix it without the underlying knowledge?

@marktechson * cues montage of Mark dusting off his black t-shirt and gold chain *

Today is my last day on Christmas vacation. I took extra time off to be with my family, rest, and re-center. I'm going back to work on Monday, supercharged and ready to go bigger than I ever have. We are on one.

@itsaj123 @Armandotrue I have tried this but in practice I don't enjoy it as much because change detection becomes a pain (force-updating the object's reference vs primitive changes just automatically being detected). Just personal taste though! It looks neater for sure

@Armandotrue I agree, a better approach can be to have one input of type object

I think some might disagree, but a component with too many inputs is just a code smell to me

@Jean__Meche @renatoaraujoc Can't believe I didn't know this AND I just built something that relied on this behaviour that I now have to rework..😂 sad times. A welcome change!

@renatoaraujoc Not the ones provided in the router config

A feature many have been waiting for. In #Angular 21.1 you'll be able to clean-up your injectors when leaving a route. Demo: stackblitz.com/edit/angular-r…