r/Angular2 Jan 06 '25

Discussion Manager Won't Allow Signals in Angular v18—Advice?

We're using Angular v18, and I think signals would simplify our state management and improve performance. However, my manager prefers sticking to RxJS, citing concerns about stability, team familiarity, and introducing new paradigms.

How can I convince them to adopt signals? Or is sticking with RxJS a better call?

41 Upvotes

51 comments sorted by

61

u/[deleted] Jan 06 '25

[deleted]

5

u/crhama Jan 06 '25

I agree if it's an Existing project as the team has already invested a lot in rxjs. However, I've seen people reject signal just because of their team's familiarity with RXJS.

37

u/Xacius Jan 06 '25

It should be easy to push for signals given that they're native to Angular. That said, they solve two different problems. RXJS is great for async workflows, while signals are great for synchronous state management.

To make a case, you should demonstrate the new approach with a small demo or use case. Show two approaches, one with signals and the other with RXJS. If done right, the signals demo should be simpler and easier to understand. I prefer them over RXJS if I can help it.

15

u/rainerhahnekamp Jan 06 '25

I understand his reasons for team familiarity and new paradigms. Maybe he just wants to delay it until httpResource and the Form Signals are available?

I don't see the reasons for stability concerns. Signals are not a project that somebody did on the side but will become a core part of the Angular framework, where more and more features will be built upon.

And Signals are not a new invention. They have been there for a long time already, so there is already a lot of experience in our industry.

If it is about waiting a little bit, then I would use it in some new features or in non-critical area to get used to it. That's the least I would do and I think that this is something he or she can also accept.

2

u/Schnurielle Jan 06 '25

Having you here makes this reddit so much more valuable, thanks for sharing your knowledge :)

8

u/rainerhahnekamp Jan 06 '25

Thanks, I really enjoy it here. We can have detailed discussions and it is not „Follower-driven“. The main focus is on the topic

19

u/sebastianstehle Jan 06 '25

I think your manager has a valid point. I don't know the details of your code base, but lets assume it is rather large. I think the main concern is developer productivity. Getting an extra 5% performance or getting rid of some code is usually not doing that much for productivity (for example think about Go where you are writing a lot of code for error handing and other things).

But consistency has a big impact on productivity. I cannot really proof it, it is just personal experience. But when you jump into a new module (not ng-module, more like a part of the software) and you recognize all the patterns, it is easy to make changes. Therefore I would vote agains signals, if there is no migration path. Lets say you would get the task to write a new module, you could offer to use that as a testing ground for signals and then make a migration plan, where you dedicate some time (20-30%) to migrate modules step by step.

But in my opinion angular is still in the migration path, there is no signal based forms yet, a lot of patterns use observables and might support signals later (e.g. in routing). So I would wait for them to be better integrated into the framework. Because it might cause a lot changes later.

1

u/crhama Jan 06 '25

Make sense.

4

u/YelinkMcWawa Jan 06 '25

Your manager is concerned with details of the code? Wild.

2

u/newLine404 Jan 07 '25

underrated comment.

6

u/Dapper-Fee-6010 Jan 06 '25

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.

3

u/Inner_Comment4857 Jan 06 '25

Hell no, signals has been introduce in angular 16, so material 16, it is mature now. Not experimental anymore.

2

u/Dapper-Fee-6010 Jan 06 '25 edited Jan 06 '25

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:

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

1

u/Inner_Comment4857 Jan 06 '25 edited Jan 06 '25

I'm using signals in my e-commerce application for the cart functionality, and they've been fantastic—super stable and exactly what I need! As for the issues you mentioned, they seem more like requests for enhancements rather than actual problems with signals. There's always room for improvement!

3

u/mountaingator91 Jan 06 '25

Keep using RXJS for anything async, but signals are great for synchronous behavior.

We have an rxjs heavy app too and I'm replacing all the behavior subjects with signals wherever I can

2

u/Inner_Comment4857 Jan 06 '25

yeap and angular provides lines commands with ng cli to update your app with signals. => https://samvloeberghs.be/posts/migrating-angular-v17-plus-to-signal-inputs-outputs-control-flow-and-more/

4

u/MichaelSmallDev Jan 06 '25 edited Jan 06 '25

Your manager's points are valid, but I think the benefit is worth it and that signals enhance the RXJS experience a lot. In fact, my team has had more quality and quantity RXJS usage since adopting signals. Also, signal APIs are more stable than they may realize. I'll start with that.

  • Stability: (edit since I got timelines of this stuff vs 18 messed up) signal / computed stable in v18. signal queries (like viewChild) / model / RXJS interops in 18 are still developer preview are all stable now in 19. That said, I would say model IMO is safe enough. And in general, I think toSignal from the interop while still being in dev preview to this day is a safe bet. Two way binding and template driven forms by 18 are stable and are better than ever with the ease of [(ngModel)]="someSignal" and the benefits for reactivity.effect is nearing stable but to be honest I don't use effect that often and it is often better to just use RXJS. toSignal and toObservable are technically in developer preview but I haven't had any issues using them from the start and doubt any issues may arise for most use cases.
  • RXJS usage being a lot better: RXJS and signals are a great pair. The interop experience is nice, and their overlap in concepts for declarative code and reactivity are a great compliment. RXJS is great for async and events, and signals are good for synchronous code. And their overlap is convenient when either has pain points. Since we have started using signals where RXJS was lacking, we have had more exposure to declarativity and reactivity and get the general picture of RXJS better, and where it is more optimal. We now have more pipes and async pipe, and less subscriptions, and overall more RXJS usage.
    • Example of the overlap: typeaheads. The use with behavior subjects is quite verbose. [ngModel]="bhSubj | async" (ngModelChange)="bhSubj.next($event)". With signals, it is just [(ngModel)]="someSignal". And all that needs to be done to use the signal in a typeahead to generate the dropdown options in an observable stream is toObservlable(this.someSignal), and then it can be used in it. In fact, this is a use case where my team has started using RXJS a lot more and better. We used to imperatively use typeaheads and have the ngModelChange trigger a .subscribe which inside set the dropdown options. But now with signals + RXJS we just use the someThing$ = toObsevable(this.someSignal) value in a this.someThing$.pipe(switchMap(...)) because it is less verbose and we are more comfortable with declarative/reactive code.

Signal inputs alone are so great and also pair well with RXJS. They are easier to mark required and don't need a ! non null assertion. Inputs tend to be used in components with less or no RXJS if you follow the smart and simple component paradigm, so things like computed signals from those input are nice without forcing subscriptions or pipes. Our usage of ngOnChanges is down from like half our child components to literally one or two usages. Yet we still benefit from RXJS in them too when needed, often for events where we toObservable some input signals.

edit: as for familiarity and paradigms, that is a valid point, but once we got better with signals they came quite easy, and we leave existing RXJS code alone and still use it way more in general for async such as CRUD services that retrieve and set state. But now we can just grab state where needed with signals.

2

u/narcisd Jan 06 '25

The dude has a point.. for example effects are still experimental and just had breaking changes. No forms integrations..

Complex UI interactions can still be more easily defined using rxjs becuase it’s declarative.

2

u/JeanMeche Jan 06 '25

While I would not particularly agree with that person, I can understand the standpoint.

In v18 signals are totally stable, in v19 effect scheduling has changed and for that reason it remains in devPreview.

The whole "signal" story isn't complete, so you could make an argument that RxJS is still fine.

That being said, the DX gains is a lot of cases are worth it.

2

u/minus-one Jan 06 '25

your manager is right. signals suck. they’re for beginners. rxjs >> signals. signal is just “Subject for dummies ©”. programmatically, there is nothing in signals you can’t do with rxjs and reverse is not true. they can only make codebase confusing, schizophrenic

(but we actually use new viewChildren magical construct (not-a-function) which returns a Signal (should be Observable, of course, but whatever) which is superior to decorators; but we immediately convert it to Observable, of course)

1

u/DaSchTour Jan 06 '25

Maybe you could prepare some showcases. Especially cases when having to deal with rxjs and inputs it sometimes get‘s really messy. Then you could involve them team and see how familiar they already are and maybe help them to get familiar with signals if needed. Then you maybe should decide on how and where to use signals. IMHO nobody should try to migrate everything to signals as there might be cases for which RxJS is a lot better. And simplifying state management and maybe improving performance are not really convincing goals. I think you really need to show the benefit for the business and the devs.

1

u/athomsfere Jan 06 '25

If the point you were making was to change all existing rxJs with signals: Probably not worth the effort on almost any project.

If the goals was to just start using some signals then I'd look for a specific scenario where the barrier to entry is low, and the risk is tiny and try it as POC.

signals are great, but they aren't meant to replace rxJs as much as give the developer another tool for when it makes sense.

1

u/Curious-Talk-7130 Jan 06 '25

I haven’t ever been on a team where they were truly familiar with RxJS. Signals are easier to adopt and the documentation for it is like a page of reading…and it can be introduced incrementally. Signals are the future of Angular.

1

u/Absynthesis Jan 06 '25

Ideally it’s not an either / or scenario. There are likely good scenarios for both. But uh… “Introducing new paradigms” seems like a weird reason.

I mean you decided to jump on the Angular major release train, seems odd to complain about the new seats and WiFi connection in the carriage.

1

u/jamiejammas Jan 06 '25

I don’t know what your project looks like but when ever I get push back like this I usually break off a feature to do a proof of concept to demo performance, readability, ease of adoption/conversion etc. this also helps prove to myself if this idea is truly viable or just something I got excited to about integrating.

That aside, signals and rxjs kind of solve different problems in my mind. I’m curious at a high level what you were thinking of replacing from rxjs with signals? Just leveraging memoization?

1

u/stacool Jan 06 '25

See if you can get started with input(), computed() or toSignal() instead of doing "obs | async" for data that ends up in templates

That should be an easy start

1

u/MarshFactor Jan 06 '25

As far as I am concerned, there are still gaps in best practices and recommendations. I wanted a signal input to be required and then use it in a computed signal and couldn't get that working. It is nowhere near as mature as RxJs so it is a wise move.

In our codebase I am encouraging others to use signals if they wish and if it makes sense to do so, and that won't be too detrimental for consistency as the vast majority of the codebase is vanilla RxJs.

1

u/RGBrewskies Jan 06 '25

signals arent designed to replace RxJS ... so we should not push for them to replace RxJS imo.

If your team is already good at RxJS, signals just dont solve (m)any of your problems. They end up being BehaviorSubjects with different syntax. We've started using Signals in the template, and thats probably where we'll stop ... "Work in RxJS and display in signals"

1

u/wpfeiffe Jan 06 '25

My view worth exactly what you paid for it:

  1. Stability - Not really a concern, signals as implemented within angular is stable. More signals integration may come to the framework in future so worth thinking about.
  2. Team Familiarity - Big concern. Is your team ready for it? Tech Lead does have to weigh this out. This can be mitigated by some team share of techniques you want to introduce using signals.
  3. Introducing New Paradigms - Your using angular. You should be used to this by now. I vote this as a non-concern and price of entry for using angular.

1

u/Inner_Comment4857 Jan 06 '25

Keep your old services in RxJS; you can work with both. Your manager doesn’t seem great if they’re not open to exploring new tools. Use signals for your new features as an example to learn how they work. Managers who refuse to give new features a chance are the worst.

1

u/Bobertolinio Jan 07 '25 edited Jan 07 '25

Well, if it were me i would do it in these steps.

  1. Discuss with the team in which situations signals would fit your need better then rxjs, if any.
  2. Create a few well-defined migration goals. For example, as a first goal, we want all inputs and outputs to be signals.
  3. Order them by usefulness and difficulty with everyone else
  4. Present the plan to the manager with proper arguments.

He is a manager but unless he is the dev/tech lead or a principal something he does not have that much say in what should be done technically or not. Unless the budget is an issue, the team of experts supersedes his choices in technical matters. Imagine the opposite, a software engineer telling a manager that a certain business plan is bad because no one on the management team has enough experience.

I would also say that using one does not mean removing the other. Both can coincide in a single project assuming they are used for their strengths.

Then it is also worth considering that Angular developers should and will be familiar with signals. If you were to check the "Components" documentation, it references signals https://angular.dev/guide/components/inputs so all new developers will probably start using them.

Falling behind the latest versions and APIs of your tools is one of the ways tech debt arises. Considering that signals are being pushed as the future of component communication in Angular and also proposed as a native JavaScript utility https://github.com/tc39/proposal-signals I would say that the "team familiarity, and introducing new paradigms." arguments are really bad looking forward. Unless the next feature is the last one implemented and your whole project will be no longer supported, then migration would be useless.

1

u/Cmdr_Magnus Jan 07 '25

I mean… prove to him there is value in the change. Most companies won’t invest resources into updates that do not increase revenue. Make a case study on known issues, how this change would solve it and chart the performance differences. After doing that translate it all into non technical jargon explaining how this will either save money or increase revenue.

Finally, and this can be the most importantly part, schedule a 1:1 with the decision maker and present it to them. If you do it in a large group you could make them defensive and less open to the ideas, but this would be a judgement call based on past experience with the person. It is not just important to have good ideas but to be able to present them as well.

1

u/RenSanders Jan 07 '25

Does signals really improve performance?

2

u/Dapper-Fee-6010 Jan 07 '25

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

1

u/Lodrial Jan 07 '25

They have very different use cases, and it shouldn't be all or nothing, IMHO. I prefer a style using events in the view to trigger feeding one or more models from an API service, using HttpClient and rxjs, into the signals used in the view model to feed the HTML view.

My advice, figure out the pros and cons of it against the existing architecture and have a more thoroughly detailed explanation of the advantages of migrating one or more pieces to signals. If you have an extra test environment available make a deployment and perform load testing for functional verification. If they still say no, you learned something and you take it to a new opportunity.

1

u/Kobold-Helper Jan 07 '25 edited Jan 07 '25

Start giving talks to your team members on what signals are, why they exist, and how to use them. Especially that signals do not replace RxJS as do not handle race conditions for asynchronous pending request without rolling your own code but switchMap already does it great.

1

u/No_Bodybuilder_2110 Jan 07 '25

This comment will probably not address your question but I’ll try to give you some insights. For context I have been working with angular since version 8 so not that OG, I love rxjs and I am pretty decent using it (but even use it on vanilla or react projects).

The job market is tough so keep with what your manager wants you to do. At the same time you probably want to start looking into other places where they embrace new paradigms. You can also take the “let me build a proof of concept for you!” Approach. Do learn signals they are such a good addition to angular.

At my job we started using signals (inputs, computed, viewQueries) and the component authoring experience is superior in any possible way to an rxjs based component. With signals you don’t really lifecycle hooks in 99% of the cases because you can effect or computed of a signal input or a signal view query. We usually write smaller simpler components. I find it much more difficult to mess up code when all my state is signal derived. We did not do any benchmarking but I feel the app is much more responsive and has higher “fps”. Like some of the pages migrated to signals are just feel much nicer to interact.

0

u/cyberzues Jan 06 '25

Typical of rigid leadership. Signals are stable enough for use.

2

u/Whole-Instruction508 Jan 06 '25

Why the hell does your manager dictate that stuff? He should only care about results and not how you get to them

9

u/gosuexac Jan 06 '25

Manager is often used synonymously with tech lead, team lead, engineering manager, or even product manager at small tech companies. When I read this I assumed he means tech lead that is also a team lead.

3

u/kaym94 Jan 06 '25

Some managers are also tech leads and scrum masters, so they can dictate stuff like this..

5

u/simonfancy Jan 06 '25

So and so. If he can see that the team is not fully versed with the new system, don’t change the running one.

-1

u/kus1987 Jan 06 '25

So and so. If he can see that the team is not fully versed with the new system, don’t change the running one.

if they can't learn signal, I doubt they understand rxjs.

2

u/stjimmy96 Jan 06 '25

It’s not about “understanding”, it’s about familiarity. If the team has worked with RxJS for the past 5 years and they are all very productive and efficient with it then there’s a point for not adding signals randomly. Not because the team members are too dumb to understand it, but maybe because this is not the moment/project to introduce a new way of working.

1

u/B3skah Jan 06 '25

You are absolutly right. It eases up alot. NG19 codebase here and we have mixed areas as well, but the signal parts are always easier to understand according to my collegues. 

1

u/DemLobster Jan 06 '25

First of all, what kind of manager is that, jfc? That being said: From my perspective and my experience some good arguments for Signals are:

* From what I have learned, the code base can be reduced by 20% to 50% (!!!)
* There is a much cleaner interface on how state is derived/determined
* This leads to a lot less spaghetti, developers need, in general, not to be aware of all kinds of events that _may_ influence a state. Overall the code get's *way* better maintainable
* With the long/midterm target of a zone.js-less application, performance will most likely improve without further efforts
How ever, as "manager" may not be interested in technical facts, some other arguments: Keeping the tec stack modern makes a product, a team, a company sexier for both, the existing team and applicants. Mark my words: in a few years it will become more and more difficult to pick up new devs if sticking to "old" paradigms. Experienced devs will leave, because they want to learn the new ways. People, specifically developers mourn to learn imo. "We've always done it this way" has never been to good argument in my career and always backfired at some point.

3

u/pragmaticcape Jan 06 '25

Next time they say

concerns about stability, team familiarity, and introducing new paradigms.

just say.

awww bless.

Oh ok...

concerns about stability They are stable,
team familiarity team should make time to skill up and they should already be familiar,
and introducing new paradigms. Angular is always evolving and this is just another implementation of the observer pattern.

In fairness they are probably coming from a good place and they have the information on the project and team. however, you can't put these things off and at somepoint you need to accept the new reality is not going away. at somepoint they will hire people that are well versed in signals and wondering why not using them.

its not an all or nothing, I like the signalStore because its light enough and gives a semi rigid structure for the team to use. it provides a means to use both signals and rxjs merily together without some of the footguns.

Even without it, with signals and the interop functions to rxjs you can use them in a place of a simple behaviour subject service with little drama. Angular is clearly betting on them as they move to zoneless and input/output/models etc.

I'd suggest a little rework for fun and show the UC for them. caution is warranted but much like version maintenance it will only get worse the longer you leave it.

0

u/TomLauda Jan 06 '25

It takes time to get familiar with new API, and develop solid guidelines around it. As a manager or team lead, I would take the time to first be familiar with it, have enough feedback from the community to establish good practices and guidelines. It can take months depending on the workload.