One thing that can at times be annoying about building lots of different elements / user flows into a single page using custom states is that it can be difficult to maintain state if the page is refreshed.
If your user is navigating through a page on your app and clicks the back button on their browser, for example, by default they will be taken to the last page they were on (when very often the ideal behaviour would be to remain on the same page but to to return to the last “state” they were on.)
I was playing around with this problem the other week, and wanted to share one thing that I found works: https://youtu.be/LzfF18DySy8
Hope this helps!
This is awesome…wish you posted it a week ago. Last week I did a Bubble Bootcamp lesson that talked about custom states and I focused a lot on using the URL instead, for the exact reason you talk about having the page refreshed and the custom state lost.
One thing I am curious about is if you actually need the custom state? Couldn’t your conditionals for showing the different view just rely on the URL path, so as to avoid the page load workflow?
I know the plugins that have been up for a while that do this same type of thing, the paths are not recognized by Bubble in conditionals…is that the case with this method as well?
You should be able to set up conditionals to just look for the URL path. I prefer to use the page load method so that I only have to worry about writing the expression for setting the state once rather than each time as a conditional on the individual element. But it should work fine either way.
So I just got the chance to play around with this. It seems that the Bubble URL paths segment as a list is not picking up the URL changes
So it is not something that would allow for the conditional on the elements to reference the URL path segment and the custom state is required.
This works the same way the plugins for changing URLs do, in that Bubble URL paths segment list do not pick up those changes.
I wish Bubble would allow these types of changes to get picked up, as they would be so much better for SEO than parameters, as well as faster than the workflow action go to page.
Still a great way to change things when used in conjunction with custom states.
@boston85719 very interesting. You’re right, just using a conditional to reference the URL doesn’t seem to work.
jumping in here. I just made it work to save a custom state(list of texts) to add first the current paths and add another text then (which belongs to the clicked button). then i do: go to page (which must be the same page which is visible right now) and send data: custom state (which was just set)
with this method i can navigate in a one page app and always have the right paths in the url. my conditions in the groups are like this: visible when path list item: xy is group name-> element is visible.
i can go on back forward and so on and its always the correct page as well as the correct groups are visible.
maybe that helps you if I understood you discussion correctly.
I’ve just saw your video @jacobgershkovich. Nice work!
Why would you avoid URL parameters?
Also, how would you do if you want multiple search filters to apply?
For example, in a page you have date picker, amount and customer. How would you apply the filter so if the user copies the url and then he goes back, the filters get applied?
Thanks a lot in advance.
You my friend have just solved something I have spent days over the period of months trying to solve. You deserve a medal!