Make possible to render all the tabs at once on dom, not when you click on each tab.

[gaurav1999]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Normally, in tabs content is there in the DOM and they just hide them. But in superset the content is not rendered initially at least you click it once. It seems okay on the side of pagination, but I am trying to see if I can get the content of all the tabs from the DOM for exporting purposes.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I wish to export the dashboards using the DOM's data, but without having all the tabs rendered in the DOM it's not possible. I will also like to discuss about it's performance issues and why the project has decided to use the current appraoch.
Describe alternatives you've considered

[mistercrunch]

related: #8655

[gaurav1999]

Not sure, how #8655 relates ? , it's about the Dashboard tabs.

[willbarrett]

Hi @gaurav1999, from your original description it looks like you're trying to scrape the DOM for all of the charts in a dashboard. You're correct, that's different from SQL Lab tabs - @mistercrunch misunderstood.

Let me answer some questions for you:

Why isn't the content of all dashboard tabs written to the DOM?

For each chart on a dashboard, the front-end currently makes an HTTP request for the relevant data after load. Browsers limit concurrent requests to the same domain to 6 at one time. This means that we can, at most, load data for 6 charts concurrently. Writing charts to the DOM for only the current tab is a performance optimization which ensures:

1. All requests are for the tab the user wants to look at right now
2. Charts which the user does not choose to view are not unnecessarily loaded

Point 2 is especially important for large dashboards accessing data on congested databases - it's quite possible for Superset to overwhelm a back-end store if too many people hit it at once.

Why was it built this way?

I don't have the full history, but I believe this was the easiest way to build the system in the beginning. The project is currently exploring removing some of the bottlenecks by backgrounding queries and leveraging websockets. This should remove the limit of 6 charts loading at once.

Recommendation for you

One way to get around the restriction would be to export the dashboard via either a headed or headless browser using a tool like Selenium - you could code a script to click to open each tab, wait for all the API requests to complete, and then snapshot the DOM. This is likely a slower and more difficult-to-configure snapshot than what you were looking for, but I believe it would work.

Why are you looking to export dashboard data via the web interface? What is your use-case? Understanding this could assist me in helping you meet the need.

[gaurav1999]

Hi @willbarrett ,
Yes the explanation is on point, I also tried to research this out on my own and figured out this is because of performance and database requests because of which it has been designed this way at the moment. However I was not aware of details this deep. Thanks for that.

So, my use case was to print dashboards, and yes I explored a lots of ideas, first one was to get screenshot of dashboard using things like html2canvas and js2pdf but that did not worked out because not all the tabs were here in the DOM and I wish to capture all of them at once.

Also, with html2canvas and js2pdf quality of PDF's are not that great because of color models and svg charts :-/

So, to enusre quality and make sure all the tabs could be rendered in single pdf I went with headless browser tool. You are correct on this too. Yes of-course it's really really slow but if it works and there is no other way at the moment, I guess we have to stick with it.

It's been a long time, now that I have figured things already and proceeded I guess this issue is resolved for my use case, and whatever I learnt on my own, Now I have a validation of that learning in form of this discussion as well :-) !

However, I am not sure we want to close this issue or not, because in my opinion even if this is not about my use case of printing dashboards, but it totally makes sense that this approach can be rethought of and there maybe scope of optimization still left over here.

So I will leave that thought on maintainers.

Thanks!

[willbarrett]

I'm glad you came to a similar solution @gaurav1999 - just in case you're interested in how we'd like to evolve the execution systems to make things more performant, I'll leave you with a couple of open Superset Improvement Proposals (SIPs) to take a look at:

Here's one to support global async query support, the websocket-based solution I mentioned earlier: #9190

and here's one for adding connection pooling for analytics databases: #8574

Since we've found a solution for your particular usecase and this system is already being actively rethought, I'd recommend closing this issue. The closed issue will still be referenced from the appropriate SIPs. Thanks for reaching out to us.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned to prevent stale bot from closing the issue.