I've been making extensive use of modules, particularly leveraging the "Slug" property to enable access via a custom URL. However, I recently noticed that this setting has disappearedâseemingly within the past week. Instead of relying on UUIDs, the Slug property allowed modules to function more like standalone apps, which is crucial for my setup.
Can you confirm if and when this functionality will return?
Additionally, I would really appreciate it if such breaking changes were communicated more clearly. Given that you have the ability to detect which settings users rely on, outright removing a feature without notice is far from user-friendly. After all, there's no way to predict how deeply integrated these functionalities are in individual use cases.
As it stands, I have no choice but to wait and hope this feature is reinstated. My current architecture depends on it, and switching to UUID-based mapping would introduce significant maintenance overhead.
Hi!
Thank you for bringing this up! This is a byproduct of a rollout of another feature (the app level inspector)âwhile the fix rolls out on cloud, I can disable this FF for you so that you can add shortlinks to your modules!
Feel free to DM me your personal email / org email so that I can disable the FF for you?
Hey @emozio -- curious if you could expand on this part of your comment? Why are you wanting modules to act as standalone apps? And how do slug properties help you achieve this?
I'm glad you asked! It's a bit of architecture that has evolved from the limitations of modules, so I'd be happy to elaborate. I'm currently using an iFrame within my main app that leverages a dynamic URL. By changing the path along with a couple of hashtags, I can asynchronously load content from specific modules in the background. Then, I simply toggle its visibility to make it seem like it's instantly loaded.
Doing this the old-fashioned way would introduce numerous issues in terms of scalability and performance. Inserting separate modules would mean managing multiple components and their individual visibility, along with the fact that each module gets initiated before I have requested it to do so. This last part is particularly important, considering modules have their own queries that all start executing unless I provide some active output valueâbut this comes with trade-offs.
In my current setup, all I need to do is decide on a naming convention and then adjust the iFrame's source URL to get the relevant content. Better yet, when the hashtag in these iFrame sources is adjusted, the page doesnât fully reload but instead updates dynamically based on the hashtag values.
I've found this technique to work quite well, even though it may not be something youâd recommend in the documentation. That said, I do think there are a couple of takeaways for those developing and improving modules in Retool:
If there were a way to dynamically load specific modules, that would be quite convenient.
If any module could be loaded asynchronouslyâonly when it's visibleâit could also provide a performance boost.
Again, I'm trying to minimize the number of components and queries, as your docs mention that this affects performance. I'm using modules in the first place for this exact reason and to provide better namespacing.
Hope this helps give you an idea of how Iâm leveraging module URLs.
@emozio This is fantastic feedback. I'm an engineer on a team that's currently revisiting modules, and this is great information for us to have! Thank you for writing this up.
Right now, we're not promising anything as we're still in the ideation phase of what the future of modules could look like, but this is great feedback we will definitely consider. A big thing we want to tackle is performance of modules.
Love modules and basically every part of our apps is built with modules (and nested modules).
Multi-page apps have been a massive step forwards and work super well, but some of our pages are slow to load (ie 10 seconds) due to the presence of modules that often don't get used.