Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modifying Signals From Within an Effect #82

Open
vinsonchuong opened this issue Sep 11, 2024 · 2 comments
Open

Modifying Signals From Within an Effect #82

vinsonchuong opened this issue Sep 11, 2024 · 2 comments

Comments

@vinsonchuong
Copy link

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:

for (const signal of watcher.getPending()) {

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?

@NullVoxPopuli
Copy link
Collaborator

NullVoxPopuli commented Sep 11, 2024

thanks for your question!

Do you, perchance, happen to have a stackblitz or some oss code somewhere with your web components (or a reproduction somewhere)?

there are some unknowns I have about the details of how the components are interacting, and I feel like it'd be helpful to see their code -- and maybe even add them as tests in signal-utils' test suite! 💪

(or would you be willing to submit a PR that only adds tests that re-create your scenario?)

@vinsonchuong
Copy link
Author

Hello!

I've put together a minimal example here: https://github.com/vinsonchuong/web-components-signals-demo

When you start the HTTP server and open the page, you will see two counters and an increment button. The two counters are meant to stay in sync.

Please feel free to ask any questions about any part of the code, and I'll answer as best as I can!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants