You've likely heard about Single Page Apps (SPA) at least once on the Bubble forum. Since Single Page Apps don't navigate users to other pages, it's crucial to figure out how you'll handle content visibility.
The answer is with URL parameters.
Single Page Apps (SPA) don't use traditional page reloads, but that doesn't mean they don't need URLs. URLs are just as crucial in Single Page Apps on websites with multiple pages because they handle user navigation.
What are URL parameters?
The URL parameter is the text of a URL that follows a question mark. It consists of a key and a value, separated by an equal sign. Multiple parameters can be added to a single page by using an ampersand.
URL parameters are standard and are preferred by nearly all the top tech companies to transmit information between pages. But we can also use URL parameters to show and hide different groups on the same page.
To learn more about using URL parameters, read.
What are Single Page Apps (SPA)?
A SPA is an app that does not require a browser refresh. Facebook, Twitter, Gmail, and GitHub all use some form of SPA.
Therefore, they are fast.
When to use a SPA?
SPA is perfect for some use cases while not suited for others. Some common instances in which it makes sense to use a SPA are
- You are creating a native mobile application. SPA will reduce your page load times, and you can use beautiful transitions to give your app a native feel.
- CRM. Most CRM apps have a single page and use the sidebar to show/hide different content.
- Project management tools
When not to use a SPA?
Tread carefully if the app you're creating falls into any of the six examples below.
- Ecommerce sites
- Catalogues and listing platforms
- Social media apps
- Sites which rely heavily on SEO (blogs, podcast directories etc.)
This is not a statement that applies to all cases. We can build these applications as a SPA, but we need to be aware of potential problems.
The reason is site performance. The apps mentioned in this list heavily rely on pictures and videos. And media can significantly impact your app performance if the app is not optimised.
Feel free to build away if you're confident in your knowledge and mindful of the challenges.
Why use URL parameters and not custom states
A common approach used by Bubble beginners is to use custom states. It's not wrong, and even I was guilty of using them for a long time. However, custom states are not efficient.
The biggest drawback of using custom states is that they reset whenever the page is refreshed. Another disadvantage is that your users cannot use the back button in the browser. If they do, they'll be navigated off your website.
Consider a case where a user lands on your website https://xyz.com/. If you're using custom states, the user will be navigated away from this page when they press the back button.
If, however, you use URL parameters, when they navigate from https://xyz.com/ to https://xyz.com?product=1 and then to https://xyz.com?product=2, they'll be navigated back from https://xyz.com?product=2 to https://xyz.com?product=1.
As a result, they'll still be on your website. And this makes sense.
No professional Bubble app uses custom states. They all use URL parameters.
Even Amazon, Facebook etc, use URL parameters. Don't believe me? Check the URL the next time you're shopping on Amazon.
How to hide and show groups using URL parameters
I have created two full-width groups to demo how you can hide/show different groups using URL parameters.
Clicking on the blue texts will change the URL structure of the page. This, in turn, will hide and show different groups.
To begin with, we need to make all groups hidden on page load.
Next, we want the height of the hidden group to collapse when hidden. This will ensure that there is no empty white space when a group is hidden.
Once this is done, we can set conditions for each group on when to show them. We only need conditions to show them as they are hidden by default.
I'll use the word "tab" to denote which group I want to show. You are free to name it whatever you'd like. It does not matter. So when the parameter "tab" in the URL matches the visibility condition, that group will become visible.
Go to the Conditional section of each group and create a new condition.
Do the same for all the workflows while keeping the parameter name the same but with a different value.
Setting up workflows
We need two types of workflows
- When the "tab" is empty
- When the "tab" is not empty
We can set a default value when the "tab" is empty, or the page has just been opened. This can be useful if we want to show a fixed group on page load.
I'm creating a workflow that if the "tab" is empty on page load, the "tab" value should be updated to 1. This will make Group 1 to be visible.
The other workflows that we need are when the "tab" is not empty, and we want to show/hide groups.