EuiSkeleton components

[AndreaDellaValle]

Summary

Hello folks 👋
I've previously left a comment in this discussion here because like some of you I'm in the need of a proper Skeleton component, so with this draft PR I'm trying to revive the discussion with an actual testable proposal.

Context

I've checked others design system skeletons and tried to reshape them for the EUI use case (from basic apps to very complex back-office dashboards) while trying to avoid overdoing it, otherwise it's better to directly switch to a 'skeleton' prop for every component as suggested in the discussion linked.

Proposal

The basic implementation can be within a ternary operator à la Material UI just to say

myCondition 
  ? <EuiSkeletonCircle size="s" /> 
  : <EuiAvatar size="s" />

I know it's not the fanciest way, but it was also the fastest to show you a working example, we can discuss about a wrapper solution or similar once the component variants will be agreed.

Skeleton Component Structure

• placed under the Display section
• 4 variants:
  • Circle
  • Text (ex: EuiLoadingContent)
  • Heading
  • Item: generic all-around to cover images, icons, logo, badges, others...by setting height width and radius
• removal of the EuiLoadingContent component [BREAKING] (but still alive in this draft)

Missing (but willing to include):

• Table skeletons
• Line thickness props for SkeletonText
• Animation styles (the current one does not scale properly within dimension, it became too big)

Request

General feedback on this first draft, and especially about:

• Overall effectiveness
• Developer experience
• The 4 components structure (too few? too much? too much manual effort during implementation?)
• The props of the single components
• Naming

I'm leaving some screenshots and records but you can also checkout this branch and testing it:
https://user-images.githubusercontent.com/15049973/209408005-8a0ccc19-8ec7-42bc-9f86-6c9a75936473.mov

SkeletonCircle props:

SkeletonText props:

SkeletonHeading props:

SkeletonItem props:

QA

General checklist

I'll go trough the entire checklist once requirements will be reviewed and approved.
Tests and styles are in TODO state as well, also the code here and there it's still a mess, any advice is welcome.

[kibanamachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[cla-checker-service]

💚 CLA has been signed

[elizabetdev]

jenkins test this

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6502/

[elizabetdev]

Thanks @AndreaDellaValle,

This PR is looking great. I like your approach for the implementation:

myCondition 
  ? <EuiSkeletonCircle size="s" /> 
  : <EuiAvatar size="s" />

I'm a product designer on EUI team and my review is more focused on design aspects.

General feedback on this first draft.

• Overall effectiveness: I have nothing to say. It looks great.
• Developer experience: The DX looks good. The EUI team can then follow up with some usage guidelines. And we can also consider adding a more complex demo where we showcase a progessive loading of contents. But what you have looks great to merge.
• The 4 components structure: I think for now it is a good start. We can consider adding more components in the future. Only in case, it is really necessary.
• The props of the single components: I left some comments directly in the code.
• Naming: I left some comments directly in the code.

Let me know if you need any help.

[cee-chen]

@AndreaDellaValle it looks like we still need you to sign the CLA (under the email address tied to your GitHub commits) - if you could take a look at that in addition to Elizabet's feedback items, that'd be super appreciated! ❤️ Thank you for your amazing contribution - as a heads up, we'll merge it into a feature branch in order to add more docs before releasing it.

[AndreaDellaValle]

Hello @cee-chen 😀

I've signed the agreement for the third time (the last try was some minutes ago) and finally I can see that the check is green and we can move on ^_^

I take advantage of this comment to confirm that I'll take care of the CR pointed out by @miukimiu also.
I'll start working on this first CR and we will see in the next ones 👋

Thanks to both of you for the feedback and the instructions!

PS: sorry for closing/reopening the PR, it was a mistake.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_6502/

[cee-chen]

Hey @AndreaDellaValle! I've pushed up the size/scaling updates as well as some minor improvement and cleanup feedback items (should all have been atomically committed and have explanations in each git commit message - please let me know if anything doesn't make sense).

This is looking super great and I'm very excited for it! I'm signing off for today but have some very minor docs work I'd like to do left (playground, copy passes, and finally, updating EuiLoadingContent to dogfood EuiSkeletonText + deprecating it and recommending devs use EuiSkeletonText). I can either take another pass at it tomorrow, or I'd also fine merging this PR into the feature branch as-is and continuing to fine tune docs after. This is very very close though!

EDIT: apologies for the force push, I totally f-ed up my merges. Completely my bad - hopefully did it quickly enough that it didn't screw up your local.

[AndreaDellaValle]

Thank you for the amazing work @cee-chen ! You basically put in place everything that was missing and much more 🎊
Self-talking commits are super clear, I've understood some theme utilities that I was not getting and I'm still deep diving into them to better understand EUI.
Today during my lunch break I simply completed the example for the EuiSkeletonRectangle by adding the toggle.

I was putting this on ready for review but I found a bug on Safari 🐞 that is not rendering the border-radius so I'll take care of this issue later after work (and it was affecting the EuiLoadingContent as well).
Also, I'll try to go through all the other checks in the next few evenings if you agree with that 😉

EDIT: I can work on Figma components as well, but I don't know how to share them with you.

General checklist

• Checked in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox > Safari border radius issue
• Props have proper autodocs (using @default if default values are missing) and playground toggles
• Added documentation
  - [ ] Checked Code Sandbox works for any docs examples
• Added or updated jest and cypress tests
  - [ ] Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• Updated the Figma library counterpart
• A changelog entry exists and is marked appropriately

Emotion conversion checklist

• Does it work?
• Output CSS matches the previous CSS / as expected in browsers
• Rendered className reads as expected in snapshots and in browsers
  - [ ] Checked component playground (class components wrapped in withEuiTheme need to pass true as the second argument to its propUtilityForPlayground in src-docs/src/views/{component}/playground.js)
   
• Unit tests
• shouldRenderCustomStyles() test was added and passes with parent component and any nested childProps (e.g. tooltipProps)
  - [ ] Removed any mount()ed snapshots in favor of render() or a more specific assertion
   
• Sass/Emotion conversion process
  - [ ] Converted all global Sass vars/mixins to JS (e.g. $euiSize to euiTheme.size.base)
  - [ ] Removed or converted component-specific Sass vars/mixins to exported JS versions, listed removals in changelog, and manually updated our theme JSON files
• Simplified calc() to mathWithUnits if possible (if mixing different unit types, this may not be possible)
  - [ ] Added an @warn deprecation message within the global_styling/mixins/{component}.scss file
  - [ ] Removed component from src/components/index.scss
  - [ ] Deleted any src/amsterdam/overrides/{component}.scss files (styles within should have been converted to the baseline Emotion styles)
   
• CSS tech debt
• Reduced specificity where possible (usually by reducing nesting and class name chaining)
• Wrapped all animations or transitions in euiCanAnimate
• Used gap property to add margin between items if using flex
• Converted side specific padding, margin, and position to -inline and -block logical properties (check inline styles as well as CSS)
   
• Extras/nice-to-have
• Documentation pass:
  • Converted any remaining .js docs files to TS
  • Misc cleanup of docs code (e.g. combine imports to single from '../src', replace <React.Fragment> with <>)
    - [ ] Check for issues in the backlog that could be a quick fix for that component
    - [ ] Optional component/code cleanup: consider splitting up the component into multiple children if it's overly verbose or difficult to reason about

[cee-chen]

I was putting this on ready for review but I found a bug on Safari 🐞 that is not rendering the border-radius so I'll take care of this issue later after work (and it was affecting the EuiLoadingContent as well).

AMAZING catch on this @AndreaDellaValle! Safari will be the death of me 💀 I poked at it a bit and discovered the issue is that the parent container's border-radius isn't being respected via overflow: hidden when the pseudo-element is animating through. Forcing the container to create a stacking context via z-index in f9db30c was the most benign way (i.e., least potential to interfere with custom consumer CSS) that I could see to make Safari behave. This should be working now, but more of your awesome testing/QA would be much appreciated!

EDIT: I can work on Figma components as well, but I don't know how to share them with you.

No worries on this one, we usually have our designers handle this - @miukimiu can likely grab it.

I'll go through the checklist as well and strike off or delete items that don't apply to this PR. Thanks again for your amazing work!! 🎉 🎉 I've pushed up all the PR feedback/changes I wanted to see personally, and think this is ready to merge. I'll handle deprecating EuiLoadingContent in a separate PR from this in order to keep this PR more manageable.

[AndreaDellaValle]

Great fixes on the fly @cee-chen !
Yes Safari is a nightmare when it comes to CSS 🎃 (I call it the 'new IE')
Thank you for the detailed explanation on your stacking context fix also!

This should be working now, but more of your awesome testing/QA would be much appreciated!

For sure! I already saw some minors on the playgrounds but I think I can handle them on the fly tonight after dinner.
I will try to check everything before closing this btw.

I also think that Skeletons for EuiBasicTable and other tabular data display will be a different animal to handle in a new PR, so yes, we're pretty close to the ready for review state 🤓

[AndreaDellaValle]

Assuming that these kinds of tests are far more comprehensive if executed with some tool like Playwright (that I'm still not using... 🥲), I've tested both the rendering and the docs playgrounds and they're looking pretty good to me:

• Edge on Win10
• Safari on MacOS
• Firefox on MacOS
• Chrome on MacOS

There are some micro minors that are confined to the playgrounds but that I think are not relevant:

• for EuiSkeletonText it does not limit the range of lines like the component do, and numbers are rendered in sparse order
• for EuiSkeletonTitle props seems not to render the precise exact size (x and xs behaves the same)
  (After a first check they seem related more to the way playground behave than our configuration, and I haven't found hotfix for them, maybe I can check more and open an issue).

I'm asking for the review formally to @cee-chen in order to follow the standard process (but you already saw everything I think), and if you want to involve other reviewers they are more than welcome 🤠

Thank you again
PS: If for some reason, you need Figma components also, I'm at your disposal 🧑‍🎨

[cee-chen]

Woohoo! Let's ship it. Very excited for this to land (hopefully by next Tuesday's release!)

for EuiSkeletonText it does not limit the range of lines like the component do, and numbers are rendered in sparse order

For what it's worth we have several other components (with limited number inputs) that behave this way, so I'm not super worried about it. It's something we'd need to enhance our playground controls for in a separate PR.