Modifying Signals From Within an Effect #82
Description
Hi, and thanks for maintaining this library of utilities! It's been really helpful for learning about how the Signals spec works.
Perhaps what I'm doing is an anti-pattern, but I have found it useful to wire signals together like so:
const signal1 = new Signal.State(0)
const signal2 = new Signal.State(null)
effect(() => {
signal2.set(signal1.get())
})My actual usecase has a few more moving pieces but essentially boils down to the above.
It involves Web Components that pass data to each other via HTML attributes:
<!-- Parent Component -->
<my-counter></my-counter>
<!-- Child Component -->
<my-pretty-text text="10"></my-pretty-text>Each Web Component manages its internal state using signals. So, <my-counter>, has a signal called count.
Each Web Component can also take in attributes, which are converted to signals. So, <my-pretty-text> has a signal called text.
In this example, <my-counter> ends up rendering <my-pretty-text>, passing in the current count in the text attribute.
So, these HTML attributes present a boundary that prevents me from wiring the two signals together with Signal.Computed.
What I've noticed about effect() and batchedEffect() is that they don't always all fire, especially if I set signals in "upstream" effects.
For example, in:
When the for loop is complete, more pending signals could exist. Instead of only checking watcher.getPending() once, I've opted to check again and again until it's empty.
What are your opinions of this usage pattern? Is it sane?