We’re launching a new feature that will allow you to use the Go to page… action to navigate to a page dynamically given the context of the action. Previously, you were only able to select from static page names. This will allow you more flexibility to change and remove parameters on reusable elements without reloading the page using “Open an external website” or using conditionals on multiple Go to page… actions. See relevant documentation here!
When you select the Go to page… action, on the Destination field, you’ll be able to select from existing page names, the current page (Current page), or a dynamically specified page (Dynamic page…). When you select Dynamic page…, you will see an additional field for Dynamic page name where you can create a dynamic expression to specify the page.
When you select either the current page or a dynamic page as the destination, you will not be able to access the Data to send field. This is because the type of Thing of a dynamic page cannot be verified from the property editor. As a safeguard, if you select the current page, whatever data has already been sent to the page will be preserved, so the page contents will not change. When you select a dynamic page, the Data to send field will be cleared because you may be navigating to a different page on which the contents and required type of Thing may change.
Ahah, it feels like you slalomed between all my ideaboard feature requests end-motivations in this update
Some feedback:
I think it would be very useful to provide a dynamic Data to Send as well (like the ID of the thing)
Same for the Data to Send on the current page, I understand the safeguard but in my opinion it’s not worth the loose of the feature.
Maybe a “change Page Data” checkbox to reveal the field?
It would be amazing to make the Data to Send optional for pages with a Data Type setup. This would make blog page way easier to work when trying to optimize the URL path (eg. xxx/blog and xxx/blog/slug)
This is a great addition. Currently using the Arbitrary text and then having the slug url pull from the database, but this will save some time and efficiency on the navigation , while also not having to open in new tab, for the other feature update. Thank You!
It would be really awesome if we could access the page name as a built-in option-set-like value. For example, instead of having to copy and paste the raw name of each page as a text, being able to save the page’s name as its own type. Right now, we accomplish this by having an option set called “Pages”, but any time we change a page name (not often, but it happens) we need to remember to update the option set. Having this occur automatically and saveable to objects and other option sets as a built-in page option set would be amazing. Either way, super happy to see this feature @grace.hong !
Well, damn, you had me excited for a second but not including the data to send input on the current page option removes the way I (and now many others) use the go to page action to create clean urls in a SPA.
So I thought maybe the dynamic page would allow me to include additional paths in the page name but that doesn’t work either.
What a bummer. Have waited years for a current page feature on this action but it’s quite useless without being able to append text to the url you are navigating to.
Here’s a walk through on using go to page to create clean urls so you can see what I’m talking about.
Will be doing more work with dynamic pages here soon. Can someone explain to me (like I’m a 12-year-old) what the purpose of this new feature is and how it will help me create dynamically generated pages for different things? I don’t see how this is any different from just using the “open external page” option.
Thank you for this!!!
You just cleared a bunch of unnecessary steps in my reusable’s workflows as I work with URL navigation a lot and had to set specific destinations for each page they were used.
This is certainly not a feature aimed at me, but thinking about it I don’t really see how it’s different functionally, but just a different interface to the same sort of thing. I might be missing something.
Yeah same. Is this just the Bubble team trying to help less technical bubblers feel more at home? Ton of excitement in this thread, though, so I also feel like I’m missing something.
If this is in fact just sort of a duplication of existing Bubble functionality with a different interface, at least that’s something we don’t see much and this trend would be most welcome.
There’s a lot of strange or convoluted stuff in Bubble that could use better/different interfaces, that doesn’t seem to get much love. In JS (and other languages) such things are often called “syntactic sugar”, because, the easier/better interface doesn’t actually do anything different under the hood, but provides a clearer/easier-to-read/easier-to-understand way to accomplish the same task. Bubble has very little syntactic sugar… If the medicine exists, you are obliged to take it without sugar, even if it tastes yucky.
There are good reasons for not having stuff like this. For example, any duplicative feature necessarily adds some code to one or more of the functions that constitute the core of Bubble. My sense has always been that, if a way to do something exists currently, Bubble is loathe to introduce another (better) way to do it as they must generally continue to support the other way as well.
But… ya know… if we’re going to increase the Bubble core payload a little bit, would we rather see stuff like this, or would we rather see… you know useful stuff like a generic map/iteration feature. I know what I would vote for…
Can you explain how exactly you would be using dynamic data in the context of SPA?
I might be missing something.