Question about Module Best Practices

đź’¬ App Building
1

After revisiting the documentation, I came across the following recommendation in the Best Practices section:

Minimize hidden components: Avoid creating a module with a large number of hidden components. Hidden components must still be rendered and can have an impact on app performance.

This raised a few questions. What exactly is meant by “hidden components”? Given the nature of modules—which are often conditionally rendered—I would argue that, by default, components are hidden unless explicitly invoked. So I’m curious how this guideline should be interpreted in that context.

In our case, we’re using modules to structure detail forms. These forms can include 60+ fields and typically span around six tabs. While each module has associated queries, we disable those unless the module is actively loaded (which, frankly, feels like something that ought to be supported natively—but I digress).

What I’m trying to understand is whether the number of components alone can impact performance—even if they’re not visible. We noticed that, after importing all the various modules into our app, the browser nearly crashed while editing. That experience made me question whether the modular approach is actually helping or hurting us.

If there is some limit to the amount of components, and by extension modules, then I am curious to know if modules are still serving any value when it comes to decentralizing UI and logic.

As a workaround, we’ve started loading modules in an iFrame, swapping out the URL contextually. This gives us asynchronous loading and a cleaner separation of concerns, but it does feel like a workaround rather than a long-term solution - it has several drawbacks, which I won't get into now.

One open question: we’re using the URL’s hash fragment to help differentiate between the primary key value. Could that part (i.e. the hashtag) be causing issues? For instance, could it be possible this is triggering some kind of unintended re-render loop?

Any thoughts or insights would be greatly appreciated—we're currently at a crossroads and struggling to determine the most scalable architectural approach.

1 Like
2

Hey @emozio -- are your modules loaded into a single app page or on separate pages of a Multi-Page App?

I use modules pretty extensively to organize business functions and be able to better control the user experience for new features. I haven't run into any major performance issues when using Multi-Page since the modules aren't loaded until the page is active. I might just not have as much going on as you yet so I'm interested in the other responses here as well.

1 Like
3

Single app. Multi-page just takes too long to load. It's what I've tried though.

My main question really concerns both adding multiple modules that contain relatively many components - and whether or not that affects performance.

If that's the case, then I honestly don't know the best way to organize things at this point. But maybe I'm overlooking something.

1 Like
4

Hi @emozio,

I saw that you ended up meeting with some Retool folks to discuss your modules feedback in more detail :slightly_smiling_face: (thank you for meeting with them!) As mentioned on other threads, we have a team looking into some module improvement projects (no specifics at this point). I hope that helped in terms of considering what could make it onto our module roadmap in the future

Modules themselves don't necessarily impact performance. However, one thing to consider is that the number of components within a module is added to the number of overall components in the app, which does ultimately contribute to performance. Our team is exploring ways to dynamically load modules, which could help with app performance. I haven't seen the idea of loading modules in an iframe before, but I imagine a native way of dynamically loading modules would definitely be preferred and easier to integrate :crossed_fingers:

I'm sorry to hear that multipage is taking too long to load :disappointed: While its difficult to say specific numbers, a multipage app with a large total number of plugins (components, module inputs/outputs, queries, etc), spread across many pages, can eventually become slow on initial load, but it’ll be significantly faster than a single page app with the same number of plugins. Each plugin that exists in a module will contribute to performance, whether or not they are visible.

The benefit of multipage is that some of the work done on initial load in single page apps is skipped for multipage apps until other pages are focused. That said, some of the work done on initial load is the same for both multipage and single page apps.

2 Likes
5

Hi @Tess,

Thank you for your thorough response, and again, my apologies for the late response. My priorities have shifted, and clearly my attention along with them. :wink: However, I wanted to make the effort to respond to your thoughtful message.

I appreciate you explaining all of the inner mechanics and any influences it may have on either modules, multi- or single-page apps. My experiencing has been that loading pages separately simply took too long and was missing some caching intelligence, in my opinion. Modules was our attempt to spread out our detail forms across the app, but after embedding several of them into the app, we found that this had a negative impact on performance.

I've considered many architectural options, but at some point was sort of forced into one that I thought made the most sense for our goals: using modules and loading them as iFrames onto the page, asynchronously.

If modules would be async and loading could be triggered depending on certain conditions, that would be a game changer, if you ask me. That would allow you to make things more DRY, without sacrificing performance.

Anyway, just some thoughts I thought I'd share.

1 Like