Signals In React | Catching up with the latest trends

It's intriguing to see that almost every JavaScript client framework has now implemented signals.

A pattern that was once deemed old and primitive has become the flagship feature of so many frameworks.

But it seems that the React team is still against the idea as they:
"don’t think it’s a great way to write UI code" as mentioned here:

But this doesn't mean all hope is lost.
After exploring the @preact/signals-react package I've found that there are some incredible possibilities when it comes to using signals in React.

All of the drawbacks of using React state are gone!!

No more prop drilling or prev-callbacks and it even allows direct mutation of the signal value.

Unfortunately, though, that library doesn't integrate well with React's state-based ecosystem and even somehow managed to break React's internal rendering queues("Which I discovered a bit too late").

So I thought that I might have a go at building a signal-based state manager for React.

So after tons of experimentation and testing, I think it is finally ready to be shared.

Here is a very basic example:

import { createSignal } from 'react-use-signals';

export const counterSignal = createSignal(0);

export const handleIncrement = () => {
  counterSignal.value += 1;
};

const Counter = () => {
  const count = counterSignal.useStateAdapter();

  return (
    <div>
      <p>Count: {count.value}</p>
      <button onClick={handleIncrement}>Increment</button>
    </div>
  );
};

And there are plenty more where that came from!!

There are more examples of how to use signals as a store, optimized rendering, selectors, and more.

Feel free to check it out on NPM:
https://www.npmjs.com/package/react-use-signals

And if you're looking for a detailed article on how they work:
https://medium.com/@personal.david.kohen/the-quest-for-signals-in-react-usestate-on-steroids-71eb9fc87c14

Any suggestions or feedback would be highly appreciated.

Comments

[Gianluca]

It would be about time we move to new paradigms, the current state management is stagnant and we, the developers, shouldn't be the ones optimizing for memoization in our components.

[Rense Bakker]

Why not?

[Gianluca]

HTMx is the answer to this question

[Lev N.]

How is HTMX the answer? merely a fancy html injection parser written in plain old Javascript.

[Rense Bakker]

Lol, yea... No 😂

[David Kohen]

You are absolutely right, but sadly it seems that the React Team is so biased towards specific patterns that they completely ignore the opinions of the developers using their product.

[Jakub Keller]

Signals is such an old concept. People go nuts over something so trivial.

[David Kohen]

Well...
Server-side rendering is also a pretty old concept, yet the industry is falling head over heels for it.

But seriously, back when signals were popular, we weren't building these huge single-page applications.

But now a large movement of developers found that signals can drastically increase the performance of their applications, hence the renewed popularity.

[Idris]

I think the reason why react are not adopting signal, is because they want to give developers full power and responsibility of the way there application behave.

[David Kohen]

Maybe so, but it does come at the cost of performance and causes tons of spaghetti code in the process.

[Idris]

And a lot of bugs.

[Gianluca]

They may also be scared of taking drastic decisions at this point, React's adoption is massive and an improper execution could alienate the community.

Everything they're releasing, from concurrency to new hooks, is meticolously planned to avoid breaking changes and offer a seamless dx during the transition.

[Idris]

What you said is true. But most of developers that try signal appreciates it and love it, and even want to continue using it.