[andrewstuart]

>> 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?

[Pufferbo]

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

[andrewstuart]

>> 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?

[Pufferbo]

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.