Hacker News Reader

Comment by ksherlock | Hacker News Reader

I agree. But look at Preact's signal documentation -

"In Preact, when a signal is passed down through a tree as props or context, we're only passing around references to the signal. The signal can be updated without re-rendering any components, since components see the signal and not its value. This lets us skip all of the expensive rendering work and jump immediately to any components in the tree that actually access the signal's .value property."

"Signals have a second important characteristic, which is that they track when their value is accessed and when it is updated. In Preact, accessing a signal's .value property from within a component automatically re-renders the component when that signal's value changes."

I think it makes a lot more sense in a context like that.

View on HN

>> In Preact, when a signal is passed down through a tree as props or context,

I have found that passing props makes React-like applications very complex and messy and props are to be avoided as must as practical.

The mechanism for avoiding props is Custom events.

It concerns me to see the concept of signals being passed as props when surely signals/events should be removing the need for props?

You don’t need to pass a Preact signal as a prop to get reactivity. If you’re using Preact, signal references will make your component reactive by default, and if you’re using React you can introduce reactivity by way of the useSignals hook or a Babel plugin. (1)

React signals have become my go to state management tool. So easy to use and very flexible.

1: https://www.npmjs.com/package/@preact/signals-react

>> React signals have become my go to state management tool.

I've ditched almost all state in my React apps except state local to the component.

Custom events do all the work for passing information around the application and directing activity.

What do signals give me that events do not?

I’m also a fan of local state, but there are some cases where it makes sense for a bit of global state - mainly user context.

However you can use signals for local state as well and they work amazingly. Being able to assign a new value to a signal without having to go though a setter is a way cleaner pattern, in my opinion.

The other use cause is for communication between micro frontends. It’s so nice to just be able to import/export a signal and get its reactivity. Before them, I would create a pub/sub pattern and that’s just not as clean.

Reply on news.ycombinator.com