Circular loader only shows a tiny sliver for short loads

[martinkrulltott]

The CircularLoader looks good for regular loading times, but if the loading is very quick, all that's shown is a tiny sliver that starts spinning and then disappears instantly. This can be seen in the first few seconds of the attached video (look closely the middle of the screen) and in the following screenshots:

---

Sliver

---

Regular spinner

---

Video, recorded from Data Visualizer

loading.mov

[Mohammer5]

I think this "issue" came up already a couple of time, I'm not really sure how to address is properly as we don't know how long a request will take unless we implement a prediction system (which can range from being very naive - manually done per request per app - to extremely sophisticated - test internet speed on app init, store which requests typically request a lot of data and only show the loading spinner there if the internet is slow, etc).

If I'm not mistaken @cooper-joe has proposed something along the lines of delaying the loading spinner display so it will only show if loading will take a certain amount of time. But it could very well be that we'd see more partially rendered loading spinners that way. I also don't know how to figure out if our solution is a good one at all (because we'd need to see how it behaves "in the wild" with real world data).

I guess the easiest solution is just to ignore that this happens. It's not beautiful but at the same time not harmful at all. It would cost us a lot of time to address this even though it's not really causing any harm.

I'm curious though what the others think (cc @dhis2/front-end)

[cooper-joe]

User experience research on this topic suggests that it can be useful to delay a loading indicator. However, with the amount of use cases we must account for, there is no standard amount of time the spinner should be delayed by, nor is there a standard 'trigger' for hiding or showing (e.g. on user input, or network activity, etc.). A flexible solution like the one @varl suggested above would be a useful utility, I think.

Whether the delay functionality should provided by ui or handled in app, I cannot comment on.

[cooper-joe]

Of course, delaying the loading by 1sec, 2sec, Xsec doesn't really mean there will not be flashes of loading spinners. 1.1sec, 2.1sec, X.1sec, will show a flash. This can be avoided with styling. For example, fading in the loader over 0.3sec.

[ismay]

Of course, delaying the loading by 1sec, 2sec, Xsec doesn't really mean there will not be flashes of loading spinners. 1.1sec, 2.1sec, X.1sec, will show a flash. This can be avoided with styling. For example, fading in the loader over 0.3sec.

That seems nice. Do you think that if we have a spinner that slowly fades in, we would still have a usecase for a spinner that shows instantly?

[cooper-joe]

Do you think that if we have a spinner that slowly fades in, we would still have a usecase for a spinner that shows instantly?

I think it depends on the duration of the fade-in. It might be possible to have a fade-in that is fast enough that it appears to be instant, but slow enough that it lowers the visual noise of the flashing-loader.

Ideally, I think we would not have two separate types. There are subtle use-case differences between when you'd want to fade in (uncertain loading time) rather than show instantly (known minimum loading time), and I think that subtlety would be difficult to convey in the ui library.

[varl]

@Mohammer5 Yeah, at the heart of it, my response is that we should not implement this type of functionality in our core components. That's not their purpose. So for this question the answer is "do nothing (right now)".

That's a pretty unsatisfying answer though, and might cause @martinkrulltott to go off and create a custom solution, and when we do provide something like @dhis2/ui-hooks, he will have to refactor again.

I wanted to illustrate how components are intended to be composed with functionality through an example, and while we don't have something like @dhis2/ui-hooks right now, it might not be that far off, so he can decide for himself if he wants to patch it in the App, or wait for the UI library to provide what he needs.

The hook example is a recipe for building custom functionality with core components. It is not intended as an example of what the ui-hooks lib is guaranteed to provide.