feat: progressive dashboard loading

[amcgee]

Fixes DHIS2-4867

This adds very basic support for progressive dashboard loading, so that only the dashboards visible in the current client window (scrolled into view) are loaded. Additional dashboards are loaded on scroll with a configurable debounce of 100ms.

In testing this reduces the number of initial HTTP requests spawned by a simple 8-item dashboard from 153 to 113 (with 4 dashboard items visible on startup) as seen in the screenshots below. (side note that's a whole lot of requests! We should reduce them. Also the dashboards javascript bundle is an astonishing 10 MB....)

Some cons of this approach and future enhancements:

1. I'm just doing a dumb getBoundingClientRect check, so there might be cases where a dashboard is loaded even though only 1px of it is visible or the visible portion is covered by the header bar. I think it's OK to be a little over-zealous here for now.
2. I'm also not currently checking left or right, but I don't think horizontally-scrolling dashboards are common (are they?)
3. There is some render lag while scrolling. This was always the case if you scrolled while the items were loading, but it may happen more often now since there will always be items loading as you scroll (the first time). To fix this we would need to offload some processing to a service worker.
4. Right now I've only done this with VisualizationItems, we might want to extend it also to AppItems?
5. We might want to make this even more intelligent by queuing items and waiting for a certain number to load at a time before loading the rest. This could get annoying for fast-scrollers though.

[jenniferarnesen]

In response to your comments above:
1: I think its better to err on the side of loading too much
2. We don't need to worry about horizontal scrolling
3. Perceived performance on small to medium dashboards might be worse and I wonder if we could think up some solutions. On the flip side, it will actually be possible to load large dashboards, so maybe its worth releasing what we have now, and iteratively improving it.
4. I think just focusing on vis items for now is a great start and first iteration.

One thing - when user applies a filter, then all the vis items are loaded even if they are not in the viewport. So this doesn't fix those performance issues.

[amcgee]

Thanks @jennifer, good catch of the filters issue. I will look at how to apply that fix, though it may be more involved

[amcgee]

Updated to support an initialBufferFactor with a default of 0.5. This can be tuned to select how much of the second scroll viewport height is loaded on startup (so by default, anything visible in the first 150vh or 1.5 viewports is loaded).

For the Filter issue - progressive loading actually does work with filters, but each item is only loaded once. If the filter is updated, all items which have already loaded (so all of them if you've already scrolled through the whole dashboard, are updated at once. I will try to find a way to clear out the loaded state when updating the filter.

[cooper-joe]

I think we should ensure that it's very obvious to the user why the items might not have loaded yet. As Jennifer mentioned, some users may perceive a slight decrease in performance. So let's make it as smooth as possible. As a minimum I think we should go for text inside all dashboard items saying "Loading item", that can be replaced when the item has fully loaded.

(I'm wary of spinners in this case because on older machines they can stall or just never load fully before the item loads anyway.)

[amcgee]

I think we should ensure that it's very obvious to the user why the items might not have loaded yet. As Jennifer mentioned, some users may perceive a slight decrease in performance. So let's make it as smooth as possible. As a minimum I think we should go for text inside all dashboard items saying "Loading item", that can be replaced when the item has fully loaded.

(I'm wary of spinners in this case because on older machines they can stall or just never load fully before the item loads anyway.)

@joeDHIS there is an existing loading spinner which indicates a loading state, this change doesn't affect that. If we wanted to replace that spinner with something else I think that's outside the scope of this change. This only affects items which are not currently visible to the user, as soon as the item is scrolled into view the loading spinner appears - previously this happened while the item was off the screen.

There will be at most 100 milliseconds of delay before the loading indicator appears, but I think it would be more confusing to have text appear for such a brief period when there's a loading indicator about to appear.

If you were referencing the screenshot, I turned off the scroll event to take that screenshot to show the reduction in requests. That's why you see a blank white item.

[amcgee]

For the record I think the spinners aren't the best choice here either, but they're what we currently have. As I mentioned to improve the performance of those spinners and prevent browsers from jerking when items are loading we'd need to significantly change the way we render individual items, again probably outside the scope of this change.

[amcgee]

@jenniferarnesen I'm currently looking into the progressive re-loading after a filter change and also a potential bug with Chart items.

[cooper-joe]

@amcgee Understood, thanks for the clear explanation 👍 I'll keep some ideas noted down for if/when we expand the scope of this implementation

[amcgee]

@joeDHIS 👍

@jenniferarnesen I updated the PR to re-mount the progressiveLoading components whenever the itemFilter changes. To do this I generate a new key whenever the item changes, using a single-cache-depth memoized function (which I added to util.js and wrote tests for).

This makes for a nice, non-resource-intensive experience again when updating the filter after loading all items. It does reload items which might not respect the filter unnecessarily, but this was also the existing behavior.

The potential Chart bug was a misconfiguration of my environment (and a strange d2 behavior which is a crusade for another day)

[jenniferarnesen]

Looks good, tried it on Chrome, FF, and IE11. What do you think about moving the memoize fn into a separate file with a relevant name, rather than putting it in a nebulous file named util? Also, do you think the Progressive Container could use any unit tests?

[amcgee]

@jenniferarnesen thanks for testing!

Sure, I like that idea. Will move the memoizeOne function to its own file (and move tests accordingly)

I thought about writing unit tests for the Progressive Container but I think they would be pretty fragile. The component is pretty tightly-coupled with window.scroll, so we would have to mock out a lot of the meat of the functionality to get a meaningful test, and then the test surface area is small. If we had Cypress set up in Dashboards I think it could be a good candidate for scroll testing, however. Let me know if you disagree and I can write the unit test, it shouldn't be terribly hard to do.

[jenniferarnesen]

Re tests for the Progressive Container - I agree, ran into the same issue when testing components that use refs to talk directly to the web api's. Let's prioritize getting Cypress into dashboards (not in this PR though :)

[amcgee]

@jenniferarnesen @joeDHIS @geethaalwan This should be good to go. You can test it here, but be sure to log in to play/dev and clear your cache first.

Note that the first 1.5 viewport heights are loaded at first, so the easiest way to test it is to make your browser window pretty short. Then load a dashboard, wait for everything to complete, and note that you can interact with the visual dashboard items. Then scroll down and note that the previously-hidden items weren't loaded, so you'll see a loading spinner and then they will load when they come into view.

You can also validate this by looking at the "request count" in the Chrome console network tab, comparing it to the dashboards version on play (it should be less), and then seeing the number go up as you scroll down and more items load.

[jenniferarnesen]

@amcgee PR approved. As soon as Geetha has tested it, you can merge to master. Also, Scott had a question for you about backporting to 2.31 (see the Jira ticket).

When you merge, could you include in the commit description what was actually implemented (1.5 viewport heights, progressive loading also applies to when filters are added...)

[jenniferarnesen]

You can go ahead and merge. Netlify seems to be a little problematic with staying logged in and CORS issues.

[dhis2-bot]

🎉 This PR is included in version 31.1.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀