Search for an Option Set quickly (`:filtered` too slow)

Need help
1

Set up:

  • Have a bunch of tags as option sets. tags - color: blue,green, etc, tags - features: modular, outdoor, etc
  • Users can search for the tags they want to apply to filter products
  • Once tags is selected I apply that tag as a parameter in the URL i.e color=blue

Problem
When users search for a tag it is processing the search too slowly, it needs to be extremely quick. I presume this is due to the :filtered set up.

Current set up

  • When a user searches for a tag a bunch of RGs are shown (one for each tag type: Color, Features, etc)
  • Each RG Data source is: All [tag type] tags: filtered - filter: Constraint: This tags display contains [search value]
  • When a user clicks on this tag in the results, I use both the Option set (Color) and Display text (Green) to pass into the URL parameter [url]?color=green.

Other implementation options and their issues
Was thinking about having one RG combining all Option Sets All Color tags: each tags display :merged with All Features tags: each tags display to give a list of texts that I can just apply a :contains [search value] to. This should be a lot faster than :filtered. BUT. Since it is a list of texts (Green, Blue, Outdoor, etc) I can’t pull the option set name (Color, Filter, etc) to pass to the URL parameter.

Open to all suggestions…

RGs for each Option set in search results:

Lookbook___Bubble_Editor
Lookbook___Bubble_Editor1994×640 51.9 KB

RG filter:

Lookbook___Bubble_Editor
Lookbook___Bubble_Editor1518×1174 155 KB

2

Hi there,

This is how I approach option-set filtering, and admittedly there may be an easier way, but this is what I found and it works quite fast, without any advanced filtering.

I treat each option-set as a separate URL parameter, so in my use-case I’m using recipes, and the option sets are ‘Allergens’ (Gluten, Dairy, etc) and ‘Characteristics’ (Sweet, Fruity, etc). Each can have multiples chosen. When filters are selected, I send them to the URL parameter like this:

Multidropdown’s Characteristic’s value:format as text. Under Format as Text, I choose to show the Display, and my delimiter I use an underscore, mostly because I know I don’t use it elsewhere so I won’t have any issues splitting later on.
image

This is how it shows up in the URL:
&characteristics=Fruity_Minty&allergens=Peanuts_Soybeans

Now here’s where my workaround comes in- for each Option Set, I have a hidden repeating group of Type Text. For Characteristics, the RG data source is Get characteristics from page URL (type text):split by _

I then use RepeatingGroup Tools by BDK: RepeatingGroup Tools ( bdk ) Plugin | Bubble

To use this plugin, I place an RG Extractor in the Repeating Group I described above, give it an extractor name (something unique I can remember so I can reference it in a bit): ‘URL Characteristics’. Cell_index: current cell's index. Column 1: Current Cell's Text.Now this element will live in this repeating group, and grab each text element that has been pulled to the RG from the URL.

Outside the RG, elsewhere on the page, but also hidden, you can now place the RG Data piece of the BDK Repeating Group Tools plugin element. On this one, remember to give the Extractor Name the same thing (‘URL Characteristics’) so it knows which RG Extractor it’s pulling data from. Here’s the magic: for Column 1 datatype, instead of ‘Text’, choose ‘Characteristics’. This is now effectively converting the list of text from a URL into a repeating group as type text, running through this plugin, and coming out the other side as a list of Options, matched by each option’s Display.

Now that we’ve converted a URL into a list of options, there’s one final step that I use to filter / constrain my results efficiently and without any advanced filters. Again, I recognize this may be arduous so I welcome any other thoughts on this or workarounds anyone else has!

On my main repeating group, the one actually displaying the filtered results (Recipes), I have my Data Source set just Search for Recipes), and my constraints work like this: Characteristics contains ‘RG Data’s Column 1 list: Item #1’, Characteristics contains ‘RG Data’s Column 1 list: Item #2’, Characteristics contains ‘RG Data’s Column 1 list: Item #3’, etc.’ Create as many as you anticipate (in my use-case, I only allow up to 6 characteristics to be chosen, so I don’t need more than 6. And there are 9 main allergens in US food regulations, so I use 9 on Allergens)

And that’s how I search for an Option Set quickly, without using ‘:filtered’.

3

Why not just make it all one option set? Have a Tag option set, and a Tag Type option set. The Tag Type can be an attribute of the Tag. Tag Type would be Colour/Feature/Location, and if you want to display only Colours, for example, show All Tags:filtered (Tag Type = Colour).

5

yes, that is an option as well. However, I don’t believe that would get round the fact you’d still have to use an advanced filter, which is the issue with speed.

Unless I misunderstood your point?

6

All option sets use client side filtering, because they’re always downloading to the client. But, one advanced filter will run better than three…

If your option sets are large, and you still want them to be faster, why not consider making them a data type (all in one data type) which means they’ll be searched on the server, and comes with benefits like being able to modify them from your site rather than the editor.

7

Thanks for taking the time to lay this out. Seems to be some good pieces of wisdom in here.

The last point you made seems to be an important one Create as many as you anticipate. In my case there are hundreds, so it may be unwieldy.

1 Like
8

Understood! If you do find a way to work with many like that, I’d be curious as well!

9

Then data type > option set, probably.

10

This suggestion (Data Type) seems to be superior than Option Sets but still not as quick as I’d like. Perhaps I need to farm it out to Algolia or something similar.

11

This topic was automatically closed after 70 days. New replies are no longer allowed.