I hope my request is clear, as it touches on quite a few topics simultaneously. Let’s start simple: I am using the IFrame component.
Why am I using this component? Well, to embed a web page. Which page? I am loading another Retool app (or rather, module), such as mydomain.com/app/name-of-my-module.
Why am I using an iFrame instead of directly importing the module? Because I’m encountering issues when embedding the module inside a modal (more on that here, by the way).
Now, whenever I open the modal, the iFrame gets fully reloaded. However, this is not the behavior I want. Ideally, the iFrame should remain loaded so that I can access its content immediately, without having to wait for it to reload every time.
After investigating why this happens, I noticed some behavior described in your source code regarding visibility. I suspect the issue lies here: when the modal is hidden, the iFrame appears to unload or reload entirely. - I actually found more information about this on the official MDN page, for those who are interested.
That said, I really hope you can add an option to make iFrame content persistent, so it doesn’t reload every time the modal is shown or hidden.
I can elaborate on why this setup is critical to my workflow, but to summarize: loading an iFrame allows me to dynamically control the content, rather than having to load multiple modules and toggle them individually. This approach not only simplifies the process but also reduces the performance overhead of loading everything at once. (This is a separate discussion entirely—why modules can’t be loaded dynamically or lazy-loaded instead of being immediately initialized.)
Totally understand the ask and use case, thank you for describing it in such a clear and concise way.
I believe the root cause is that when a modal closes, all of its contents are removed from the DOM and when the modal is opened again all of its contents are recreated and reloaded because of the code of modal components.
So I can definitely file a feature request to see if there is something our engineers can do to support your use case and get around the code architecture without having to rebuild modals from scratch
A short term work around might be to have the iframe on the page to start, and set the iframe as hidden, and then it can exist on page load and not be depended on the modal.
Where it can be kept hidden until it is time to be shown and it won't take up space. This might need some testing to get this working exactly as you want.
In my mind, you could un-hide the iframe and then move/place it onto the modal, then hide it and move it off of the modal before the modal closes
Also! Exciting and somewhat related news, one of our top engineering managers for the UI team, @Jennifer_Zhang, asked the support team for a short list of module users for her to get in contact with to interview for a feedback call and I put in your name!
Thanks for the usual extensive response, it's appreciated.
I have managed to solve it in a rather creative way, namely by having two components stacked on one another, one of which is the iFrame, which is simply outside of view (i,e. using "Overflow: Hidden"). Then, whenever I need it, I simply hide the sibling component, revealing the iFrame automatically.
Although this definitely feels a bit hacky, and dirty, it allows me to accomplish my goal for now, However, I had to forget about my Modal implementation, because that doesn't seem to support this due to the forementioned issues.
I think the key in this solution is to be able to asynchronously load other content, so it there was a way to simply have modules load by their dynamic path/URL, rather than having it load entirely on its own, users would be able to load ANY kind of module, instead of having to import all of them and then toggle between them using visibility properties.
I know, it's a moutful, but I think this is key to keeping apps performant and efficient.