Add key to data-on-signals-change

[bencroker]

It might be useful to be able to listen for when a specific signal changes, for example:

<div data-on-signals-change-foo="alert('foo changed')"></div>

[delaneyj]

this need more thought, what about if you want more keys? would an event be better instead? This seems like a discussion for now

[bencroker]

My thinking is that data-on-signals-change-foo would be triggered whenever foo or foo.bar changes, allowing you to listen on nested signal changes. If you want another key, just add another attribute (data-on-signals-change-baz).

[bencroker]

Moved into #587 for implementing.

[JeremS]

In signal parlance, wouldn't that be declaring effects?

[andersmurphy]

So reading up on this a bit more. It's effectively an effect. You could currently do this withdata-computed-* but the downside is that stores the result as a signal. The preact signals library we are using already has the concept of effect.

To run arbitrary code in response to signal changes, we can use effect(fn). Similar to computed signals, effects track which signals are accessed and re-run their callback when those signals change. If the callback returns a function, this function will be run before the next value update. Unlike computed signals, effect() does not return a signal - it's the end of a sequence of changes.

So this might just be a question of exposing it. Would it make more sense to call this data-effect as we already have data-computed?

[bencroker]

Why introduce a new attribute when we already have and can extend data-on-signals-change?

[andersmurphy]

Ahh missed we had data-on-signals-change already, that makes sense for naming then.

So done a quick and dirty bit of exploration and I've managed to build a super crude version tapping into preact effects.

data-effect = $someSignal ; "alert('hello!')"

Should be easy enough to go from that to:

data-on-signals-change-somesigna = "alert('hello!')"

There would still be a question of listening to a namespace.

The question is, is that the way we would want to go? data-on-signals-change uses events rather than being part of the signal graph as far as I can tell. My gut tells me building on the effect system is probably cleaner than adding a layer of events, but I could be completely wrong.

[bencroker]

The event that is in place now should work well for this addition. I’ve moved this to #587 for implementing.