-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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 CM tearing #1455
fix CM tearing #1455
Changes from 1 commit
b986030
9c0520f
3d52f3a
647195d
d248d0a
eb6f8cf
6647836
5ed652c
16a6253
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -350,13 +350,11 @@ describe('React', () => { | |
} | ||
) | ||
|
||
let sawInconsistentState = false | ||
let lastRenderInconsistentState = false | ||
|
||
const Child = ({ parentCount }) => { | ||
const result = useSelector(({ count }) => { | ||
if (count !== parentCount) { | ||
sawInconsistentState = true | ||
} | ||
lastRenderInconsistentState = count !== parentCount | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand this change. The whole purpose of this test was to ensure the selector never sees inconsistent state, not just on the latest render. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Because we NO more read the last state in the render phase, the "parent-child-issue" is resolved with 2 render, as every change of the store make 2 event-callback one on the parent and one on the child. That hack while resolve the "parent-issue" with 1 render less, broke the changes normal queue on the the componente, that produce tearing on CM where every component could rendered in a random way, jumping the "changhes queue" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. please try the demo of @dai-shi with my version and with old one. you will see the differences on a fast store changes, with slow render. |
||
|
||
return count + parentCount | ||
}) | ||
|
@@ -372,7 +370,7 @@ describe('React', () => { | |
|
||
store.dispatch({ type: '' }) | ||
|
||
expect(sawInconsistentState).toBe(false) | ||
expect(lastRenderInconsistentState).toBe(false) | ||
|
||
spy.mockRestore() | ||
}) | ||
|
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.
To be CM friendly, could we do something like:
So we could do this, for example:
In React docs, it's using something like:
const value = resource.read()
where
read()
either returns the value or throws so it can bail out before the selector is set. Not sure if here is the best place to do it, but yeah, with CM not everything "thrown" is an error.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.
sorry i think that thow promise to comunicate with Suspense does NOT matter with useSelector, that has to select a state without tearing on render. that's another problem.