Thoughts on Novel Approach to Dynamic UI

I’m in the process of building my second application in Bubble. We’ve already built out our data structure and wireframes and are preparing to move forward with the actual build. That said, because our app is fairly complex, we had developed a somewhat novel approach to building it in Bubble, with the goals of increasing performance and allowing our team to make minor UI tweaks without fussing with the editor.

I’m not an engineer by training and would love to get some insight from the community on any unforeseen stumbling blocks adopting this approach might imply.

Essentially, we’re building a SPA with a very modular UI that relies heavily on conditional logic URL routing (via @sudsy’s Sudsy plugin) to pull the appropriate UI modules in for each page. From the front-end, our team will be able to spin up new pages, add modules and reorder them on the fly.

Our module libraries would be housed in a few master reusable elements — similarly to the homepage builder that Airdev (@stephanie @vlad) built for their Canvas framework. Reusable elements would be housed in repeating groups on the page, and the UI for a given cell would be defined via conditional visibility rules.

Clear as mud, right? In all seriousness, though, I would be grateful for feedback here, particularly from those who have adopted a similar approach (@keith, ever done anything like this?) . Our goals are to increase performance for the end user and simplify app management for our team.

Thank you all!

1 Like

Hi mate, we’ve been working on a full ERP application, with each of the core functions in separate modules, built in Reusable elements and using the URL parameters to hide and show content. Each company (tenant) and user within those companies will have access to different modules and sub modules and all of this can be set up on the fly without any developer touch.

So I think we are using a similar approach - although I’m not embedding my reusable elements in Repeating Groups (I’m not sure how that would work) as each one is likely a different data source. I just have all my reusable elements (modules) hidden and stacked on top of each other. We also have some in second windows (like a slim panel on RHS of screen when in full desktop mode) and some are utilised in pop-ups.

We haven’t run into any problems. Performance wise it is working well. And from a dev productivity perspective it is easy to manage as we rarely need to work on the main page (i.e. most of the work is in the individual reusable elements).


If by “stacked” you mean “z-stacked” (as opposed to “y-stacked”), the only thing I’ll say is that the former approach opens the possibility of layout issues, as I learned when assisting with this post. (I created a simple demo/test page.) A former z-stacker, I now y-stack all of my initially hidden elements. I don’t use a ton of reusable elements, though, so I can’t say if/how things might differ in that context. Needless to say, the editor page can get pretty long, but navigating the editor by clicking elements in the elements tree (as opposed to scrolling) is still quick and snappy.


Thanks mate. I haven’t experienced any adverse layout issues yet but I’ll keep an eye out for it.



1 Like