This repository has been archived by the owner on Dec 31, 2020. It is now read-only.
fix: render reaction would dispose too early if observable data was changed before first useEffect
#328
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixed an issue where, if an observable changed between initial render and useEffect, the render reaction would be disposed. This caused any computed values to be cleaned up as well, and become untracked.
It was a bit tricky to reproduce in a unit tests, as they don't run effects async, but see the following screenshots of before and after, and the unit test.
In the screenshot, observerHeader uses amount of todo's left.
Then directly after mount, but before the useEffect happened (
create HEADER
), we would first change the collection (causing the render reaction to be disposed), and then set up an unrelated reaction. Since the computed value is suspended at that point, it will recomputed.After the fix, todo's is computed only once, as should be done.
It seem that in the code somebody already thought about this case before, as a field
changedBeforeMount
was introduced earlier, but it was never set or read.I've made those fields non optional; a) it would probably have prevented this bug, and b) this is in general faster as as JS engines optimize objects with a fixed shape better.