Closed WebReflection closed 2 years ago
P.S. the reason I believe this is a regression is that here the example explicitly states the intent:
import { signal, computed, effect, batch } from "@preact/signals-core";
const counter = signal(0);
const double = computed(() => counter.value * 2);
const tripple = computed(() => counter.value * 3);
effect(() => console.log(double.value, tripple.value));
batch(() => {
counter.value = 1;
// Logs: 2, despite being inside batch, but `tripple`
// will only update once the callback is complete
console.log(double.value);
});
// Now we reached the end of the batch and call the effect
FWIWI I've based 100% code coverage on most of your examples (and more) so, thanks folks, this project has been both inspiring and fun as R&D side-project.
Oh good catch! Agree, with you that doesn't look right and is not intentional on our part. Maybe an area where our test suite is not exhaustive enough yet. Checked the history and the regression was introduced in #127.
Thanks for reporting this issue and happy to hear that you enjoy playing around with the code š
feel free to copy/paste my tests which do 100% code coverage for usignal and might help having code coverage in here too (I haven't seen that running in PRs) ... you want to look at test/preact.js and test/test.js (but if you want to use test/leak.js too go ahead, as I am planning to keep testing usignal, preact, and solid there (at least) š
I have been testing preact/signals-core together with usignal and solid-js but after installing latest my tests, which run just fine with latter two libraries and used to run just fine before latest release, now fail with preact.
The test in case contains this code:
If you'd like to test yourself:
If this regression was actually an intentional change, it would be great to understand how come preact signals decided to behave differently from solid-js there (I am just the last one playing around with signals here, I don't have strong opinion about anything š)
Thanks.