-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
[proposal] improve rendering for query without incremental data #241
Conversation
src/QueryFetcher.ts
Outdated
if (!this.snapshot) { | ||
this.snapshot = snapshot; | ||
this.subscribe(snapshot); | ||
this.resolveResult(); | ||
if (fetchHasReturned) { | ||
const responses = Array.isArray(response) ? response : [response]; | ||
const isFinal = responses.some((x) => x != null && x.extensions?.is_final === true); |
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.
deepening the proposed solution for defer facebook/relay#3121 (comment)
prefer to change the logic using hasNext (spec-complaint) instead of is_final (FB specific):
const isIncremental = responses.some((x) => x != null && x.hasNext === true);
if (fetchHasReturned && isIncremental) {
this.forceUpdate();
}
In this way, no code modification is needed to optimize the render in case an incremental query is not used but it could be a breaking change for those using it with other specifications
with this PR, renderer change: when the response doesn't have the hasNext field set to true
when the responsehave the hasNext field set to true, so the response waiting
|
I would like to consider releasing both this PR and the solution to the issue #233 (comment) with version 8.0.0. @Lalitha-Iyer @alex-statsig Could you help me to test it also in your applications? |
@Lalitha-Iyer @alex-statsig released 8.0.0-rc.1 with #233 (comment) and this PR. |
…om the store during the refetch
released 8.0.0-rc.2, with a small fix for incremental data |
released 8.0.0-rc.3, with a fix for #159, now i added the test for it |
Looks like the warning is fixed, and it no longer spams queries during the suspense. It does still seem to send the query twice (one time on initial mount, one time when the suspense finishes), but that's probably semi-expected with "store-and-network". |
Hi, @morrys thanks for the proposal and for implementing this. I verified when data is null, we now render only two times ( data=null & isLoading=true, data provided & isLoading=false ) 👍 However, when some fields are already cached, and with |
@Lalitha-Iyer @alex-statsig released version 8.0.0 https://github.com/relay-tools/relay-hooks/releases/tag/v8.0.0 Rendering is optimized when the query does not fetch data from the store with the store-and-network policy. From a first analysis, the third render is essential to avoid possible update problems that do not derive from the execution of the query which is still pending. To be evaluated if it is possible, without modifying the relay-runtime, to identify that the subscription was triggered by the query response. |
#238
to adapt the check to this PR and defer
facebook/relay#3121 (comment)
https://github.com/facebook/relay/blob/9ecd6195d83c3f9127067d4c4199979ad4e5f66e/packages/relay-runtime/store/OperationExecutor.js#L1690