Here is the prototype of the signals lib: #49091

Here is the prototype of the signals lib: #49091

So basically, it is the Reactivity API from Vue with different function names?
Do you have any idea yet how we use it in our HTML templates? Will it be always the function call to extract the value?

In Vue, it is possible to just use the property name, which makes it easier.

I hope we'll one day make the list!

I would argue "the best of two worlds". There is a simplicity mirage when people see signals from far away, but when they get near, they understand how ugly and bad it is. For example, having two types of "for" is a bad design, no matter how you look at it.
https://www.solidjs.com/tutorial/flow_index

Having two types of "for" is a side effect of fine-grained reactivity. Angular will eventually need such bad designs as it is baked into fine-grained reactivity.

For these kinds of designs, even it's impossible to write lint to catch wrong usages. It is a nightmare for big projects.

Or sometimes you need to manage your dom rendering changes yourself instead of the framework to take care of that.

https://www.solidjs.com/docs/latest/api#createrendereffect

And solid can cause max call stack limit if a project is big enough. Just imagine something like a role or permission that is used in every part of the application change.

https://stackoverflow.com/questions/7826992/browser-javascript-stack-size-limit

For every effect you keep adding, your memory usage will increase multiplied by the number of signals used inside that effect. Bcs every signal keeps track of its effect and its usage reference. That's a big no for low-powered devices.

Clean-up of the lost references effects and signal usages also is another story. If someone asks you if having a framework that keeps adding and removing to arrays on every function usage in your application, and it does it multiples by the number of signals in your application, is it a good framework? What would be your answer? And I want to remind you that every line of your template that uses a signal is an effect too!

Rx-angular solved the issue of the complexity of rxjs. I don't understand why we can't build on top of that!

For anyone who thinks the signal is a good design choice, I suggest trying to recreate some part of their application with it.

But rather than being forced to use rxjs you have a simpler option and 3rd party libs that do it much. Better.

Getting rid of Zone.js is a good direction but Signals looks like (another) revolution in the Angular world.
Also, it's really dubious that implementation with this syntax is well-suited to Angular.
IMHO decorators, as we see in MobX, are better fitted: https://mobx.js.org/enabling-decorators.html#enabling-decorators-
We also have a ready-to-use (zone.js-free) solution from @BioPhoton (Michael Hladky) : https://www.rx-angular.io/
Please consider going this way first because Angular is heavily related to RxJS and this is ok. Otherwise, we will create the same mess as we saw in React - Redux and Hooks.

Yeah, it would be interesting to know what other options were studied. And Rx Angular or NgRx were not good enough in comparison to signals.

+1 for MobX decorators and rx-angular approach, rather than yet another "revolution" in Angular.

I do need real HMR, and anybody who does more or less complex enterprise-grade application does. It was reloading whole your app without refreshing the browser page, nothing more. It's not HMR at all, in any sense. Just read through that issue, no need to continue an offtopic discussion here.

I was actually thinking along the lines of what @dgp1130 said I think after esbuild hmr will come into focus more, so it's not like the team is doing nothing, they are at least making progress toward it. You're a developer too, you understand, these things take time and you can't just choose what you want to work on whenever, I'm sure they want to give you proper hmr support, why wouldn't they want it? So there must be a reason and I don't think being toxic about it helps, a lot of things that we are getting now in Angular have been asked for years BUT WE ARE STARTING TO GET THEM, your hmr time will come, just support what's being done right now.

That's what happen for years now. They have "other priorities" like Ivy and now... what they call "Signals".
It's just an RxJS BehavriorSubject + shareReply + distinctUntilChanged out of the box. So why then all the fuss about? Just provide a new RxJS creational operator, that's it. But guess what, it won't change much. Because it's not the reason of failure.

You just illustrated why signals are great, not only do you have to use those extra operators to achieve the same thing, you have to learn them as a new developer and also be aware of any gotcha that can happen, also then you expect Angular to create a custom method just for that, why not use something the js ecosystem is adopting , if you want to use RXJS still and know how to no problem but you can see it already makes Angular simpler because if you get a new developer instead of telling them use all those operators, just create a signal, and now if they want to use solid or something else the knowledge is re-usable in much less time.

Yes I want to use RxJS and I want Angular to improve their integration with RxJS instead of making up new things, that could turn out to be a failure in another 7 years. Another operator needed? No problem, make it. But not a hook-like "something else".

RxJS is synchronous as long as there's nothing async present in the pipeline like a delay.

import { BehaviorSubject } from 'rxjs';

const s = new BehaviorSubject(1);
let a = undefined;
s.subscribe((v) => (a = v));
console.log('a1', a); // 1
s.next(2);
console.log('a2', a); // 2

But it's easy to get something async into a pipeline that will the break all previous assumptions about if it's sync or async

And by "constructive" you mean to agree to you without arguing? Ok

Not at all. There's a difference between an exchange of ideas, and "arguing". You're just here arguing, with a "I hate this, you suck" energy. That's not constructive.

The main question is simple: why to add another concept different from RxJS, if it can me just +1 creational operator based on RxJS (it's extensible, you know?) that would combine BehaviorSubject, shareReply, distinctUntilChanged, and whatever else.

Ok, let's think how you could replace a single signal with rxjs implementation. For each signal you'll need to have a separate BehaviorSubject plus piped observable (shareReplay + distinctUntilChanged) for the optimization purposes to mimic signal's behavior. In this case you could use this observable in streams and use subject to read current value.

Now you need some computed from those "signal" observables. Ok, mapping them and also piping to shareReplay + distinctUntilChanged. But, hey, how to read current value from it if you need it in some non-rxjs code? Ok, adding tap and saving the value to some property. Great! Now instead of 2 signals and 1 computed (3 lines of straightforward code) you have 2 subjects, 3 piped observables, one simple property and tens of lines of boilerplate code.

And also don't forget to add dozens of | asyncs in the component template.

Just like it's done for EventEmitters. They are part of Angular and aware of Component lifecycle, there's no need to subscribe or unsubscribe, and still it's based on RxJS. Right? I'm not saying "don't hide the implementation logic", I'm saying that maybe - just maybe - Angular doesn't need another one reactive solution apart from RxJS that's already there.
It could be something similar to how they do it in NGXS:

@Signal(...) value$;
// Or maybe 
value$ = new Signal<...>(...); // Signal extends BehaviorSubject just like EventEmitter extends Subject

// It's already aware about the component lifecycle, shareReplay + distinctUntilChanged is baked in.
// And you can extend it with _more_ logic if you want,  but it's still RxJS BehaviorSubject.

The main question is simple: why to add another concept different from RxJS, if it can me just +1 creational operator based on RxJS (it's extensible, you know?) that would combine BehaviorSubject, shareReply, distinctUntilChanged, and whatever else.

Ok, let's think how you could replace a single signal with rxjs implementation. For each signal you'll need to have a separate BehaviorSubject plus piped observable (shareReplay + distinctUntilChanged) for the optimization purposes to mimic signal's behavior. In this case you could use this observable in streams and use subject to read current value.

Now you need some computed from those "signal" observables. Ok, mapping them and also piping to shareReplay + distinctUntilChanged. But, hey, how to read current value from it if you need it in some non-rxjs code? Ok, adding tap and saving the value to some property. Great! Now instead of 2 signals and 1 computed (3 lines of straightforward code) you have 2 subjects, 3 piped observables, one simple property and tens of lines of boilerplate code.

And also don't forget to add dozens of | asyncs in the component template.

Well, it may be a bad news for some, but when you start using RxJS somewhere in your app, it is much easier to use it everywhere to avoid what you've discribed. Add a declarative pattern to it and (after you get used to it), in my personal opinion, it will become incredibly confortable to use.

Here's how it's gonna be, remember my words:

1. They'll say "we invented new cool thing, Signals! It IS NOT a replacement to RxJS, rather a great addition!"
2. (After 6 months) "Angular Signals are better than RxJS and here is why"
3. (After anohter 6 months) "RxJS is deprecated in favor of Angular Signals, but here are our semi-working schematics to ease a migration process for you"
4. (After anohter 6 months) "We have re-written our Engine, now it's called Angular PopCorn, all libs should migrate or else they won't work"

Hopefully HMR is done by that time.

@menosprezzi The concepts signalFromObservable() and observableFromSignal() are in the planning.
So there is going to be full interoperability between the two concepts.
They complement each other and do not take anything away!

What signals really open up in the feature is an alternative to zoneJs. I'm really looking forward t that future!

@SanderElias nice! But I mean that implementing InteropObservable interface you can use the signal directly in your rxjs pipes if you need.

For instance, lets say that angular changes the @input to wrap values into a signal, you can still use it with the rxjs's reactive utils if you need:

class MyCmp {
  @Input()
  value: Signal<number>;

  ngOnInit() {
    const aNativeObservable$ = this.myService.get();
    combineLatest([this.value, aNativeObservable$]).pipe(/* and so on :D */ ) 
  }
}

This will ease the migration between both!

@menosprezzi The concepts signalFromObservable() and observableFromSignal() are in the planning. So there is going to be full interoperability between the two concepts. They complement each other and do not take anything away!

What signals really open up in the feature is an alternative to zoneJs. I'm really looking forward t that future!

I think signalFromObservable() is really essential to have in place when this lands. It also has to automatically handle the subscription. If this gets done right it will be a really nice solution.

wou, what @menosprezzi said is interesting

They mentioned it 2 times:

Significantly improved interoperability with reactive libraries such as RxJS.

Bidirectional integration story with RxJS reactivity

I think it means that they are taking care of it and you don't need to worry about your existing code, relying on RxJS. Also, this tweet might be helpful

And if you're an RxJS master, you'll be able to leverage our RxJS interop to compose Observable inputs, queries, lifecycles into your streams.

@e-oz Sorry...

No @IRod22 you shouldn't be sorry, because you are right: there will never be "magic", even though they claim there is, like with NgUpgrade. Any interop will help us only partially, but there definitely will be a need to worry about existing code.

@BruceWeng Yes, they will be available wherever you want to use them. You can use them in services and functions and wherever else you might need a reactive primitive.

the main point is you don't need to handle subsription/unsubscription with signal compare to Rxjs Subject

Thanks! Came here to ask the same question! Not needing to subscribe/unsubscribe would be awesome.

@ntorrey yeah imagine not having to do | async and deal with default null value

the main point is you don't need to handle subsription/unsubscription with signal compare to Rxjs Subject

That’s sort of my point. What benefit would a BehaviorSubject provide if a Signal can be easily transformed into an Observable? Seems like it’d save people from the private BehaviorSubject + getter/setter pattern I’ve seen in quite a few codebases.

@Cjameek you'd still want to have Subjects to handle streams of events or asynchronous events. Eg: a search input with debounce.

@Component({
   template: `
      <input type="text" (change)="query$.next($event.target.value)" />
      <p>Debounced query: {{ query() }}</p>
   `
})
export class SearchComponent {
   readonly query$ = new BehaviorSubject('');
   readonly query = toSignal(this.query$.pipe(debounceTime(250)), '' /* maybe default value since signals are synchronous */);
}

why signals if we have already reactivty via Rxjs?
other frameworks are missing Rxjs integration, that's why I guess they implemented Signals as a core feature in their library.
maybe I'm wrong

One important question. What about all rxjs stuff that is introduced in simplest examples like @Output and EventEmitter. What about router events, reactive forms, httpClient. Will they move away from rxjs? That is really important thing to know to properly aproximate new learning curve

Rxjs is awesome, I use it also in Vue a solidjs, mapping rxjs observables to their signals.
Signals are simpler for sure, but also much less powerful.

And also, ecmascript is considering including native observables, they are already in stage 1.

I think with observables is going to happen like with promises 10 years ago.

Promises only existed in jQuery and libraries and finally were natively implemented in js.

why signals if we have already reactivty via Rxjs? other frameworks are missing Rxjs integration, that's why I guess they implemented Signals as a core feature in their library. maybe I'm wrong

I think this is more of an internal implementation for updating the DOM. Right now every change detection cycle requires a scan of all the data model to see if something needs updating. This is the zone.js model; it encapsulates all the javascript tasks and tells the framework when the tasks are done, then the data model scan. It is expensive and has quite a few gnarly issues that we have to work around. The signal implementation would, if I understand it correctly, have each property of the data model subscribed to by the dom manipulation system to know when something changes.

From the user side, these primitives can be useful for simple data manipulation and update situations, which is most of the time. For more complex data structures and data flows full of asynchronous events, rxjs has more tools for dealing with them, along with the complexity and learning curve. Hard problems require powerful tools, simple problems are best with simpler tools.

I think actually the learning curve will be simplified probably the end goal will be that you don't have to learn rxjs to use Angular but you can use it if you want and are willing to learn.

Exactly. If there's an EventEmitter -- still based on RxJS -- why to add another "reactive primitive"? It also unsubscribes and automatizes things for you.

building a Signal out of rxjs building blocks is practically free

Also from conceptual and learning point of view.
Could be something like:

value$ = new Signal<...>(...); // Signal extends BehaviorSubject just like EventEmitter extends Subject.

Or, the team could spend energy on improving e.g. debugging of RxJS via e.g. some kind of panel in Angualr DevTools. Or building up new operators and abstractions based on RxJS. In other words, improving the RxJS integration.

That's too optimistic. I can't remember a single "RFC" where team would change their decision. If they published something - it's already decided. The only useful thing we can do here is to remind them what cases they didn't test.

Improving on RxJS seems like a good alternative option.
Indeed, there are certainly different possible routes that can/should be considered, discussed and researched.
But I agree with @e-oz that #49091 means they internally have already done that (and following https://twitter.com/pkozlowski_os I've read that happening) and for now have taken the decision to explore the signals route because it holds (most) promise in their opinion.
Up to all of us over the next few months/year to try it out and see to what degree that holds true; and IF not, see how they adapt course.

Which is currently a much "weaker" version of rxjs based effects for async stuff. So I guess it should somehow play together

What I will also like to see is how would it play with many state managements concept of effect functions. Many effects are not based on value change but based on actual DOM event and only using current value of the state (or selector). Currently there are many problems like the diamond problem or batching problem which can be solved with denouncing (making it async) which as a result make effects using selectors more complicated. It seems signals can solve those problems entirely if they are lazy, batched and always updated.

It seems signals can solve those problems entirely if they are lazy, batched and always updated.

Yep, this is definitively a nice property of the signals approach. Especially with the proposed implementation where signals / computed are lazy by default and effects are scheduled to run in a separate JS stack frame.

It seems signals can solve those problems entirely if they are lazy, batched and always updated.

Yep, this is definitively a nice property of the signals approach. Especially with the proposed implementation where signals / computed are lazy by default and effects are scheduled to run in a separate JS stack frame.

The only thing I am missing is how the signal's effect (sync regular code) can be "merged" with async rxjs code requiring most updated signal value. Currently in places an effect function requires a new microtask to access denounced selectors values a chain of those effects will run each in its own microtask. Will signals be able to make it sync? Or the same concept but easier to handle? I kind of can't wrap my hand around it - as signals and computed are sync while signal's effects are kind of async by nature if I understand correctly.

Probably use of custom scheduler, but this should partially be handled by signal.toObservable() or something like this maybe?

This looks like ChatGPT

Yes, always takes expert advice! :)

Should Angular move to Signals?

ChatGPT:
_I'm not entirely sure what you mean by "signals." If you're referring to a specific technology or programming paradigm, please let me know and I can provide a more specific answer.

Assuming you're referring to signals in a broader sense, such as a system of communicating between components or modules within an application, my answer would depend on the specifics of the situation.

Angular is a popular web application framework that provides a lot of built-in functionality for building complex, scalable applications. It uses a component-based architecture, which allows you to break down your application into smaller, reusable pieces. Components can communicate with each other using a variety of mechanisms, including input and output properties, services, and observables.

If you're currently using Angular and are considering switching to a different approach for component communication, it's important to carefully evaluate the pros and cons of any alternative approach. Signals may be a valid option in some cases, but they may not be the best choice for every situation.

Ultimately, the decision of whether to use signals or any other approach for component communication depends on your specific needs and goals for your application. If you're unsure which approach is best for your situation, it may be helpful to do some research and/or consult with other developers who have experience with similar projects._

ChatGPT results depends upon user's input. Dump input, Dump answer. Smart input, smart answer.

Man I just want good future for Angular and us, the developers

So do I, and so does everyone here. And each person may have a different perspective on what that means to them. And that's ok. Each person's perspective is valid, but you've been jumping down people's throats if they have an opinion you don't agree with. Just be civil, and we'll work together towards a brighter future.

What did I say wrong? Re-read my comment. What's invalid there? Don't take it personal, please, it's not about you. Allow people to have their own opinion. P.S. I'm sorry if I hurt you though

Well, if you want functional everything, TSX, Redux, hooks, etc., why don't you just use React, Solid or Vue?

Not only does that misrepresent what I said (I said more functional, not functional everything) but it's also basically saying get lost and use another framework if you want it x way. That's hostile and not very inclusive of others' ideas. Whether you meant it that way or not.

But to your point on decorators being added to the ecmascript spec, they are, and that's great, but they're more limited than what TS' prior implementation was (e.g. using decorators in function params). And that's sort of what I meant by limiting how you can use signals in that way may be a bad trade-off.

First, I understand your point. But I also see what makes Solid so successful which is the focus on primitives. Angular also needs these primitives and once it's exposed to developers, we can build on top of it. Functions just compose better.
I think there is always an option to use them inside decorators. Check out this project https://github.com/lume/classy-solid

And the last thing, I would miss creating helper functions together with inject fn, if not exposed. Just my current view.

What framework is this???

What framework is this???

@tayambamwanza This is a reactive JS execution environment built with dependency compilation-time semantic analysis and runtime Proxies.
https://github.com/FEFF01/WEBX

Hold my beer!

<div id="root">
  <div id="form">
    <input id="nickname" value="Jin" />
    <button id="clear">Clear</button>

    <label> <input id="greet" type="checkbox" checked /> Greet </label>
  </div>

  <p id="greeting">...</p>
</div>

// Take references to elements
const root = document.getElementById("root") as HTMLDivElement;
const form = document.getElementById("form") as HTMLDivElement;
const nickname = document.getElementById("nickname") as HTMLInputElement;
const greet = document.getElementById("greet") as HTMLInputElement;
const greeting = document.getElementById("greeting") as HTMLParagraphElement;
const clear = document.getElementById("clear") as HTMLButtonElement;

// Setup invariants

Object.assign(root, {
  childNodes: () => (greet.checked ? [form, greeting] : [form]),
  style: () => ({
    zoom: 1 / devicePixelRatio
  })
});

Object.assign(greeting, {
  textContent: () => `Hello ${nickname.value}!`
});

// Set up handlers
clear.onclick = () => (nickname.value = "");

@nin-jin In a reactive JS & HTML hybrid language execution environment, it can be written like this.

let nickname="EF";
let showGreeting=true;

document.body.appendChild(
    <div id="root">
        <div id="form">
            <input id="nickname" value=@(nickname) />
            <button 
                id="clear" 
                onclick=function(){nickname=""}
            >Clear</button>
            <label>
                <input id="greet" type="checkbox" checked=@(showGreeting) /> 
                Greet
            </label>
        </div>
        @:if(showGreeting)
            <p id="greeting">@(`Hello ${nickname}`)</p>
    </div>
)

I hope that the development process of frontend frameworks does not require more hacks, and the ultimate goal of frameworks is to enable developers to write UI interactions just like writing JS logic.

Yes, I was looking at some examples and, I'm slowly convincing myself to the Signals too :)

Another thing worth mentioning is what's the difference between:

const state = signal({a: 2, b: 'test'});

const state = {
  a: signal(2),
  b: signal('test')
}

And why should we use one over the other and when

Good question. And also do changes to the props of state objects trigger the signal updates. I guess if it's going through the .set() function, then it forces immutability anyway and will always trigger the update algorithm.

@Harpush This video can summarize the two cases you mention https://www.youtube.com/watch?v=GEu8hc3RKpw

The second approach is more appropriate for a State Management since each "property" of the State object can be referred to as a "Slice". Updating a Slice shouldn't signal (no pun intended) the other Slices

I think this requires real thought. On the surface it seems like a no question that option 2 is better. But if try and think of the actual usage I am not so sure. A simple example:

const state = signal({one: 2, two: 'test'});
const one = computed(() => state().one);
const two = computed(() => state().two);
state.mutate(s => s.one = 8);

// ----

const state = {one: signal(2), two: signal('test')};
const one = state.one;
const two = state.two;
state.one.set(7);

In both case one and two will update (the result) in the same way and won't trigger unnecessary further recompute or rerender. The only difference is that option 1 will run one when two changes and vice versa... but this is cheap and actually resembles ngrx selectors.
Currently option 2 still wins but it is less obvious.

Now for a more extreme scenario. I have entities in store bound to virtual scroll in UI. You can add entities, remove and update properties inside. Lets take addition of 1000 entities each with 10 properties inside. The UI will render only 10 of them due to virtual scroll.
Signals are lazy and that's awesome but there is one caveat - in option 1 we will create one signal and in option 2 we will create 1000 * 10 = 10,000 sugnals. Now this can affect performance negatively pretty easilly.

Now I am not sure which way is better and if there is one correct answer to begin with.

I'm pretty sure, yes.