We are creating an UI with many sub-modules. What I simply want to achive is, I would like to show/activate selected module on the main screen.
Actually we achived this with "Tabbed Container" BUT It loads/renders all the imported modules at the same time. I just want to RENDER selected module ONLY WHEN user selects it from menu.
The reason behind of this, all the modules have their own "on page load" queries, and in current situation they're all running their own queries immediately because they are already placed in "Tabbed Container". Actually what I am looking for is, "Tabbed Container" with lazy-loading - or similar workaround for this issue.
This is something that is on the radar for our dev team but at the moment I can't give you a timeline for when this kind of behavior will be supported.
In the meantime, you might consider having the queries that run on page load within each module be triggered when the tab is selected. This post has more information on how to trigger queries within modules. If you pass a conditional like {{ tabbedContainer.currentViewKey === 'view key corresponding to your module' }} as an input to your module you can also set those queries to run only when the appropriate tab is open.
Let me know if that seems like it might work for you or if your use case differs!
Do you have any updates on this? I'm needing to implement some strategy like lazy load to prevent the app to take 20secs to load and get slow during usage time.
Any workaround besides running the queries of the module when the tab of that module is selected? I have 5 modules and hundreds of queries so this would be a weird/slow solution to implement in all of them.
No updates yet. The only workarounds I'm aware of are a bit more general and may or may not apply to your design. There are a number of recommendations on how to improve performance on this docs page. In particular, you might try splitting your app into separate apps that share a header/sidebar. With that and a combination of query caching and local storage you may be able to achieve an experience similar to lazy-loaded components.
I've experienced the same thing, I would really expect this to be a default option, i.e. to have modules be loaded lazily.
In my case I want to toggle a modal, but since that modal contains a form, it ends up loading many queries even though it shouldn't load these until the form is requested.
I know there is a workaround to accept an input parameter (called active for example), and then conditionally disable queries based on that value, but this doesn't feel quite like the durable solution in the long run,
I sincerely hope that this feature will get a higher priority, given how modules are the only way to build scalable applications in my opinion, but this issue seems to disallow for this strategy to actually be useful.
Thanks for providing your input and perspective, @emozio! I'm glad that you have a functional workaround, but agree that it could certainly be cleaner.
I'm happy to report that modules are on our roadmap for next year, so I'll be sure to bump this particular feature and add it to the relevant project.
If I could add something to this discussion, which is closely related: if it were possible to import modules while editing, without executing their contents, that alone could significantly improve performance. Especially in cases where modules include multiple queries that might run in parallel—often unintentionally—this could make a big difference.
I understand that a core part of Retool’s appeal is its real-time UI feedback. Still, introducing a sort of “static mode” during editing—just to prevent modules from running until explicitly triggered—could go a long way in making the editor more performant.
Just to give you some context into the conversations we've had internally, it's been challenging to clearly define what "lazy loading" means in the context of modules. Should it be tied to the hidden attribute or to lower level lifecycle states, for example? While we are targeting the overall performance of modules in our current development work, lazy loading won't specifically be part of the initial revamp as a result of intricacies like this.
I did have one idea, though, that may be relevant - what if we exposed a Disabled attribute on the module itself that could be dynamically set in order to control whether the contained queries run?
