🚀 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."

Angular 22.0 is available ! github.com/angular/angular/r…

Merged ✅

Signals Form will be promoted to stable in v22. #Angular github.com/angular/angular/p…

are there people out there who just want to refactor every day? just wake up and find the worst code and just chip away at it and clean it up wake up the next day do it again, infinitely improving things with zero external impact?

Something I've wanted for years. Finally going to land in #Angular v22. You'll be able to comment attributes/inputs. What you're seeing here is the toggle support by Vscode (thx to the Angular language service extension).

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

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?

github.com/angular/angular/d… @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/angular/d…

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

What is your JIRA personality? - Less columns/states; simple but ambiguous - More columns/states; bloated but accurate

I realised I've never actually seen an #Angular lazy-loaded chunk fail. Surely it's possible as it's travelling over the network? Are there inbuilt framework-managed retries? Or are devs explicitly handling this somehow? Or is it actually impossible?

#Angular do I still need to launch a new Chromium instance to use the debugger? This was always a sticking point for me, wondering if the tooling has evolved?

Signal graphs using mermaid for a basic filtered list implementation - was pretty fun/helpful making this! Haven't used the Angular DevTools version yet, I'll try that out later today and compare

i will never call it a merge request

github.com/nrwl/nx/releases/… Angular 21 available in Nx! 🙌(beta release) I've never spoken to @leosvelperez_ from the Nx team, but I certainly owe him a beer! 🍻

AGI is coming but we still can't put comments in JSON or block comment over existing HTML comments 😢

Joy and fulfilment are often opposites - When you indulge in short-term pleasures, you win joy at the expense of fulfilment - When you invest in long-term discipline, you win fulfilment at the expense of joy As @ChrisWillx said "There are no solutions, only trade-offs". Nothing is inherently bad it is just either in service of joy or fulfilment I have often wrestled with this notion - "Why shouldn't I indulge if it makes me feel good?" - "Aren't the net positives of a life of daily hedonism greater than the net positives of a life of discipline with some magical 'future payoff'?" - "Is there a 'best positive emotion' or should they coexist by design?" Intuitively I feel there is a place for both. My best periods in life have never been 100% disciplined but my worst periods have certainly been my least disciplined To tackle this I went meta - Certain periods are marked for joy - Certain periods are marked for fulfilment It could be 1 day of joy for every 6 days of fulfilment. Or 1 day for every 364 days. It's a sliding scale, a ratio, that every individual gets to control. All configurations are valid. This is not ground-breaking, of course, and lacks nuance but it gives us language to interrogate the idea. Nobody knows their ratio straight out of the gate. We should live life, experience things and tweak our ratio over time. What we don't get to say is "I want the results of a 0.1 J:F but experience life at a 0.8 J:F". So many people do this, either consciously or subconsciously - I want the body but don't want to diet - I want money/independence but don't want to have to grind a business to success - I want to have a strong character but not repeatedly do hard things needed to build it These are classic cases which could be represented by a discordance of ratios. A shiny object which tempts individuals towards a ratio which is not aligned with who they are What I would give for a simulation that takes a person's current state and a slider and shows them what the ratio cost really is for the results they desire. My prediction is if such a tool existed, far more people would be content in aiming "lower" Can a person's ratio be changed/developed? I don't know - this feels more fundamental, almost spiritual. It's a similar question to "can someone change their character?" They can fake it until they make it sure, but have they ever really changed? Is their soul completely at peace with this new version of themselves or is this just a new layer of programming that's serves some social goal and further complicates/obfuscates their internal wiring/value system Maybe this is all nonsense but it speaks to me. Thanks for reading and I'd love to know if it speaks to you too!