-
Notifications
You must be signed in to change notification settings - Fork 242
area/ui: Replace loading spinners with skeleton placeholders #4293
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
Conversation
|
🤖 Meticulous spotted visual differences in 287 of 372 screens tested: view and approve differences detected. Last updated for commit 1de698d. This comment will update as new commits are pushed. |
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.
We've been getting an error when publishing the packages to npm, an example can be seen here https://github.com/parca-dev/parca/actions/runs/7612558919/job/20730449671
But after running yarn build locally, this file was auto-deleted in the process. I'm not really sure what the file does so I'm leaving this change as is.
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.
Sadly we need this file to successfully use the Parca code in other projects.
Is there some way we can get lerna to explicitly ignore this particular file?
Here's the related PR that introduced this file: https://github.com/parca-dev/parca/pull/4105/files
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 see. Thanks for the clarification. I'll look into how we can do that.
fe76f2e to
c2ac2b7
Compare
c2ac2b7 to
80ae508
Compare
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.
Just a feedback on the overall approach:
Based on my previous experiences with the skeleton loader, it's better if the skeleton loaders are handled by the actual components themselves (by taking in a loading prop) instead of creating new components with the matching design.
- It helps to reduce the jumps in the UI when the app switches between the loaders and the actual content.
- It is easier to maintain the loader designs when they are handled by the actually component, otherwise any design change/additions to actual components have to be replicated with the skeleton components as well, becomes a pain in the longer run.
But this is almost like a rewrite of this whole PR, so I guess we can proceed with this implementation but keep this in mind when we plan any work on the loaders in the future so we can transition towards this.
Hmm i agree with the skeleton loaders being ideally handled by the actual components and taking in a loading prop. The latter part of that is actually already included in the PR, but its the former that might be a bit tricky. Because out of all of the visualizations, the table component is probably the only one in which we can ideally have an idea of what it's going to be like after the data is done loading. For the icicle graph and metrics graph (and to some extent the source view) we can't be sure of how it's going be drawn/rendered on the browser until we've successfully fetched the data. Which is why an SVG matching the design was approach used. |




This PR replaces the loading spinners with skeleton placeholders for:
The skeleton placeholder can be seen in action by using the Vercel preview link.
I also fixed the visual bug where the action buttons for the icicle graph were smushed together when there were multiple visualizations side by side. Fixed this by replacing some of the buttons with texts with icons (only when two visualizations are side by side) which shows a tooltip when you hover on them.


Before
After
Resolves #3851