Skip to content

Conversation

@yomete
Copy link
Contributor

@yomete yomete commented Jan 29, 2024

This PR replaces the loading spinners with skeleton placeholders for:

  • the metrics graph
  • the icicle graph
  • the top table
  • the source view

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
image
After
image

Resolves #3851

@yomete yomete requested review from a team as code owners January 29, 2024 13:23
@alwaysmeticulous
Copy link

alwaysmeticulous bot commented Jan 29, 2024

🤖 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.

Copy link
Contributor Author

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

image

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.

Copy link
Member

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

Copy link
Contributor Author

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.

@manojVivek
Copy link
Contributor

manojVivek commented Jan 30, 2024

Would it be possible to adjust the height and the padding between the bars to match the actual Flamegraph closely?

Screenshot 2024-01-30 at 11 37 03 AM 1

Same with the font of the headers in the top table loader:
Screenshot 2024-01-30 at 11 39 27 AM

Copy link
Contributor

@manojVivek manojVivek left a 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.

  1. It helps to reduce the jumps in the UI when the app switches between the loaders and the actual content.
  2. 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.

@yomete
Copy link
Contributor Author

yomete commented Jan 30, 2024

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.

  1. It helps to reduce the jumps in the UI when the app switches between the loaders and the actual content.
  2. 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.

@yomete
Copy link
Contributor Author

yomete commented Jan 30, 2024

Would it be possible to adjust the height and the padding between the bars to match the actual Flamegraph closely?

Screenshot 2024-01-30 at 11 37 03 AM 1 Same with the font of the headers in the top table loader: Screenshot 2024-01-30 at 11 39 27 AM

Thanks for spotting that, I need to do some more responsive work for the skeletons so it's consistent across different screens.

@yomete yomete merged commit 353f967 into main Jan 31, 2024
@yomete yomete deleted the skeleton-placeholders branch November 7, 2024 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Replace loading spinners with skeleton placeholders

4 participants