-
Notifications
You must be signed in to change notification settings - Fork 103
Description
❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.
Background
We have ongoing issues with loading states in our products. KCard
/ KCardGrid
is the first KDS component that introduced loading skeletons feature that is not only meant to serve card use-cases, but also encapsulates first patterns for general loading behavior (timing, delay, animation,...) that were agreed with the design team.
Summary
As a next step, I propose we move loading skeletons feature to a new separate component, KSkeletonLoader
. I already prepared a proof of concept #841 with the preview page here. The PoC was created after discussing the desired direction for loading skeletons with designers and demonstrates the following benefits:
- Resolves general need for better loading experience, not only that of cards. See "Generic" and "Custom" sections.
- More flexible behavior. Resolves issues @AlexVelezLl observed in Kolibri. See both "Card grid" sections.
- Scales easily. New shapes can be added from within KDS as well as from consumers (see "Custom" section).
- Makes
KCard
/KCardGrid
simpler. - More suitable place to document and encapsulate general patterns.
Guidance
As can be seen in #841, technically this is achieved by:
- Moving
cards/useGridLoading
toKSkeletonLoader/useGridLoading
- Separating
KSkeletonLoader/useGridLoading
into two parts:KSkeletonLoader/useLoading
contains general loading logic (timing, delay, ...)KSkeletonLoader/useGridLoading
contains only pieces specific to card grids (number of skeleton cards, their height, orientation, ...)
Every skeleton shape is encapsulated in its own component
SkeletonGeneric
SkeletonCustom
SkeletonCard
This all makes KSkeletonLoader
ready for simple addition of new shapes.
Needs decisions
From previous discussions with both devs and designers, it seemed we're already aligned on high-level direction (Slack thread).
What remains is to make final confirmation to move towards this solution, and then finalize few details such as the exact shape for the generic skeleton.