I had a quick question. If I am doing a search for a RG that starts off showing all results. If I then want to add filtering to this, is it best practice to add constraints to the Search with “ignore constraints” checked or to build out some sort of daisy chain filtering with custom events?
I have seen it taught both ways on courses I have watched so I was unsure. If daisy chain is not the best option then when would you ever use daisy chain filtering over search constraints?
Thanks in advance for any insight!
@cmarchan and @J805 - I would love to hear your guys input as well!
Why filter in step 1, 2, 3 and 4, when you can do it all in step 1 (or just with a dynamic data source), making it run faster and more cheaply in terms of WU?
There might be limited cases where daisy chain filtering is necessary but I haven’t done any recently to give an example.
Daisy chain filtering may be useful when subsequent filtering depends on the result of previous filtering … when this latter cannot be implemented in one single query.
As far as I remember my light experiments with DCF in summer 2023 - there is no difference in terms of WU consumption between DCF and using constraints (of course if they are using same attributes).
Yeah. @georgecollier is what I was going to suggest as well. I was going to say the same thing @cmarchan mentioned too. Glad we’re all on the same page.
I don’t know why anyone would recommend a daisy chain for searching. It’s concerning that newbies, who have enough to digest trying to learn Bubble, are being taught a convoluted daisy chain method, when Bubble provides a very simple way straight out of the box (“search for and ignore empty constraints”).
In addition, I know the regular “search for” will always run server side, meaning the app can scale. A daisy chain risks pulling the search client side, meaning the app can’t scale and the app owner is in for an unpleasant surprise down the road.
I remain open to the possibility that I am wrong on this, and that someone can provide a good explanation on why daisy chain is better, but I can’t find any such explanation.
You are not wrong. Daisy Chain Filtering in my opinion is never needed and just bad practice. Reason newbies do it is because of a video from 2017 released by a high profile trainer.
I’ve yet to have anybody who uses the method explain why it is better than using search constraints with ignore empty constraints checked.
I’ve never been able to come up with a single use-case where daisy-chaining has any benefit over using a search with empty constraints (or a single client-side advanced filter, depending on the use case). And daisy chaining is always done client-side, in multiple searches, so it is inherently unscalable, and costs more in WU than loading all the data in a single search and then using a client-side filter (unless the data is already loaded to the page, in which case it makes no difference at all, and has no obvious advantage).
But yeah… if anyone can provide an example use-case where it’s either necessary, or better, then I’d be keen to know…
Daisy chain filtering is basically the same as using Do a search:filtered:filtered:filtered... expression.
So if we are using exactly the same list of constraints in Do a search (default/ordinary filtering) and daisy chain filtering - there should be no difference in the number of searches, the way (client-side or server side) filters are applied and WU consumption.
Filtering is triggered by a “Search” button click on both pages. Same number of searches (1 vs 1), same number of items returned (19 vs 19), same WU consumption for filtering (0,61 WU vs 0,61 WU):
Well of course… if your data is already loaded, then any type of client-side filtering won’t have any affect on WU cost (the searches have already been done and the data is already there).
But if you’re trying to minimize data retrieval and WU cost, then using server-side constraints is far better than daisy chaining (which can only work with data already on the page).
It seems I’m missing something…
Usually “client-side filtering” term implies the fact that Bubble returns all items row-by-row (relevant and not relevant) from the DB until there is enough relevant (corresponding filters) items to be displayed. The most well known example of client-side filtering is using Advanced: option.
So in my example above both filters seems to be applied server-side (Bubble fetches relevant items only).
What is the other option to make sure filtering is performed client-side?
So, I have Cats data type with different attributes like age (number), vaccinated (y/n), preferred food (list of items from another data type Food) and so on.
On both pages I use same 3 options to filter items:
“older than 1 y.o.?” - should return cats with age > 1
“vaccinated?” - should return only cats with vaccinated = yes
“Choose food…” - dropdown to choose food option
So you need to choose any/all of these 3 filters and click search button. Relevant results should be displayed. Here is the expression for non-daisy filtering:
My bad, placed conditions on WF level instead of step level. so it worked only when you choose all filters. Fixed, should work correctly now.
If I had time, here’s what I’d do. I’d set up a multi-constraint search and run it the following ways. I’d set each one up so that no data is loaded until the search button is hit. And I’d select all the constraints each time I searched:
Standard way - put constraints in “search for” box
A single filter containing all the constraints
Multiple filters, one for each constraint
Daisy chain workflow
I would then look at chrome dev tools to see what Bubble was loading to the page. That’s the only way to tell for sure what Bubble is doing.
I know #1 executes server side. Not sure about #2, since Josh said Bubble might execute a filter server side, or might not, depending on the filter. I suspect #3 and #4 are client side.
If anything is running client side, the app cannot handle large amounts of data, and therefore can’t scale.
This is all getting away from the other point, which is that daisy chain is a convoluted way of doing a search, and Bubble provides a much simpler way out of the box.
That’s exactly how I’ve organised my test example above. With a small difference - default (unfiltered) data loaded on page load. Now I’ve changed this behaviour and no data is fetched until search button is clicked. Still no difference in number of requests, items fetched and WU consumed.
Not wanna take the role of DCF advocate (I don’t use it in my apps) but I suppose there are some scenarios when it is more comfortable way of managing filter options within an app (if there is no difference in performance and WU consumption).
For example, if you are using default checkbox elements a lot. Using DCF all you need is just to have a separate filtering custom event for each checkbox. If you are using “on-the-fly” filtering (apply filter at once without need to click on filter or search button) - you’ll need to create additional WFs for each checkbox to trigger DCF. But after WU model has been launched I’m not sure that “on-the-fly” filtering is a good idea
Going with standard way filtering - you’ll have to manage a lot of conditional data sources.
Of course, there is an option with creating custom checkboxes (icons + text) and using custom states, but it requires additional job too (creating custom states + setting custom states in WFs). And if you have a lot of custom checkboxes - you’ll have a lot of custom states. And managing a huge list of custom states via small element inspector window is, to put it mildly, also not very convenient.
Another example - when you need to use advanced filtering to filter one data type using another data type. For example, filter blog posts based on multiple tags selected from a multidropdown. So with standard approach we need default data source + conditional data source for cases when at least 1 tag is selected in the multidropdown (cause if we will use advanced filtering in default data source - we will face client-side filtering even when multidropdown is empty). If we add/delete new constraints to/from default data source - we need not to forget to adopt conditional data source. Also “ignore empty constraints” is ignored by advanced filtering, so we need to add some excessive expression like ...or this multidropdown's value:count > 0.
And again - using DCF method will result in adding just one custom event to the WF.
P.S. also there is a twitter thread where AndrewV (developer from Bubble team) shares how and why he is using DCF in his project:
I was going to say the same thing 
Glad we’re all on the same page.
