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
|
|
| Playground | Link |
|---|---|
| React demo | https://livecodes.io?x=id/AQGQ99S6C |
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.
@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.
cd67e40 --- yeah. I think we miss some optimization tests. I'll try to add one.
There was a problem hiding this comment.
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.
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. |
Fix #2738