Yeah. Unfortunately they didn’t have the ‘is in’ for everything until last month (Nov 2023), which meant it was not possible to do easily if you don’t want to display unique ID and instead want to display a more human readable format like the name of the thing, or use other value sets like option sets.
Don’t cause that to be a reason not to deliver to your app users a good UX and feature sets. But, if you have things setup and working the way you want that is great.
Correct, then it’s only the performance issues
You can have the advantage of custom states using URL params as a backup (for reloading etc.)."
@brad.h going back and reloading page are actions you don’t want to promote (WU consumption) so its a case-by-case judgment of balancing UX and costs.
That would be reason to make it so a search page when a user clicks a particular entry doesn’t navigate to a new page, and only opens a side bar or drawer to show the details of the selected entry. When using URL parameters and using the navigation go to page workflow action to change those parameters, the page doesn’t reload, so there shouldn’t be any WU consumption for that.
What performance issues? Have you tested and seen a demonstrable performance reduction when going beyond 3 items that the parsing takes considerably longer? Or is it an idea that URL parameters take longer to parse a list of parameters versus using a custom state that is a list?
There would be no advantage or real reason if you are using URL parameters to use custom states at all. Once you use URL parameters, you don’t need custom states so it would be both a drain on the resources the developer puts into putting the system in place to use both URL parameters and custom states in tandem as well as the performance issues of having parse the URL parameters and then set a custom state with the parsed URL parameter values.
For me, it is always a one or the other decision, either use custom states or use URL parameters. The most important factor in the decision on which one to use is the sense of what type of features you may want to incorporate, such as emails with direct links, or notifications systems with direct links (ie: new booking notification takes the user to the dashboard page to the booking section with only the new booking displayed in the RG), things that can be done solely with URL parameters, but if you wanted to use custom states you’d have to tie it together with URL parameters as well.
Yes I have but not recently. And maybe its not considerable with 4 or 5, but in large numbers it sure is. And its logical as well: search records (simple search) and set RG data source OR search records → extract UIDs → add UIDs to URL → search records with a large contains list! 
and set RG data source
This is very different retrieving a single record via URL parameters where the constraint is = UID and not contains
For those you don’t do a search. Instead just on the Get Data from URL dynamic expression you state the type of data is not text, but instead the actual type of data…so if the UID in a URL parameter is the UID for a product, and in the DB you have specified the name of the data type as product, when doing the Get Data from URL you use the dropdown to select the type as product…this way no need for a Do a Search since Bubble does the single item search for you. It works the same way the page content type works.
I might be confused and misunderstanding this but, when using the URL parameters as constraints you do not need to do much except just put into the search constraints on the RG itself, so no need to set RG data source via workflow actions. Instead it would look like this below
In the first screen shot it is simple to have the Get data from URL value in the constraint directly as done for Delivery Available, the distance and zip code. For the Neighborhood constraint I use option sets instead of data types as the option sets are faster to parse since they are already loaded on the page and do not require a Do a Search and interaction with server.
I personally have not tried using UIDs for data types on URL parameters, except for single items, because Bubble will extract the value automatically when you state the type is a custom data type from the DB. I would expect that if needing to use the UID of data types as a list parameter, it would slow things down due to the fact that you have to do a search to find the list of data entries.
However, if I were using UIDs as a list parameter, I would not need to do a search in the way that I would set up the app. Since the use of these URL parameters is to filter a search, you’d expect that the user needs the filter choices available to select from via a side bar of some kind, so the filters will need to be on the page already, normally as a repeating group displaying the filter choices in the side bar…so instead of needing to Do a Search for the UIDs in the URL parameter list, you can simply refer to the RG in the side bar that already has the entire list displayed and filter it, so you eliminate the need to Do a Search for the filters.
But in the end, I wouldn’t put UIDs into a list parameter as it is a messy URL and I would opt instead if I need to use a list of data entries from a custom data type in the database to use the slug field or another unique identifier that I create as a field, really just to reduce the clutter of the long UIDs.
You seem to be going back and forth on whether the url parameters contain a list of things (like your post quoted and the actual topic of this thread) or parameters for a search of a list.
Example:
to which you replied:
So I said there are performance issues with a large list in the URL parameters, and you asked me what performance issues there are with using search parameters in the URL over a custom state?
I’m unsure how to respond, but to sum it all up: A large list in the url is sub-optimal performance. Parameters in the URL are totally fine.
Yes I think you are confused about how I am replying to your comments.
For starters, I am asking questions to find out if you’ve done enough testing and research to be providing quality insights into something, I myself may not have tested. So, me asking about testing for performance issues with URL parameters that are a large list is a legitimate question as I never tested it with a console log or anything other than my naked eye, which could always be not as accurate as tests using browser tools which are beyond my technical capacities.
But in that question I was not sure what the point of highlighting what you’ve found as performance issues, since the original poster indicated they switched back from URL parameters to custom states, so I was confused if you were making a declaration that performance issues with URL parameters that are a list of things was in comparison to the other approach discussed in the thread, being custom states. So, the concept there, is, that if you need to filter based on a list and have two choices, custom states or URL parameter, which has better performance.
When you answered the question you provided a response as below
Which in my experience would be reason for performance issues as the implementation of the URL parameters as a list is not optimal itself, so I provided insights into how to use them properly, not just for you, but for anybody else who may stumble upon the thread and are interested in advancing their understanding of how to work with filters, be it through URL parameters or custom states, since there is no reason to set the RG datasource via a workflow action as in your explanation of the approach you used in your testing.
It is the same concept, whether you are populating the list of things in an RG directly from the URL parameters, or you are using the URL parameters as a constraint on a search, the actual extraction of the URL parameter (list) is the same, it is just that those values are used in different places.
I also read through other comments before I joined the conversation and saw comments that to me are referencing the use of either URL parameters or custom states for filtering
This very likely is true, to which I’ve never refuted…I think I was more focused on what I saw as the topic of conversation which seemed to me to be a comparison of using custom states versus URL parameters for filtering a list of things to display in a repeating group.
Seems like maybe the topic was as you saw it to use URL parameters to populate a list of things, rather than to filter a list of things. Which, yes, I would not use a list of Unique IDs in a URL parameter to set a repeating groups value. I only use the URL parameters as a list for filtering.
Thanks for clarifying we have been on the wrong page when understanding the topic of discussion.
