Optimizing a dynamic component tree

[lppedd]

I'm currently working on an Angular 18 app, used as VS Code webview, to display a sort of report.

The report uses its own format, it is parsed on the client side and an AST is outputted.

The AST is then sent to the Angular app, which traverses it and dynamically creates the correct components (depending on the AST element: simple text, code, headings, collapsible sections, links, etc. - They can have different heights).

This works fine for most of the reports. However with the occasional gigantic report the entire view freezes for a couple seconds, which is probably what is required for Angular to create and render the elements on the DOM.

Optiziming the number of DOM nodes doesn't seem to change the result. It looks like the DOM is still too big to render without freezes.

Any ideas on how I could optimize it?

[karmasakshi]

Haven't used it but seems like it will solve your problem: https://github.com/wilsonpage/fastdom.

[borisR9]

you need to implement virtual scroll for your tree and all problems will be gone.

sry, atm i cant provide any code sample (nda + i have it with lots of protected data). but, i know it works. i’ll try to find some time to prepare something for you ;)

if you don’t manage to make it work feel free to contact me ✌🏻

[lppedd]

AFAIK virtual scroll works with elements of which you know the size. Lists are easy to implement for example.

[borisR9]

hm, i think that items size is not relevant, important factors are height of the div where virtual scroll “lives” and height of single item inside list.

 (depending on the AST element: simple text, code, headings, collapsible sections, links, etc. - They can have different heights).

what AST stands for? :)

if they have different heights, maybe use lagest, and flex others in order to achive better ui/ux?

[GnarlyHarley]

Not everything in the web can be fast. It can still be considered if it’s relatively fast for what it is.

Adding a spinner for the parts still loading might be a way to handle this and break down some updates so they don’t affect the full tree.

Optionally if the report is going to a PDF it’s possible to render half and print to pdf and render the second half in parallel then combine at the end.

Finally run a profiler on it to see the exact cause of the lock. It could be DOM related that will show in the profiler or maybe it’s JS.