Flow UI: Page not very responsive while loading large component

[xiyu95]

Description Component detail page with large amount of exports values takes a long time to load due to large amount of returning data (~20 - 30 seconds loading time) Sometimes this will cause the entire page to crash Page reaction on user action is very slow on larger data size

[Daniel-Vaz]

Plus one to see this addressed somehow.

When there are many targets found using components like discovery.kubernetes, it makes the component page load very slowly in medium to large Kubernetes clusters. Sometimes, it can take over a minute for the page to fully load.

In these situations, it's really difficult to check and fix any problems with the discovered\scraped targets.

[ptodev]

As a temporary workaround, I think it's possible to retrieve component information from a URL such as this:

https://localhost:12345/api/v0/web/components/discovery.kubernetes.kubernetes_pods

[rfratto]

Hi there :wave:

On April 9, 2024, Grafana Labs announced Grafana Alloy, the spirital successor to Grafana Agent and the final form of Grafana Agent flow mode. As a result, Grafana Agent has been deprecated and will only be receiving bug and security fixes until its end-of-life around November 1, 2025.

To make things easier for maintainers, we're in the process of migrating all issues tagged variant/flow to the Grafana Alloy repository to have a single home for tracking issues. This issue is likely something we'll want to address in both Grafana Alloy and Grafana Agent, so just because it's being moved doesn't mean we won't address the issue in Grafana Agent :)

[josh-thisisbud]

Experiencing this issue at the moment

Would appreciate some pagination of the lists as this seems to be the main thing causing us grief

[Daniel-Vaz]

After digging a bit further, I believe that what's constituting the biggest chunk of time consumption in the rendering of the results is the SyntaxHighlighter - Source

Building a custom image while just changing this to something simpler like <code></code> Tags I can see a really big improvement in the total amount of time in the page rendering:

[rfratto]

Agreed that the issue is primarily the syntax highlighting.

A good short term fix might be disabling syntax highlighting if the payload is longer than some reasonable size (maybe 1KB). Alternatively we might be able to explore lazily loading the syntax so it doens't block the first render.

[Daniel-Vaz]

Can't a similar approach be used, like alloyStringify, or even extend its functionality ?

[rfratto]

I'm not sure what you mean, what would using alloyStringify mean in this context?

[akevdmeer]

I believe that what @Daniel-Vaz means is that the current code highlights the result of that alloyStringify() which requires parsing as Javascript. But there is no need to parse: alloyStringify() knows the structure of what it is generating and the highlighting could be done in the same pass efficiently. Basically to fuse this highlighting with the stringifying.

[rfratto]

Ah, thanks! Yeah, it seems possible that we could have a new function to produce the highlighted DOM directly. It's worth some investigation for sure.

[sidewinder12s]

Another thought would be just break up the page more and lazy load.

For a Kubernetes scrape target example, present the CRD configs on one page and the targets on another.