openSUSE / agama / 8925013654 / 3 – web

72%

master: 72%

push

github

Storage: show skeletons only when needed (#1171)

## Problem

- The loading skeletons are displayed always, even when not needed
- The installation device selection popup is empty when clicked quickly
before loading all data

## Solution

### Loading Skeletons

- Pass the name of the component which is changed by user to parent
- Send back the changing component to all children
- There is mapping which defined whether a child needs refresh when some
setting is being changed

### Installation Device Progress

- Use the sent data when when the stored values are `undefined`
- Show a simple skeleton

### screenreaderText Properties

- I have removed all `screenreaderText` properties for skeletons and
keep it only for the result section
- The reason is that it does not make sense to notify users about 5
values in progress, it usually takes about 2 seconds to refresh the data
so the screen reader would not have enough time to read all messages
- Use it only the result section which is refreshed always, moreover the
data for the other values will be read together with the result data,
they will always take the same time

## Questions

- Do we need more granularity with changing values? I.e. if the Btrfs
snapshots are enabled/disabled then the partition list below is refresh
as well. (IMHO fine to solve this later in a separate card / PR.)
- Better progress for the installation device loading? (Note: do not
overengineer here, the progress is displayed only when you click the
link very quickly after opening the storage page, in most cases it won't
be used at all.)

## Testing

- Tested manually

## Screenshots

When enabling/disabling the Btrfs snapshots all data was refreshed, now
the installation device and the space policy does not show the progress
skeletons.

| Original | Fixed |
|---|---|
|
![storage_skeletons_broken](https://github.com/openSUSE/agama/assets/907998/9833814b-ee02-42c3-be7f-089f4b832cba... (continued)

1986 of 2867 branches covered (69.27%)

Branch coverage included in aggregate %.

7026 of 9102 relevant lines covered (77.19%)

68.35 hits per line