Building a proposal API on top of alien-signals #44
Conversation
|
@NullVoxPopuli Did you add prohibited-contexts.test? Does this test need to be updated or is there a genuine issue here do you think? |
|
I did not add it -- it was implemented with the original spec -- but I did pull it out of a massive test file, as we need to be describing why tests exist, and what they're testing, and why that behavior is important. It is def a behavior question about whether or not folks want to allow synchronous mutation while reading another value. Personally, I don't think this is a good idea, as it prior-reads of the mutated state are now out of date, and if the consumer is entangled with the mutated state, that usually leads to infinite looping when a renderer is involved |
|
We have already solved the problem of infinite loops at the algorithmic level. If synchronous mutations in computed is not handled, it can not pass the Vue core test suite. |
|
Sounds fine since it's solved. |
|
Can you link to the source of the benchmark? I'd be curious to see what the test setup was like. Was it based on https://github.com/transitive-bullshit/js-reactivity-benchmark? |
johnsoncodehk
force-pushed
the
alien-signals
branch
from
0ffa34f to
e6f28d6
Compare
|
@jkrems yes, I just add a test for this PR to a new branch. https://github.com/johnsoncodehk/js-reactivity-benchmark/tree/alien-polyfill |
|
@johnsoncodehk I was asking because that benchmark has some known measuring artifacts for the signal polyfill specifically (see https://x.com/synalx/status/1868235387812053167). So it might be less predictive for this particular PR. That doesn't mean that this PR isn't a performance improvement. But it might just require additional validation before it's clear how it compares. |
|
I implemented a pull model-based createReactiveSystem API based on preact’s approach in stackblitz/alien-signals#41, which can solve the GC problem mentioned by @alxhub. The performance improvement is still significant, but due to the overhead of the proposed's surface API, it is still far from alien-signals. I've update this branch to https://github.com/johnsoncodehk/js-reactivity-benchmark/tree/alien-polyfill. |
…l system" This reverts commit 62b25b4.
|
The GC problem is now solved by a cooling mechanism. Computed will enter cooling in the next microtask every time it loses all subscribers (no longer referenced by dependencies), and warm up (re-referenced by dependencies to receive updates) when the getter is called next time . If computed is triggered every time a microtask is triggered, cooling/warming up may occur frequently, so we may need to implement more reliable scheduling for cooling. The latest benchmark result has been updated to #44 (comment). |
|
Any movement here? |
|
We just released alien-signals 2.0, closed because and this PR approach is outdated. If polyfill is still interested in a solution with alien 2.0 please let me know and I'll try to fix it, thanks. 🙏 |
|
@johnsoncodehk Congrats on the release! I'd definitely be interested in seeing an implementation of the proposal on top of Alien Signals 2.0. That's an important part of our process. If it can be shown that the Alien Signals implementation has better performance characteristics than the current implementation, then I'd also love to see a discussion happen around updating this repo that version (other may have different opinions of course). |
|
I fixed the conflicts with alien-signals v2 integration, the aforementioned cooldown mechanic has been restored since it can now be implemented outside of alien-signals. If we want to solve the GC problem based on microtasks (or similar approach), I can open a new PR to do it so as not to clutter this PR. There is no noteworthy change in the performance test results. The main overhead (compared to pure alien-signals) still comes from the Map object used to implement onWatched and onUnwatched APIs. 
|
johnsoncodehk
changed the title
|
Thank you so much for this work @johnsoncodehk! I believe @EisenbergEffect said offline he was also in favor of this general approach? Does anyone have concerns about moving in this direction? I think maybe I had heard conversations where some application use cases found other approaches to be faster? It's a large change so I'm hesitant for us to merge it in without a bit more conversation / consensus but would love to hear how people are feeling! |
| // would cause it to change value (due to the set inside of it). | ||
| expect(c.get()).toBe(2); | ||
| expect(s.get()).toBe(2); | ||
| if (isAlien) { |
There was a problem hiding this comment.
when are we not alien?
| @@ -0,0 +1,360 @@ | |||
| import * as alien from 'alien-signals'; | |||
There was a problem hiding this comment.
do we get any perf benefits by internalizing the implementation here?
|
Hi, any updates? Can't wait to see the new stuff! :D
Unifying reactivity systems at this level would be fantastic! Big thanks for your awesome work! 🤗 |
We are re-constructing surface APIs based on alien-signals to obtain performance improvements, now faster than most frameworks.
We intentionally relies on the alien-signals package rather than duplicating code in order to easily discover code specific to the signal proposal.
Regarding the differences in test results.
Prohibited contexts - allows writes during computed: The alien-signals algorithm is able to handle computed side effects, so the expected results in the test are now modified to the correct values.type checks - checks types in methods: I'm not sure what I should do to make the current implementation pass these tests, but since this PR is for research purposes only, I don't think this test is worth solving, so I just skipped it.Chart:
(Please note that since this PR is just to explore speed improvements, we will not try to align with all the details in the proposal. If you want to continue exploring this approach please feel free to fork this branch, thanks. 🙏)