[Feature request]: Returning html response instead of iframe desirable

[eddy-ojb]

I realise I am posting a lot on here, sorry!

One thought that occurred to me as I have been porting some of my existing code over is that injecting the html code instead of an iframe is more desirable to me as a developer as I can use the same css across Django and Dash as well as not having to deal with the nuances of an iframe. My dashboard code doesn't quite render with the same scaling using an iframe, even though the code is the same as when I didn't use django-dash-plotly, if that makes sense.

I plan to start looking deeper in to your code to try and understand how you are wrapping around Dash and see if this is feasible!

[delsim]

The iframe is used because the dash content doesn't mix well with other content on the page. This makes not encapsulating it tricky.
Would a different template - one that still had an iframe, but had some css (and perhaps js) added to it - suffice?

[eddy-ojb]

I've gone ahead and implemented this feature and it works for me, though its not a clean solution yet. You are right that there are some issues with injecting Dash in to an existing page, but I think these look resolvable.

I am still experimenting to see what is better in what scenario and learning how the dpd code works.

The iframe route might be fine but some handy options would be:

• Being able to choose whether to return raw html code for injection or an iframe
• If an iframe, passing specific css routes over to Dash during construction of the app would minimise duplication. For example, I am thinking that if we know the Django app name and the base url and the css we care about, it might be suitable to pass the same static routes over to DjangoDash to inject in the dpd template containing the iframe.

[delsim]

I've done some work to move this project onto a newer dash version, so we now have the benefit of the new template rendering in dash and I'm starting to think about how to leverage that to make the iframe optional.

@eddy-ojb - are you able to share any ideas or code from your own work? I'm keen to avoid duplicating work, particularly if it helps me avoid trampling on what you've already done.

[eddy-ojb]

Hi delsim,

I am on holiday without my computer but when I'm back in a week and a half I'll neaten my code and share!

[eddy-ojb]

The code is on its way shortly.

Whilst I have integrated my changes to the DPD code to show how I made this work, I won't be offended if you refine it as I don't have a mental map of how it all connects just yet. The way Django and Dash work is so different that I feel that I need to get stuck in to React and Flask to fully realize the DPD code.

I just need to scrub my demo and then push my version of the DPD code and a demo to a repo. Bearing in mind that I am not an expert in Git, would you like me to try pushing to your repo or shall I push to my own and you compare that way?

[delsim]

I wouldnt claim to be a git expert either! I think push to your repo, then send a pull request, is the best/easiest way forward.

[eddy-ojb]

I've made the request - I did try over the weekend but got quite frustrated with Git! This is my first push like this so not offended if you chop, change or reject. We will be sticking to this methodology for now though until we get our head around channels and how we can deploy with reverse proxy on IIS, then I would like to move on to your channels methodology.

[GibbsConsulting]

I've merged your pull request into a new branch off of the 0.6.0 tag. I'll use this as a base for pulling in parts of your changeset to trunk. It is not clear if this is the best workflow with git/github but it should work here.

[eddy-ojb]

The clean_dash_content function that I wrote in views.py in my branch can be replaced by the following:

dash_content = "".join(dash_content.decode('unicode_escape').splitlines())

Works across the different versions I have tested.

[eddy-ojb]

I have tested my html return vs the iframe method for a larger layout with callbacks and the load time is nearly 2:1. The iframe method is superior in this case.

I have noticed the 'html_formation' branch has been developed with some probably much more efficient code. I am happy to give this a test if/when it is ready - wondering if the load ratios are similar. If this runs reasonably, this still seems like a nice option as I find duplicating the static routes with Dash offline tricky at the moment, unless I am doing it incorrectly.

[GibbsConsulting]

html formation (along with a replication of the example kindly supplied by @eddy-ojb) directly into a template, so not wrapped in an iframe, is now in the published prerelease 0.8.0 version and it covers (I think) the goal of this enhancement request.

As a consequence, closing this issue. If its way off base then please reopen and comment. If there are bugs etc then please open a new issue.

[eddy-ojb]

@GibbsConsulting, once a project is setup to accommodate this feature, I have it found it works really well! Thanks!

[GibbsConsulting]

@eddy-ojb that's good to know, thanks!