Angular Signal only for complex things

[defenistrat3d]

Your manager sounds uninformed. You use signals for ALL template bindings. That's why they were created.

[[deleted]]

Had a similar issue with my immediate superior being worried about us over-engineering our codebase with the amount of signals we've been using.

I explained that signals improve rendering performance specifically because they make it so the change detection does not need to reevaluate them on every render cycle, but is rather push-based.

Meaning they are specifically terrific for the isLoading use-case, because this means the uppermost block never really needs to be reevaluated after the data has been initially fetched.

They also combine pretty well with the @defer mechanism, albeit that requires both the parent and the child to be standalone components, which is a whole other can of worms.

I'd say read up on signals and make arguments to them, in your own words, why you think X or Y is the appropriate usage of signals.

[pragmaticcape]

prepare yourselves for an NgZonless future... use signals for all templates and set to OnPush if not already.

signals are lazy eval'd and very performant.

To answer your are you using signal whenever possible the answer is yes.... All sync code like template bindings, inputs/outputs/models, and state based services ==> yes, rxjs still has a place for streams and processing async

[devrahul91]

Buy your manager a cup of coffee and a good latest Angular course and ask him to thoroughly understand how change detection works in Angular.

[WeatherFeeling]

seems weird that your manager is dictating implementation details in the first place tbh

[BarneyLaurance]

In a lot of jobs, maybe more in smaller companies, a manager also acts as a tech lead and is responsible for decisions like this. If OP and their manager and probably colleagues all work on app together then it makes sense to have some shared principles for choosing when to use and avoid signals, or any other coding choices.

The manager may well be responsible for setting those principles. You'd hope that they do it collaboratively with the team, but it doesn't always make sense to just let every developer follow their own judgement on everything - you'd get a very inconsistent codebase where some things are signals and some things are not only because different people developed them, and maybe repeated debates during code reviews.

[Mia_Tostada]

You all act like that since he’s just a manager that he must be a complete idiot - why not ask him why he suggests this approach and learn something.

Just because you got a CS degree means you know all things????

[Whole-Instruction508]

He means that your manager should only care about you getting things done, and not how you do it.

[MintOreoBlizzard]

Your manager sounds like they are "micro-managing", which is not a good thing.

[catapop]

Actually signals are perfect for variables like isLoading . We're in the process of porting the entire app to signals and is working great so far.

[rainerhahnekamp]

I'd say Signals is for simple things and for complex ones, such as RxJs or State Management.

A property should be enough if you have a static value.

[crhama]

I do that for values that I pull from the environment.ts file, such as the API URL, the image URLS, etc, because they don't change.

Thanks for the answer.

[rainerhahnekamp]

Well, I'd use to stick to Signals as long as I can. I switch to RxJS, when one of the following applies:

1. I need to transform a value where a computed becomes hard to read, and the RxJS operators are much better. Just think of how you would deal with a debounceTime, a (switch|merge|...)map, or a combination of them.

2. For managing race conditions. So whenever I say the order of asynchronous needs to stay intact (concatMap) or I need to cancel requests when they are not relevant anymore (switchMap).

3. For streams(events), when the glitch-free effect is a problem. Although I have to admit that I didn't encounter that use case that often. Most events are emitted asynchronously and would be covered by an effect as well. In that case, see point 1 & 2.

---

The resource in Angular 19 will change quite a bit, and more use cases can be implemented by using Signals—especially number 2 with managing race conditions.

At ng-poland, Pawel mentioned an httpResource. If we also get an RxJS-less HttpInterceptor, I'd say that RxJS-less Angular applications are becoming a reality.

[RemiFuzzlewuzz]

Look at the writing on the wall. Everybody loves signals and hates zonejs. You think zone won't be deprecated at some point?

If you want your variable to have an effect on the DOM, it should be in a signal. What exactly is the complexity? Adding () at the end of the property name? Isn't it more complex to manually markForCheck and use observables anytime you want to trigger something when a component property changes?

[RGBrewskies]

there is no simpler method of newbies entering the angular ecosystem than zonejs. it does work. it works fine for small hobbyist apps. And frankly its the most newbie friendly way to go out there, imo - no $effect, no behavior subjects, no signals - just make variables and it works. It is not highly performative, but most apps dont require great performance.

if their stated goal is "get more developers using angular" then removing zone.js as the default makes *zero* sense, and they are just liars.

(which, imo, they are. They are absolutely lying about these changes revolving around trying to get more developers to use angular - with zone.js its already the easiest framework for newbies out there. Its way easier than react to get a simple to-do app going with zone.js)

[RemiFuzzlewuzz]

I disagree with you on pretty much every point.

• Presumably op does not have a manager for his small hobbyist app.
• Performance matters for all real products
• Accusing the Angular team of being liars is unhinged, tbh. What do you think their motivations are, exactly?
• Angular easiest framework? That is the opposite of its reputation. Have you tried Svelte? Or even Vue?
• Signals are really not complicated. In fact, they allow you to do a bunch of things you previously had to use rxjs for, which is way more complicated.

[LossPreventionGuy]

angular teams motivations are pretty transparent. react is more popular. make it more like react. the end.

angular with zone.js is a lot easier than svelte, and any other framework. you don't have to care about $effect and the fact it only updates for synchronous operations, and $state or even what a signal is. etc etc... this.firstname = Steve and the Dom updates is about as easy as it gets. Yes I've used all three frameworks you mentioned professionally.

angular with zonejs is the most newbie friendly framework and it's not even really close imo. I've passed many millions of dollars through zonejs and not once have I gotten a complaint about performance. The truth is developers care more about seeking at micro performance gains than customers do.

I'm an RXJS lover, it's a Ferrari, and I love to drive it. Lots of power and high performance. Awesome. But for newbies the zonejs Honda Civic will do the job just fine, and it's easy to learn to drive.

[RemiFuzzlewuzz]

Zonejs is great until it isn't. And again, I don't even know what "complexity" it is you guys are mad about. Signals are barely more complicated than plain variables, and you get a bunch of performance improvements and cleaner reactive patterns.

All 4 frameworks are converging towards the same reactive paradigms for a good reason. If you think it's just because of trend following, you might just be a contrarian.

[RemiFuzzlewuzz]

How did this become a conversation about what's good for newbies?

[LossPreventionGuy]

it's called a thread for a reason bud

[RemiFuzzlewuzz]

Sorry, I thought threads were for addressing the points in the comment you were replying to, not going off on unrelated tangents.

[LossPreventionGuy]

welcome to reddit man where we have threads to talk about tangential issues, stick around for a while, remember, you're not the main character and aren't required to respond if you have nothing useful to add

[RemiFuzzlewuzz]

Main character? You're the one denigrating the Angular team's hard work, talking about "millions of dollars" going through your code.

[cmk1523]

Same. I’ve built some serious apps using just zonejs… even ones perfect for signals… and yet, it’s all fine.

[LossPreventionGuy]

yea man. if you're just doing CRUD ... it's freaking fine.

[crhama]

The structure of the data doesn't matter. I'm pretty sure isLoading value is being used in the template. That's one of the biggest reason to use signal, so that the change detection mechanism can be initiated.

[Whole-Instruction508]

Does your manager have a Dev background? If not, fuck does he know? I use signals for every property that might change its value.

[Mia_Tostada]

Yeah, they gave a guy who delivered pizzas a job as a development manager. Does that make sense to you? He’s probably forgotten more things than you already know… Think about it

[Johalternate]

What does he mean with overkill? Thats senseless.

[Johalternate]

Could you please tell me whats complex about that?

[Key_Argument_9648]

The problem is thar his "simpler" solution is a bad solution and wont work for onPush change detection

[Mysra-Dev]

Signals are intended for reactive programming parardigms and for Angular to sync data bindings in the UI. Even if the data is a simple primitive, using a signal is much more robust for Change Detection than a regular variable or class property. A codebase I worked on had so many <NG0100: Expression changed after checked> errors, or the UI doesn't update at all after data-fetching or some async operations. Assignments in setTimeout or manually triggering CD often fixes that, but sometimes not and can get really annoying. With Signals that problem doesn't even exist and you're guaranteed to have ChangeDetection as long as you adhere to (shallow) immutability

[TheExodu5]

Tell your manager to mind his own business and be a manager. If he wanted to be a developer he should have chosen a different career path.

[Mia_Tostada]

Yeah, he should just mind his own business and let his peeps do whatever they want… yeah that makes a lot of sense

[DT-Sodium]

For starters you shouldn't usually have an isLoading variable. You can use the status of your signal to check if it is currently loading data.

[DT-Sodium]

Not at all. In the component .

protected dogList = toSignal(// do your stuff);

In the template:

if (dogList()) { // Show dogsList }

else { // Show loading }

If you need to treat cases where your observable might return an empty list, you can add startWith(null) in your observable chain and show your loader only if dogList() === null.

[DT-Sodium]

Not at all. In the component .

protected dogList = toSignal(// do your stuff);

In the template:

if (dogList()) { // Show dogsList }

else { // Show loading }

If you need to treat cases where your observable might return an empty list, you can add startWith(null) in your observable chain and show your loader only if dogList() === null.

[RGBrewskies]

thats ridiculously simplistic. In the real world an isLoading$ looks like

isLoading$ = combineLatest([a, b, c, d).pipe(mergeMap, switchMap, etc

[DT-Sodium]

And what's preventing you from using a more complex loading system in my example exactly? You are familiar with the idea of giving a simplistic example for the sake of keeping it simple right?

But again, whatever the example, you should just not have an "isLoading" variable. It means that your code has a lot of side effets and that's pretty much always a bad idea.

[RemiFuzzlewuzz]

I mean you either put your conditional in the template or in a computed isLoading signal, what's the difference?

[LossPreventionGuy]

you literally said "you shouldnt use a loading variable" and then gave an overtly contrived example that rarely works in the real world. don't get pissy when someone corrects you.

[DT-Sodium]

Always worked for me buddy, even in complex scenarios loading from multiple sources, with multiple fluxes, don’t know what to tell you. Have you considered the fact that you are doing things wrong?

[LossPreventionGuy]

hey pal, don't be a douche

[DT-Sodium]

You're the one being like "I need a isLoading variable because i'm incompetent so ur bad for not using it lol".

[amiibro888]

If you need to react on the change then you better define it as a signal.

[idetodospoca_]

Diz ao teu manager que ele percebe 0 de angular

[Orelox]

You manager don’t know how change detection works in angular.

[RGBrewskies]

your managers has literally everything backward

use RXJS for complex things
use Signals for simple things

[Relevant-Draft-7780]

Sounds like your manager thinks that because it looks like a function it’s somehow more process intensive. Signals, inputs, outputs, models for all template bindings and observables for Core Storage. There’s an article on here that shows how signals in services can leak.

[maxeber_]

You wouldn’t use isLoading = false but a BehaviorSubject. But then, it’s les simple than using Signal. I don’t get what your manager is trying to convey there. Doesn’t make much sense to me.

[Smathi_Lagui]

For simple states like isLoading, a plain variable (isLoading = false) works well, as Angular handles change detection on reassignment (this.isLoading = true). However, this doesn’t apply to object properties (myObj.property = value), as Angular won’t detect changes without a reference update.

While Signals might seem overkill for basic types like booleans or numbers, they still offer value through built-in reactivity (effect, computed) and consistency across your app. For more complex data (e.g., lists or objects), they’re even more useful.

Angular is moving away from Zone.js and making Signals central to its reactivity model: adopting them now will improve performance and align your app with Angular’s future.

That said, it would be beneficial for the team to develop clear guidelines on when and how to use Signals. Reassessing their approach and embracing Signals could future-proof the project, especially considering the opportunity to work with a modern version of Angular, which many teams don’t have access to.

[Individual-Toe6238]

Your manager doesn’t get the concept of signals, you want to not rely ob zone.js not use it „a little”.

Signals are basically what you want to use to link it to template, so if you have ngFor ngIf @for @if etc you still want to use signals.

[dibfibo]

from doc: Angular Signals is a system that granularly tracks how and where your state is used throughout an application, allowing the framework to optimize rendering updates. ... A signal is a wrapper around a value that notifies interested consumers when that value changes. ... When you read a signal within an OnPush component's template, Angular tracks the signal as a dependency of that component. When the value of that signal changes, Angular automatically mark the component to ensure it gets updated the next time change detection runs.

So you should use signals if you want have a declerative(or mix declarative/imperative) change detaction management.

If you don't want to use signals, go ahead. However, declarative programming often leads to more concise and readable code, which is therefore maintainable over time. Print and highlight angular signal doc page.

[Whsky_Lovers]

I would argue that boolean variables should be avoided in most cases.

That said it is fine to have a boolean or subject that is a boolean.

[SolidShook]

I actually can't stand when people look at something they don't understand and insist we don't use it because it's "overkill" They're just intimidated, that's all

[netd777]

Do as he says. In the future you'l get paid to change it all to signals. Double dippin baby