Architecture layout best practice: one page with multiple functions/groups vs multiple pages

I’ve been working on a multiple page web app where each page has a distinct function (client management, scheduling, etc). And am at the point of tieing them together with a side menu. As I struggle with spacing and formatting issues the thought occurred to me that I could create one page with the side menu that hides or shows functionality groups based on the menu option selected.

is there a performance, security or design preference to either approach.

From a design side I could see the importance of labeling being that much more critical as all of the workflows and other elements will be in one place. Thoughts on other pros cons?


It’ll take longer to load the page initially, but the show/hide of individual groups will be really speedy. I’ve done both approaches and tend to use whichever fits the context.

I’ve seen the same. Initial page load is a bit slower, but navigating between pages is almost instantaneous.

Also, from a architecture standpoint, if you go with a single page app, best to set it up so that the different views show up based on a url parameter so that you can link to different views of the 1-page app.


Good point about the URL parameters. Also want to be able to use the back button on the browser!


Yeah, the catch to using a one-page app is that the browser controls don’t perform intuitively. Like if someone clicks next in your UI and then wants to go back they might hit the browser’s back button, which will either reload the app or take them out of the app entirely.

1 Like

Great suggestion, this would solve a major frustration point in my app’s UI/UX.

´Hi Sridharan, I have been struggling with this problem for a while now:

I designed a 3-step form, all on the same page, with every step (1,2,3) in a different group which is shown/hidden based on the step the user is at.

I would like to be able to design the page in a way in which the next page or previous page button would make the application switch in between groups on the same page, instead of going to a different page/jumping back to step 1 from step 3 because of a refresh.

I imagined that the linking you proposed would help with that, any suggestions or other ways I can solve this?

Yep. If you change the URL parameter whenever users go to a different step, then when they click “back” it’ll take them to the prior step (since it had a different URL) instead of going all the back to the page before the 3 steps.

Here’s how to do that.

  1. When users click, say, the “next button” to go from step 1 to step 2, then have that run a workflow that loads the same page with all 3 steps and set a parameter for step = 2 to be added to the URL.

  2. Run a workflow on page load to set a conditional state = to the step number in the URL. Also, add a workflow to set the default step to 1 if there is not URL parameter for which step.

  3. Set the group for step 2 to conditionally display whenever the conditional state “step” = “2” (additionally, you probably want the other steps to be hidden unless step 1 or step 3 are in the URL)

That’s all it takes.

Here are those same steps in my app where, rather than going between steps, I have users selecting a tab:

Hope this helps!



@Tivano, Scott answered the question here! Thanks a lot Scott, I´ll try to implement it today still but I feel like it´s going to work out just fine now. Great!

1 Like

Why doesn’t this trigger a page refresh? Is it hardcoded in Bubble’s backend not to reload after navigating to the same page unless we specifically execute “refresh the page”?

I’ve wondered this too actually… why navigating to the same page doesn’t fully refresh the page.

1 Like

That’s a good question. Seems to me that when I have a background image on a page and link to another page with the same background image that the content changes but the background image doesn’t seem to be reloaded all.

Perhaps Bubble loads all pages with AJAX? …so content that doesn’t change doesn’t get reloaded?

1 Like


Hi Scott! Thanks again for directing me to this thread.

I’m a bit confused at the last step. In your screenshot, you seem to refer to the page URL parameter in the same way that you would refer to a state. However, following the steps, I can’t see that the parameter shows up in the Conditions window. How do I find it?

I would hope this never becomes a ‘thing’! All of my apps are single-page apps that rely on the browser not refreshing — when I want to change the current visible Group I send traffic back to the same page in order to modify GET key/value parameters in the URL. I suppose this could be split off into two different nav functions: one that actually goes to a new page and refreshes, and another that skips the page navigation altogether and only asks you for updated URL data (ie Get Data from Page URL).

1 Like

I’d hazard a guess, based on the node backend and functionality similar to express/angular, that Bubble is running a router, which applies rules to decide what to do with a url.

Great point @petter. I’ve updated the instructions and added a new screenshot. My apologies for the oversight.

Thanks again! I’ve got it solved now, thanks to you!

I have one challenge though; even if the page does not reload, it seems to reload/re-search repeating groups. Which means that navigation that used to take a tenth of a second now takes about 6 seconds, and the same to go back. Also, repeating navigation doesn’t “remember” the search, it has to do them all over every time a user goes back and forth.

Is there any way to avoid this, and still get the benefit of using the back button?

(this does bring up my number one concern using Bubble in general – why does it need 6 seconds to load a repeating group with 3 items?

@petter, I’m not sure what the solution would be for that.

One potential work-around would be to save the RG in a custom state and then have it load the custom state when the new URL parameter is loaded. If the custom state works, it’d be a lot quicker than hitting the database with a search query since it’s run client side.

1 Like

I tried that, but it’s just as slow. In this particular app, the navigation is very much based on RG’s (it jumps from list to list, say “Company” -> “Department” -> “Employee” -> “Item” as the user clicks. So even if there are few items in each list, it’s quite “RG-heavy”.

Even when I load the RG’s into a custom state, it takes about 6 seconds to jump back and forth between stages, but no time at all when I don’t use Go to Page. Also the header and everything else blinks and reloads, it doesn’t look very smooth. I suppose an app of this sort is not the best for this particular method.

For my other apps, I’ll be implementing this though, thanks again for explaining it, I appreciate it!

I build Dashboards as One Page and use show hide groups for navigation. I tried many times to find a solution to send URL parameters to groups and use customer states to SHOW/HIDE Groups and be able to access the tabs using the URL Link.

I think I found the way to do that and wanted to share with you.

The best way I have come to do and seems to work with me is by using Custom States on buttons to show groups and use “Go To” send a parameter to the same page. And create a conditioned workflow on “Page Loaded” on the same page that loads that custom state and URL parameter of it.

Follow the example below:

Let’s assume you have a dahsboard page with three Tabs: Orders, Products, and Settings.
If we click on the Orders button, the Orders Tab will be shown and the link of the Dashboard page will be updated with orders parameter.

First we create a custom state on the button to show the Orders Tab.

Then on the same button we make it navigate “Go To” to the same Page and send a parameter with “Orders”

Lastly, On the same Dashboard Page we create a conditioned “Page Loaded” with that custom state and Parameter.

Now if you create the above procedure on all three tabs Orders, Products, and Settings. You will be able to use the browser back button and the tabs will be accessible using the following links:

The only down side of this method you will need to have a “Page Loaded” for every tab. Which if you many tabs you will have to create several “Page Loaded” workflows.