Create an option for each tab, optionally add a slug to each, and make RE visible only when Get tab from page URL is Get an option (the relevant tab option)‘s slug
Or, for the long form that describes it far better than I ever would:
Thanks! But since my tab is a reusable element and not an element directly on the page. What page should I use in the workflow? Is current Page the right one?
Probably not if you want them to be navigated to another page. But if you just want to change the URL parameter value, then yes, that would be fine.
Never waste your time with custom states in conjunction with URL parameters. If you are using URL parameters use them alone. I’ve seen too many people use custom states when also using URL parameters.
Create an option set for each of your url parameters that you will use. Make the display value all lowercase. For example, if I have a URL parameter of mode, and another of reference, I will have two options in the set, one is mode and the other is reference. This way, whenever I use the Get data from URL I can reference my option set as the parameter name so I don’t have to try and remember what they are.
If you are going to use option sets for the value of a parameter (ie: not the key name) make sure you have the display value all lowercase, and if you have a space, you could change it to a -…this will make it easier to read the URL values as the encoded values for a space can be difficult to shift through and the proper structure of URL is no uppercase letters, so should use lowercase. Additionally, Bubble has a bug that when you continuously refresh the page with parameter values in the URL and those values are special characters, such as a +the url encoded value of that special character can become messed up and reverts to the url encoded value of a space. So, in the display value, avoid special characters.
When you have a group on the page, that is supposed to be shown based on the URL parameter value that is an option, set the data type of the group to the option set type, and set the source to the option it is to be visible for. Then set the conditional to be Get data from URL is this groups option value. Change parameter to make it visible when condition is true. Set the ‘visible on page load’ to no and collapse when hidden. Then after you set up the first, simply copy and paste and change the datasource for the next…this makes it so you do not need to keep setting the conditionals, especially useful for a SPA or dashboard page with multiple groups.
When you use the Get data from URL which is for the parameter, and the value of the parameter is an option, do not leave the type as text, but instead declare it as the option set…this way Bubble will URL decode the value and it will match your option display value. This is especially helpful when you go to save the URL value as an option into a data field that is an option.
The only time to leave the type as text when using the Get data from URL is when you want to determine if it is empty or not, otherwise, you would likely always want to set the type to the proper type of data that it is.
For more advanced usage of URL parameters check the other posts below
Thank you very much. There’s a lot here I need to familiarize myself with.
I tried this just now, and I can see the slug in the URL. However, the content does not change. I’ve definitely overlooked something. Can you see what it might be?
This I think is the problem is that you have an attribute called slug instead of just using the option set display value. If you are using an attribute, bubble doesn’t pick it up as the option, but when using the option display value, bubble picks up the correct option.
Likely better to use another attribute for the parameter, as there’s cases where you may want the development / behind the scenes identifier for the option (the display) to be different to what is shown in the URL parameter.
So @Xtine the problem here as @boston85719 rightly pointed out is that you’re sending URL param v = option’s slug, but the condition refers to v = option (not option’s slug)
It’s a quirk that URL parameters must be text (hence you can use Display or Slug, but not the option itself, because the option is an option, not a text).
Get v of type option set works because, generally, using the display of an option set in the parameter will allow Bubble to work out the relevant option. However, Bubble starts playing weirdly when you change the display from what it originally was, hence I try and use a slug / id field to make sure I can control this.
Could you provide some instances and explanation on why that would be the case? For me personally, I’d prefer to make use of the ability to more easily save the data from the URL as well as access it via dictating the type as the option set itself. This reduces a need for filtering to find the correct option, as well as reduces the length of the dynamic expression, which can speed up development time. I also use this approach as it is easier to debug, maintain and add to the option set list. I also use the operators in dynamic expressions to manipulate the ‘view’ on the screen to the user, so display value is lowercase with no spaces but uses a -I can operate with find and replace for the -then use operator for uppercase or capitalize words. It also helps when using these values in an API call as the parameter values for API calls would like be structured similar to a parameter value of the URL with lowercase and no spaces.
That is a case in the logs, but the sending of the display value to a URL parameter is not affected. And neither are set data sources on groups or other elements that reference the option set.
In the end @Xtine everybody will have their own personal preferences for how they handle things. I used to use the attribute approach but have since decided to move away from it for most of the reasons I have outlined for why I use the display as opposed to an attribute. Either approach works, and each will have benefits and drawbacks.
When the name for a data abstraction is different from the developer side to when the user sees it (e.g in one app I have a data type and app structure that refers to Organisations but users see this as Teams, so I want Organisation to be the option name but Team to be the url param. Or, if I have an upsell tab and I don’t want the user to see that we’re upselling them, I’ll want the URL param to be ‘addons’ or something
In terms of the display changing, that also becomes relevant when using backend workflows and calling them from the front end (this is especially important now that mobile native is coming as only BE workflows are shared). You can’t reliably pass an option’s display to a BE workflow as Bubble can’t seem to parse the option correctly. By having a static ID attribute that that I can set and then leave and ignore, and using that when trying to call BE workflows using API / app connector, I know that it will always work no matter what I do to the display that might be used elsewhere in the app.
Is that in a situation now where a backend workflow with a text parameter is being scheduled and passed the display value as text as opposed to the parameter being the option? I normally send my option set as the parameter and then reference in the backend actions the display or other attributes, so I have not encountered the name change issue there myself. Or is this in terms of mobile native apps?
I have not played much with using the backend workflows with API calls to the app, so do not know how the option value needs to be sent via the API call. Do we need to send them through as the original display value, like what is shown in the logs tab when the display value has been changed? I recall you pointing that the logs show the original display value to me when I thought my logs were showing the wrong option used.
I am in the middle of making some changes to an app. I previously had some pricing data I didn’t want the user to see stored as an attribute in an option set and decided to move that to a data type so I could use privacy rules to keep users from seeing it. I have not checked the console to see if an options’ attributes are visible or if it is only the display value so I thought to be safer with the pricing info and not use the option attribute for that.
Scheduling using schedule API workflow works as normal using the option itself as the type - I’m just talking about calling your own BE API workflow via either the API Connector or the App Connector
Sending the display via the app connector will not work if the display is different to what it was when the option was created originally
Option set attributes are visible - but I don’t really care if a curious user can see that option Y is a sneaky upsell. 99% of users will never know and it’s not a security issue in the example I gave, just a minor user experience thing.
It seems you are doing the same thing, but you also have a key for “d.”
Here is what I did:
1. I use “Go to page > Current Page > Send more parameters” (the parameter is V=current cell’s slug) when a user press the tab-button.
2. On my page, I set the visibility of elements to “is visible if: Get v from page URL” and reference the same slug (using option sets).
However, my content does not display when I click on the different tabs.
If you use go to page v = Option’s slug and have a condition to be visible when Get v from page URL is Option’s slug, where the same option is in both expressions, the RE will show (and make sure you’ve actually specified a slug for the option!)