Search: any field contains - highlight match?

I’m using a search with operator ‘any field contains’ to display matching results in an RG. I would like to highlight the field that contained the match for display purposes. Can anybody think of a smart way to do that?

The only way I can think of to do that off the top of my head would be to run a few searches in parallel that each search one field and then see which ones also find the same record. Definitely not the smart solution you’re looking for though.

Note - you’d also run into cases where multiple fields match so it could get a bit tricky.

Just guessing here, but offering input to also get feedback to see if what I’d try would work.

Wouldn’t the match any field parameter already return only rows matching the search term? And then put a conditional format on each text element to highlight it if its content contained the search term?

1 Like

Thank you @sridharan.s - that is where my thought process was going too but I knew it was overcomplicating things and would cause performance issues. I believe your solution will work @gnelson - it was so obvious that I didn’t see it - too far down the rabbit hole - must remember to come up for air occasionally.

The native Bubble search field will search any field on the table (as you say) but will only display single row of text for each result (so, for example, not way to show user photo next to their name) . This approach searches the database, though, so it can search a large list fast which is great.

If you use the Search & Autocorrect plugin, then it’ll enable you to do what you’re suggesting, but this plugin loads the results to the client first and then filters from there. So, if you’re searching a large list, it can take a long time to load the list. This plugin is great when you have a smaller list of entries that you’re searching.

1 Like

Thank you again @sridharan.s for the reasons you mentioned I’m not using S&A plugin on this one. I’m using an Input field not Search Box so I can use bubble’s Do a Search for : filtered where the filter looks for the input value by the length of that input. It’s not quite but almost like @NigelG’s Partial Search on - I only found that resource yesterday and it has lots of excellent examples on it. Should be promoted more often.

As a heads up, when you add “:filtered” to a search query that often filters client side (not on the server). So, this means it loads the “search for” to the client and then filters it. As such, it can results in the same challenges as the S&A plugin.

You may want to test this. I know Josh is constantly improving the way searches are handled (moving more and more of the logic to the server to increase performance). But, as far as I know, anything “:filtered” still loads the search items to the client before filtering them.

1 Like

Good to know @sridharan.s that’s certainly important. I have read the Performance Q&A twice but I had forgotten that. I’m planning to only show the first 3 to 5 matches and then have the user tap an icon to open the full list. My reasoning was that the user was more likely to keep typing in the search box until he found the result he was after.

However, if he taps the icon to expand then I could either (a) make him wait whilst it loads, or (b) I could be loading it behind the shorter version, not hidden but covered over and then revealed if needed.

Anything there that I should be aware of?

just spotted your wording above. Are there times :filtered is done server side and if so how can I learn which are and which are not?

I suspect anything before “:filtered” is loaded client side for all scenarios, but hard to know. 2 ways to figure out: 1) test it with your app to see the performance. 2) ask Josh in the performance thread.

1 Like

Thanks again. I was planning to upload a large number of test records later in the week and I’m actually building a couple of possible solutions for testing. Plus I believe this relates to the thread you posted How are people implementing site-wide Search? where I said I’d direct messaged Nigel. He came back to me and said he had seen both my message and your post and will respond in the forum so I’m waiting for that too.

In an on-page workflow, “:filtered” is executed client side. I believe “always.”

However, you’ll note that the :filtered operator is ALSO available in API workflows. Those operations would be done on the server of course.

(They also seem to be pretty fast. I do some things like this: I have an API workflow that pings an external API to get events from an iCalendar file. The complete list of events gets stored in the db. But I also do a filtering step to store only events that are in the future in another field. This step adds zero appreciable time to completion of the API workflow, at least in MY use case.)

1 Like

Hm… I can see it working well there @keith . I have used Grouped by in the same sort of way on an API Workflow, however, I think using an API Workflow will not work well for a search where a user expects to see shortlisting almost immediately. It seems whatever I do there is going to be a lag at least until bubble double down on getting better search functionality which I know they are working on.

So far I’ve tested S&A and :filtered by … now I’m wondering if :merged with might be worth a shot, it might just be faster than :any field since I don’t need to search all fields.

Sorry, I was not trying to answer your specific question, @patricia. I was clarifying for @sridharan.s when filters might be executed locally vs server-side. I don’t think my comments there are helpful to you in solving your specific problem.

They are useful actually @keith just not for the search but for other things I’m planning right now. Always good to learn.

@keith and @sridharan.s I’ve tried as many approaches to search as I can think of and I seem to be coming back to the Search & AutoCorrect plugin approach. It is powerful because it allows partial word matches, ignores case, and can be tokenized and other things so it’s difficult to match. So in an attempt to save some time, what I’ve done is rather than have it search 5 fields (I need 7 fields) I’ve run and API Workflow that concatenates those fields into a single field and that seems to make the matching faster. I can’t be sure without many more records but it does look that way. Any thoughts on any potential issues I’m not seeing?

EDIT: I just added AirDev’s Instant Text plugin and it removes the delay in bubble when entering text … not all the lag was down to S&A’s client-side matching.

I would think that for client side matching with S&A plugin, the performance would be pretty much the same for 1 field vs. all fields. I think this because with client-side data, it’s slow to load but once loaded all of the calculations are lightning quick. But, I could be missing something so let me know if you find this to be wrong. I definitely don’t know the inner workings of the S&A plugin either.

I have yet to look at the S&A plugin, but it certainly seems very useful.

What I have done is split text into words, and then build a Search Index from that. I think that is fairly similar to the method above with concatenation.

1 Like

I can add to that to improve performance. All the lag is not due to the S&A plugin. I’ve started to use Instant Text plugin and I point S&A to it’s value instead of the Input’s value. So the search gets started sooner and it feels better.