SearchBox Constraint "OR"

Hi there,

First time I post here (but read a long list of topics !).

I have a SearchBox which searches for Telephone number. I need to “filter” them whether they have an Entity (a table in my DB) or not (Entity is empty). The Entity is selected in the “Entité” dropdown (which is filtered by the Group Dropdown).

Here is my form :

Today, I have :

It works well when lines are matching the selected Entity. But I also have lines that are not affected to Entity, and I want to display them.How can I build a constraint saying : Entity = DdEntity’s value OR Entity is empty ?

Thanks for your reply !

One last word : Thank you Bubble ! 3 weeks to build a complete app vs 6 months to build a low-quality MVP with a dev on .NET ! :slight_smile:

2 Likes

Hi Julien!

I don’t think you’ll be able to do this with the standard Bubble search element. The constraints are always AND, so we usually use multiple searches merged together to create an OR statement, or when results are few, use the advanced filter. However, the search element doesn’t expose either of those options.

You might take a look at this free plugin, which gives you this ability and much more, but is more complicated to setup. You basically tie a standard input element, to this plugin’s search element, and then display results in a repeating group.

Welcome to Bubble!

–Ken


Looking to accelerate your app development?

Development of Advanced Apps at https://uniqueideas.com or schedule a free intro session :gift:

Ken Truesdale
LinkedIn

For whatever reason, there is no logical OR condition in “Do a Search…” operations. (Search criteria are logically ANDed together.)

The Bubble method for ORs in searches is to MERGE the results of the two criteria.

For example:

Let us say we want the list of all Users with FirstName “Keith” OR FavoriteThing “Taco”.

This can’t be constructed in a single Bubble Search, but you can still do it as a “one liner”.

For clarity, the list of all Users with FirstName “Keith” is:

Search for Users (criteria FirstName = Keith)

The list of Users whose FavoriteThing is “Taco” is:

Search for Users (criteria FavoriteThing = Taco)

The list of Users that meet the first or second criterion is:

Search for Users (constraint FirstName = Keith):merged with Search for Users (constraint FavoriteThing = Taco)

Keep in mind that if there’s a User named Keith whose fave thing is tacos, they will appear only once in the resulting list (which is of course what you want in most cases).

4 Likes

I guess the question is: Should this give us the allergic reaction that folks often have to this?

We can test it. The test case is to compare the relative speed of the method above compared to:

  1. A server-side plug that does this on the page.

  2. An SSA plug that does this on the server.

I’m going to bet that the method above outpaces either 1 or 2, but perceptually 1 or 2 may seem faster.

The hitch is that to do either 1 or 2, we must fetch the list of ALL USERS into the browser (in case 1) or fetch the list of all Users to server memory (in case 2).

This will RAWK if there are only a small number of Users (as you’d have if you set up a janky use case on a free app) but as # of Users grows, 1 and 2 will fall over.

#bubbleisnotslow

Thanks, @keith, this is really insightful and helpful. So, having also read your follow-up post, does this mean that the “merge” technique described in your first post is executed as a single request/query?

@keith are you saying a merge or even a filter will work in the search element? I’m not seeing that as an option for the op???

Ken, I just did a quick test with a RG, and “merged with” is available upon clicking “More…” after constructing a “Do a search for”. :+1:

1 Like

Ya, I get that and use merge all the time, but the original poster is asking about the search element.

Oh yeah, I see what you mean about dynamic choices for the SearchBox. :neutral_face:

EDIT: I wonder if creating a custom “SearchBox” would be a viable option. Hmmm…

Hmm. I don’t use the search box element as I’ve never run across an application for it. It seems like it’s a shortcut for… well, I don’t know what.

(It lets you search for a Thing, based on some field of Thing. All well and good. But this isn’t that useful.)

@sudsy, yeah maybe. I feel like the Search Box element is there to make noobs feel like you can build Google or a foundational social network in Bubble, which of course you can’t actually do.

I’ve literally, actually never used it, even in a demonstration app. It feels like “barking up the wrong tree” to me. I get that autocomplete is neat, but in practice this just doesn’t work / is not helpful except in contexts like Algolia (which is an entirely 'nother thing).

I’ve used the SearchBox element for location-based searches - not to pull data from the DB (although I can see the appeal of being able to quickly create a “live search” input in certain contexts).

That said, I just whipped up a SearchBox-like UI using a RG and regular input linked to the “Live Text” plugin. This enables the use of “merge with”. The biggest issue would be dynamically positioning the RG for responsive behavior. Anyway, off to tinker some more to refine the search…

Ya, that’s basically what the search plugin I linked to does, with some fuzzy search added in. Allows multiple fields to be searched as well.

@mebeingken, do you have any experience with that plugin on data sets having tens of thousands of records (or more)? At first blush, it seems to “work its magic” client-side, which suggests that filtering large data sets could be an issue performance-wise.

Nope, Only small sets.

Well, it SORT OF does. It’s abandonware. (Also, it’s not magic.)

I think the thing that’s missing here is that none of these approaches actually use the capabilities of Bubble adequately. The Search Box thing is set up as a thing that just returns a value.

But there is, of course, a state BETWEEN when the user starts typing and then finds an item they want to hone in on. In that state, the Search Box thingy should have an exposed state that is currently hidden – the list of possible matches.

What it does right now, is shows the list of possible matches like a dropdown. This is nifty, but not helpful to the Bubble programmer/developer. The Bubble developer desires access to that list.

This can totally be done, of course, but it requires a bit of explanation. I feel that Bubble errs too much on the side of obfuscating “what’s going on” vs. explaining things clearly and letting folks deal with it. So, the Search Box just isn’t useful right now.

Anyway, should the OP want to do an OR operation, I’ve shown how to do that.

@sudsy you’re on the right track. What you need to do is (1) detect the state that the user has entered data entry mode (fire off a trigger to indicate that) and then (2) keep doing that every time the list of possible completions has changed… and (3) update some exposed state with those possible completions. Then the programmer user can just slam those potential answers into an RG for display.

Thank you all for your replies ! What a community ! :slight_smile:

I already use this plugin, but as it needs a RG, I didn’t want to use it there to keep my form “flow” !

Yes ! I knew that ! And I use it to make OR conditions possible ! But it’s not available in the SearchBox component (Why ?)

Nope ! That’s not ! :neutral_face:

By the way, I’m gonna use a Standard Input with a RG group and Fuzzy Autocomplete ! It works well on another search in my app !

Once again, thank you all for your replies and time !

Best,

Julien

2 Likes

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