ContentHubUI: Content hub client is sending a lot of identical requests


Acceptance Criteria

  • The content hub client should cache results for requests for a short while and re-use the results of these requests whenever it needs.


Every time the content hub client is opened up it sends several search requests for content and many of them are identical. Every time the search is cleared the same request is sent.

It is reported that there are 5 identical requests going on, but with the current implementation it was only meant to send 3 (one for each list).

Since the “Popular Content“-list is already fetched by the main tabular list, we can skip this request, and just pick the 6 first from the main list. In that way we end up with 2 initial requests.

Acceptance Criteria



Frode Petterson
September 15, 2020, 7:20 AM

No. When opening the HUB there are at least 5 simultaneous requests from the browser to the same endpoint. There is definitely something wrong with the hub client if it sends more before getting a response to the initial request. You could have a look at the content type section to see how we manage with one request there?

Pål Jørgensen
September 15, 2020, 7:28 AM

: It definitively shouldn’t be 5 requests. But I think it actually should be 3. I.e: one for each list.

Frode Petterson
September 15, 2020, 7:44 AM

Why 3? Isn’t 2 enough? In the plans, it says we should group them all into one initial request, but I’m fine with having 2 if it makes the implementation quicker.

Erik Langhaug
September 23, 2020, 12:11 PM

The caching seems to work as expected!

When we cache every search like this, should we to think about informing the author that results might be stale if the page has been open for a while? Something like a warning message somewhere at the top of the page simply suggesting to refresh the page perhaps.

If not, should we have some cache expiration logic?

Pål Jørgensen
September 24, 2020, 7:14 AM

I agree, I’ll add some cache expiration logic.


Pål Jørgensen


Thomas Marstrander



Code reviewer

Erik Langhaug



Time tracking