-
Notifications
You must be signed in to change notification settings - Fork 4.7k
DataViews: Add overlay to table layout when loading to prevent flickering
#74572
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
base: trunk
Are you sure you want to change the base?
Conversation
|
Size Change: +561 B (+0.02%) Total Size: 3.05 MB
ℹ️ View Unchanged
|
| data={ data || EMPTY_ARRAY } | ||
| isLoading={ isLoadingData || isLoadingNotesCount } | ||
| isLoading={ | ||
| isLoadingData || isLoadingNotesCount || ! hasResolved |
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 is an underlying issue here with how selectors work and the isResolving might not be the best indicator, thus this change.
When we call the useEntityRecordsWithPermissions internally we call the core data selector, but here we call synchronously the existing selector that might have not been resolved yet. In that case the selector returns an empty array and the isResolving is still false (it's updated later in the event loop).
Should we update the isResolving in such cases when a selector hasn't been resolved? Is it possible and does it make sense?
Should the selector return null if it hasn't been resolved? Although this still wouldn't solve the issue to reliably use isResolved in the sense of isLoading as I think it's expected.
Any thoughts @jsnajdr or @youknowriad ?
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
table layout when loading to prevent flickering
|
This seems closely related to #74122. Is there a way we could tackle these issues together? |
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.
I think we should also update data to displayData on the BulkSelectionCheckbox given that the table body also uses it. If we select all and then search for something that is a subset of the selection we can see the checkbox go off and on again during the loading.
jorgefilipecosta
left a comment
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.
Left some minor comments, but things worked well on the tests I did.
| enabled: !! actions?.length, | ||
| } ); | ||
|
|
||
| // Preserve previous loaded data to show them blurred and |
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.
Nitpick: loaded data to show them blurred -> loaded data to show it blurred.
What?
Resolves: #74074
Right now in
tablelayout we show the headers (th) when loading new data. When we load data the spinner shows and while it's expected, it's a bit jarring. This PR adds an overlay effect if we already had loaded data and make a new request to prevent this 'flickering'. For infinite scroll and in the case of the previous loaded data being empty, we keep showing the spinner.Testing Instructions
tablelayoutScreenshots or screencast
Noting that for the video I have throttled the network a bit to make the effect easier to see.
Screen.Recording.2026-01-13.at.10.19.38.AM.mov