-
Notifications
You must be signed in to change notification settings - Fork 64
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
Focusing only on signals interoperability #259
Comments
Given some code like the following: const a = library1.signal(1);
const b = library2.signal(1);
const sum = library3.computed(() => a.get() + b.get());
effect(() => console.log(sum.get()); // 2
a.set(2); // 3 Can you explain in further detail how the computed/effect functions would be written so that this all works together correctly? |
@EisenbergEffect Thank you for your answer. To answer your question, I have written below a very simple implementation of signals that relies (only) on the above Also, maybe we should move the Sample implementation of signals that relies on the above
|
It would be great to get feedback on this from authors of various signal libraries. Because, if it looks feasible, this could be done as a community protocol effort, independent of standardization, giving us interoperability virtually overnight. We've done a few things like that in Web Components, where we created and documented various protocols, and then all the Web Component libraries implemented them in order to be interoperable with one another. |
Hello,
I am opening this issue to suggest a specification that would only focus on making different signal implementations interoperable.
By this, I mean: if I have multiple signal implementations, if I create a signal with one implementation, and I use in it a computed of a different implementation, when the first signal changes, the computed of the second implementation should be recomputed correctly.
With the following code, I think we can achieve signals interoperability.
Each signal just have to expose a
watchSignal
method that returns a watcher.I have implemented this suggestion in our Tansu signal library in this PR
What do you think?
The text was updated successfully, but these errors were encountered: