-
-
Notifications
You must be signed in to change notification settings - Fork 617
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
fix(core): recompute dependents in edge cases #2742
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
Size Change: -72 B (-0.08%) Total Size: 88.9 kB
ℹ️ View Unchanged
|
Preview in LiveCodesLatest commit: 79adf23
See documentations for usage instructions. |
src/vanilla/store.ts
Outdated
): AtomState<Value> => { | ||
// See if we can skip recomputing this atom. | ||
if (!force?.(atom) && isAtomStateInitialized(atomState)) { | ||
if (!force && isAtomStateInitialized(atomState)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dai-shi I'm not sure why but removing !force
from this makes all tests pass... do you know why this would work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cd67e40 --- yeah. I think we miss some optimization tests. I'll try to add one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it actually seems fine, because in normal cases (no reordering), dirtyAtoms doesn't include dependencies. So, no performance drawback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might exist some other edge cases we miss now, but the change is small and looks reasonable.
Thanks to @Pinpickle
Memo: Originally, I was thinking about removing from dirtyAtoms to avoid recomputing the same atom again, but we actually need to remove from topSortedAtoms, but then it doesn't add to changedAtoms. Because readAtomState recursively checks epoch number even if it's marked as dirty, it actually doesn't recompute thanks to dropping force
.
This change breaks my app related to some atomEffect usage, anyway I have to figure out why and post an minimum viable repro. |
Oh... Yeah, a repro would be helpful and we need a test case to investigate further. |
I installed both I might be missing some test cases. Please create a minimally viable repro and I can take a look. |
I also got exceptions with
|
It feels like a bug with this PR. Hope someone can create a failing test case! |
FYI, I fixed the issue (Uncaught RangeError: Maximum call stack size exceeded) in my app. It seems I may have introduced "circular dependencies" between an atom and the effect of it, like below, const atomA = atom((get) => {
get(atomAEffect);
})
const atomAEffect = atomEffect((get) => {
get(atomA)
}) I think I had exploited a hidden feature by accident. This "feature" is apparently not allowed since version 2.10.1. I fixed my code by eliminating these circular dependencies. I am now surprised that my app worked 😂😂. I remember the purpose of organizing code like this is to colocate logically atom and its effect, and make sure I do not forget to mount the effect. Because when Is that usage legal ? If not, what is the best practice ? |
Fix #2738