Forum Academy Marketplace Showcase Pricing Features

[New Plugin] Quick Find Search & Facet Filtering

Hey all!

I just released this plugin to optimize client-side Data, Nested-Data and Option set searching. You can now build your own fast, real-time search engine and enable facet filtering. (See live example Popup we search a 58k length list almost instantly).

Enable Algolia search-like functionalities and capabilities in minutes!! This is a great alternative to the Algolia search engine without having to export and push your Data to Algolia’s servers.

:running_woman: Demo page
:running_woman: Plugin page

:zap:Add fast Sublime search to your application.

:mag_right:This Plugin enables the searching of types date, geographic address, number, text and yes/no fields.

:heart:Nested searches are fast and easy to implement.

:ballot_box_with_check:Searching in Data with Option sets is now a breeze.

:rocket:Real-time searching without exporting your Data to a third-party application.

:pen:Highlight the parts of the matched fields.

:fire:Want to add fast filtering options without defining multiple Conditional states? This Plugin is perfect for you.

:ok_hand:Works great on Page, in Popups, Focus Groups, and Floating Groups.

Feel free to reach out to me for questions, report bugs, or request features!


Wow seems great! Do the searches respect the privacy settings? (I have a multi-tenant app, and fast search is something I’m looking for since day 1.)

1 Like

Hello @zavitac,

Yes!! :tada: all the privacy rules that you set up in the Privacy tab remain applied. The limitation I found with Algolia is that it only supports public data fields (i.e., fields without privacy rules).

Also, this Plugin is optimized for loading client-side and it’s pretty powerful for searching data types with lots of entries.

Another Bubbler was looking for ways to search data types with lots of entries here is an example of the Plugin with a DataBase of 10k and 58k entries.

1 Like

Wow! This looks incredibly powerful! I don’t have a terrific use case for it at the moment, but I’ll be adding this to the list of ideal tools for future use!

1 Like

Update 1.0.1

Patch bug fix for undefined fields.

Refresh your editor and Upgrade the Plugin to get updated code


This look great indeed~!

however does it work on languages like Chinese, Japanese and Korean?

Looks awesome. If it were used as an app wide search on a reusable header in a multipage app, would each page the user navigates to require the initial load of the data, implying that every page redirect made will result in that long first load of the data?

Hello @hwgz01,

Yes, this Plugin can search foreign languages!!:tada:

Take a look at this example, it searches in traditional and pinyin Mandarin :female_detective:

Don’t hesitate if you have other questions.

This Plugin is not a Local or Session Storage Plugin it is a Search engine. It ​uses data provided on page load (i.e., global variables), therefore on page reload data will be reloaded. However, if the Plugin is used in a Reusable element (e.g., reusable header) for a single page application, the data will only be loaded once and on subsequent data source changes.

Unfortunately, it is not possible to store objects in Local or Session Storage so it’s hard to reference Bubble objects. They also shouldn’t be relied on for sensitive or security-related data.

Let me know if you have any other questions :slight_smile:

1 Like

Nice !
Thanks alot for the quick reply @fabrice.latour04

1 Like

Update 1.1.0

:tada: Improved searching when Data source is from an API call! Test it in action here.

Refresh your editor and Upgrade the Plugin to get updated code


Hey @fabrice.latour04,

I’ve been using your plugin for a month or so but haven’t time to go into its full capabilities.

I’m getting this error:

“The plugin Quick Find Search & Facet Filtering / element Quick Find threw the following error: TypeError: Cannot read properties of undefined (reading ‘listProperties’)
at u (PLUGIN_1635529305406x115283834020036600/Quick-Find-Search—Facet-Filtering-update–Quick-Find-.js:6:3078)
at eval (PLUGIN_1635529305406x115283834020036600/Quick-Find-Search—Facet-Filtering-update–Quick-Find-.js:6:6111) (please report this to the plugin author)”

Any clue on what’s the issue?

Also, I found out that the highlight isn’t working with this color #FFFF00 :man_shrugging:

Hello @zavitac,

Sorry to see you are having this issue, but I am looking into it at the moment. Is this a recent issue, since Update 1.1.0, or are you on another Version? Also to help me debug this problem would it be possible for you to send me by DM a link to a page with the Search element and the same parameters?

Edit: Thank you for pointing out the color issue, it is fixed and will be released on the newest Update.

Thank you

Hi, interesting plugin. I have a question: my understanding is that any search functionality plugins can only filter data client side if the data is stored in Bubble. If this is correct, does your plugin offer any efficiency/scalability gains vs. Bubble’s advanced filters (which are also client side), and if so, how?

Hey @fabrice.latour04,

I’m not sure if it is related to the latest update. I set it up once and then didn’t look back at it again until yesterday.

Sure, I’ll Dm you a link to a page with an identical set up by the end of the day. :slight_smile:

Hello @ed727,

Excellent question! I will try to answer your question to the best of my knowledge on how the Bubble :filtered operation works and only focus on the Text type operators. I will also explain how this Plugin addresses serval limitations from the :filtered operation. Here is a demo page demonstrating the Limitations and Speed differences

Indeed, to search a string in Bubble you can always use the A- … contains or the B- … contains keyword(s).

A- … contains:

  • Useful for returning exact matches for partial words (e.g., 'A', 'pl', 'Appl', etc will return 'Apple')

:x:Limitation of A- … contains (Quick Find Plugin doesn’t have this limitation):

  1. Case sensitive ('Apple' won’t return 'apple');

B- … contains keyword(s):

  • Useful for returning non case sensitive words and/or partial phrases;

:x:Limitations of B- … contains keyword(s) (Quick Find Plugin doesn’t have these limitations):

  1. Can’t be used on Data source of type Text (Text type Data sources can’t have … contains keyword(s) operators, but only Constraint: … contains);

  2. Can’t be used in Advanced: filter (Advanced: filters can’t have … contains keyword(s) operators, but only Constraint: … contains);

  3. Can’t use as a disjunction (i.e., "OR") on Data sources with multiple fields (Because this operator isn’t available in an Advanced filter you can’t use "OR" to indicate field_1 "OR" field_2 contains the value of an input);
    Limitation Limitation2

  4. Can’t use with partial words ('pple' won’t return 'apple');

:x:Joint limitations of A & B (Quick Find Plugin doesn’t have these limitations):

  1. No misspelling accepted ('aple' won’t return 'apple');

  2. No scoring to prioritize the order of the matched search list (Searched results will appear from the Data source order, not from the relevance of the search, so searching 'ship' could return ['Tommy hates spaceships', 'Lucy should worship you', 'Ships are great'] instead of ['Ships are great', 'Lucy should worship you', 'Tommy hates spaceships']);

  3. No two way searching ('mertens finn' won’t return 'Finn Mertens') (Note: here there is a little fluke as the … contains keywords(s) operator will return 'Finn Mertens' with 'mertens finn', but not with 'mertens ', 'mertens f', 'mertens fin', etc. So as the user is typing, the result will disappear as soon as a space is added 'mertens ' and won’t be returned until 'mertens' or 'mertens finn' is type;

  4. No highlighting of matched value(s);

In terms of performance/speed:
Here is an example of searching 'ship' on a list of 48k phrases with the Quick Find Plugin compared to a :filtered … contains. As you can see there is a noticeable latency before the :filtered search results are found (Approx. 5 secs).

From my understanding of the Bubble code, this is what makes the Quick Find Plugin more efficient in searching client-side:

  1. Searched objects are very light;
  2. When Bubble executes the :filtered function it reconstructs “their search” function with the defined operators even if they don’t change which must have an impact on the time to execute the code operations, whereas the Quick Find Plugin preps the Data and the search parameters.
  3. When using advanced filters you might need multiple conditionals to achieve a disjunction search on multiple fields, whereas the Quick Find Plugin searches all the fields as a custom array. The way I understand how the :filtered objects are constructed is that each "OR" is a nested operator object, so when searching on lists with a lot of conditionals you will have something like this {operator_object1{operator_object2{operator_object N}}}. Since looping through arrays is faster, in most instances, than looping through object keys, if you plan on having multiple fields and large lists it will definitely add up and impact performance.

The major gains of using this Plugin are:

  1. To show search results with little to no Search latency;
  2. To search multiple fields without using multiple conditionals and/or additional text operators (e.g., :lowercase, :extract with Regex, :find/replace, etc.);
  3. To get results when the correct spelling is not known or mistyped by the user (e.g., ‘aple’ will return ‘Apple’ and ‘fin merten’ will return ‘Finn Mertens’;
  4. To highlight the matched parts of a search;

Hope this answered your question :sweat_smile: and feel free to reach out if you have other questions,


1 Like

Update 1.1.2

Patch fix for better handling Highlight color selection and improve the performance when the Data source has values as undefined.

Refresh your editor and Upgrade the Plugin to get updated code

1 Like

Hello @agoo7714,

I’m responding here for others using this Plugin to see.

Thank you for taking the time to review the Plugin and giving your insights. The shown scenario is expected behavior as hbar in Hedera (hbar) is further in the searched field than the other results HbarPad and (hbarp), so in this scenario Hedera (hbar) would probably be the 3rd, 4th or a later result returned.

However, I understand this isn’t the desired behavior for these scenarios and I will prioritize the exact matching feature integration which was in my scope. I have a few questions though:

  1. Does the search of the symbols have to be case-sensitive? (e.g., DOT wouldn’t return Polkadot only fields with DOT);
  2. For exact matching do you want to Allow typo? (e.g., BTJ wouldn’t return BTC only fields with BTJ);

Cheers and happy holidays,

Thanks for the response @fabrice.latour04 ,

The symbol search does not have to be case sensitive, e.g. DOT and dot would both return Polkadot. And yes I have the allow typo feature selected on the current app. I guess essentially I am looking to simultaneously search both the symbol and the coin name and pull the closest matches.

Happy New Year :partying_face:

1 Like

Hey @fabrice.latour04 ,

Looks good man! But what´s the difference between this plugin and the Fuzzy search and autocomplete?

Thanks a lot.