Understanding Signals

❤

Finally ❤

Red green yellow

Thank you! The topic explained in very easy way :)

I thought that Preact Signals made them popular :D

P.S. Are you planning to add Signals section to your React course on Udemy? :)

What is or is there an advantage for that over using for example ngrx/store?

when are you going to update the angular course to angular v17 ?

Such a reimplementation is really helpful in understanding the concept! I still dont get the difference between other "pubish-subscriber" patterns in code (Like Observables).

Syntax hideosity and convolution for performance's sake.

Great explanation. It would help to show it with an example of updating the DOM - the environment where most people would use this.

React Hooks were a great inspiration for Vue 3 reactivity system (Evan Vue). Vue uses the Javascript Proxy class to track data changes. Unlike React where after each data change the UI rerenders in Vue 3 in the setup the dependencies are set with ref or reactive the Ui renderes only once and the only the html element wich displays the data change will be rerendered.

Signals might become a web standard. Signals are in the web standardization process. That said Rxjs Observables which are also in the web standardization process will probably never become a web standard.

every framework just having to re-name an existing system. Runes?? really?

This idea of signals reminds me of the observer design pattern, a pattern that has been around since before the web became popular. Other GUI libraries for native applications, such as the Qt framework, have successfully used this pattern. That being said, I still don't understand why this wasn't the original approach from the beginning of React.js. I also don't understand why such a bad library like React has become so popular. 😒

it's useState hook of REACT.

so many names for the same concept... they're all just atoms man: we restrict ourselves to atomic operations only so we can has thread-safe mutable variables (aka state management) which opens the way to "subscriptions" and reactive UI design

also, wasn't svelte's elevator pitch something like "sure it's the least mature framework, but look, it does away with the whole state management BS, you can treat simple variables like they're atoms..."? now it has the same syntax as the rest, but they're called "incantations" now! and when you de-ref them, you're "casting a spell"!

You should learn how to pause your speech. One sentence is never read throughout several minutes. Really exhausting!

Wouldn’t this infinitely grow subscribers array with every read?

Sorry, meteor popularized reactive variables more than 10 years ago: search for „Origins of dependency-tracking auto-running reactivity (Tracker) meteor“

Qwik also uses them, but we hardly see them, it's all via proxies. Angular already has a Signals API, but they are not yet fully plugged in to change detection. 👍They do already work with OnPush though, if we consume a signal in a template, a new emitted value will mark the component as dirty.

I feel the example could have been better. Kinda confusing. When you first define function read(), you also subscribe... then I would called it readAndSubscribe. Calling it "read" alone is a poor naming choice in context trying to explain the logic, IMO. And I would also not call it signals pattern, but rather classic observer pattern in that case.

amazing

Signal proposal in js have subscribers optional

very clear to know how is Singal going on.

huh, so I already implemented signals when implementing my own framework, wow im so good

Your way of implementing signals has many problems and should not ever be built like that:

Every read call pushes whatever the global state of the current reference is pointing to.

Which means that if I try to call setCount() and then signal my subscribers, if any of my subscribers callback functions invokes read(), inside the array of subscribers you will push a null value, since the "current" reference gets set to null after calling effect() once. So any subsequent updates with the provided setter functions will lead to an unstable subscribers array.

Whereas it would be better if setters and readers never pushed inside the subscribers array, and instead had the effect function pushing to the subscribers array.

Now if you really want to achieve angular-like behavior, inside the read function you should check whether you are in setting effect mode or you're just reading the value.

if (current != null) {
// triggered by an effect function call, proceed storing dependency.
subscribers.push(sub);
} else {
// just do nothing
}
// then we can return our value:
return value;