Build the proposal API on top of alien-signals

[johnsoncodehk]

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. (resolved)

Chart:

[trueadm]

@NullVoxPopuli Did you add prohibited-contexts.test? Does this test need to be updated or is there a genuine issue here do you think?

[NullVoxPopuli]

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

[johnsoncodehk]

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.

[NullVoxPopuli]

Sounds fine since it's solved.
Not sure if proposal text will need to update

[hybrist]

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]

@jkrems yes, I just add a test for this PR to a new branch.

https://github.com/johnsoncodehk/js-reactivity-benchmark/tree/alien-polyfill

[hybrist]

@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.

[johnsoncodehk]

I think the PR is complete!

The implementation has been simplified a lot while maintaining as much consistency as possible with the original behavior. To achieve this, surface APIs have added checks for isState, isComputed, and isWatcher, which will affect performance. The initial performance comparison may no longer be applicable, but the improvements should still be significant.

[pzuraq]

Does this PR support the connected/disconnected callbacks in the spec? Or in other words, is it possible to support something like the behavior of Signalium Relays with alien-signals/extensions built on top of it?

[NullVoxPopuli]

I think my biggest concern with this pr is the external dep.

It should be internalized so that experimentation is easier (nothing against alien signals ofc, just don't want to push breaking changes on y'all)

[johnsoncodehk]

@NullVoxPopuli Sorry for the delay, it's no external dep now. 🙌