Daisy Chain Filtering and Search Constraints Best Practices

[boston85719]

Yes, Bubble has added the operator of comparison ‘is in’ (was missing for years and all we had was ‘is not in’)…so now that we have ‘is in’ and ‘is not in’ it is very easy to just use those as equivalent to ‘is not’ and ‘is any of’ in your example video.

In your video you are storing a list of Users, List of Departments and List of Status, and each of the comparisons you provide for ‘is not’ is equivalent to ‘is not in’ and ‘is any of’ is equivalent to ‘is in’. So your data type that has a field for a single user as the assignee, or single department or single status is the constraint like ‘assignee is not in list of assignees’ or ‘department is in list of departments’.

[rico.trevisan]

Hey! That’s a good tip! I didn’t even notice the is in and isn't in addition. I can now have those little filters chips add the selected items to either an include and exclude list.

danke!

[boston85719]

@rico.trevisan

I didn’t even notice the is in and isn't in addition

The fact that ‘is in’ was not added originally made for crazy workarounds necessary to get some simple functionality. I am thrilled that it is there now.

[rico.trevisan]

With all that said, the mental model of daisy chain composable expressions speaks to me a ton more. It’s a lot more like Elixir’s Ecto (and like Rail’s ActiveRecord?).

[mkenton1]

Just throwing my hat in the ring -
I found daisy chain filtering very useful for some more complex filter options, where I cannot check “ignore empty constraints”. For example I have a board of “items” which have a rich set of fields (primitives, records/“things”, and lists of things)

My primary filtered datasource on a “board” is a search for all items that belong to that board (people shouldn’t see things or be pulling item data from other boards… only items built in that board by themselves or collaborators). So this search cannot be thrown in with the filters on a datasource with an “ignore empty constraints” because it’s forseeable that someone could delete a board and then the orphaned items would suddenly appear. There are probably ways to work around this, but between my team’s imports, my DB management tasks, timed-out/errored-out workflows, and who knows what else, it’s not a setting I’m comfortable with.

I initially solved this with a

1. Hidden RG Item with source search for items, where item’s board = this board
2. Hidden RG Item-Filtered, with the user-selected filters that I can throw all together with “ignore empty constraints”
3. The actual RG Item that renders the filtered data based on the selections.

However, I later wanted to give abilities to toggle filters that Bubble makes you work hard to get. For instance, if the user wants to filter by Item’s “Category”, they could do that - but what if they want to filter by “Category has not been assigned”? In the standard process, selecting (nothing) from the Category dropdown will just return all items. To solve this, I don’t find it advisable to default records to a dummy “not assigned” Category, but unless I’ve overlooked simple solutions, I don’t see really any solution except adding more and more convoluted filters to my NOT empty-contraint-ignoring Hidden RGs.

With Daisy Chain Filtering, I have a modular process to throw in these kinds of enhancements - each filter, as weird as it can get - is just another step in the daisy chain.

I also am happy with my current paradigm of using URL params with Daisy Chain Filtering. When a user applies a filter, my workflow simply sets the URL param via “go to page → current page”, and my Daisy Chain runs on Page Load. This is actually quite a lot cleaner than requiring me to build, on every filter dropdown change workflow, a custom state AND a trigger the “00-” step that kicks off the chain. I just set the param, and the page load flow takes care of it!

I’m curious if anyone thinks my method is bonkers or deeply flawed, but I’m much happier with this setup than the combined data source constraints. Works just as well, easier to maintain, and it unlocked quick enhancements that utilize URL history so people can go between pages and get back to their previously filtered view!

[georgecollier]

@mkenton1

For instance, if the user wants to filter by Item’s “Category”, they could do that - but what if they want to filter by “Category has not been assigned”? In the standard process, selecting (nothing) from the Category dropdown will just return all items. To solve this, I don’t find it advisable to default records to a dummy “not assigned” Category, but unless I’ve overlooked simple solutions, I don’t see really any solution except adding more and more convoluted filters to my NOT empty-contraint-ignoring Hidden RGs.

Yeah, when it gets to this level daisy chain can be not so good.

One thing you can do, if the search system is important enough, is use the data API and dynamically specify constraints (this is also how you can get AI to query data for clients). That will return you the list of unique IDs, and you can display them with Do a search for Items where unique ID is in returned list.

[mkenton1]

@georgecollier

Yeah, when it gets to this level daisy chain can be not so good.

One thing you can do, if the search system is important enough, is use the data API and dynamically specify constraints (this is also how you can get AI to query data for clients). That will return you the list of unique IDs, and you can display them with Do a search for Items where unique ID is in returned list.

For clarity, I meant that dummy “not assigned” records seemed to be the only route if just running one search on an RG - since I can’t filter by blank records. Because to allow the user to pick and choose the filters they want to apply, the options are either choosing “ignore empty constraints”, or not selecting it and needing a dummy record as the default in every single filter. Or… perhaps making an extremely complex set of conditionals for every combination, with repeated search logic that would be horribly unmaintainable.

But this is what Daisy Chain filtering made easy - tagging on another filter for “no record assisgned” is just as easy as any other step of the Daisy Chain filter. E.g. for any out-of-the-box dropdown/input filter, I can add an enhancement to the UI to allow filtering by this field = unassigned/blank, and throw it in the Daisy Chain with that condition. That’s just 1 new workflow step to the Daisy Chain - the same process as adding any of my other standard filters on the data type, unlocking much-asked-for enhancements that I couldn’t make on a single-data-source filter search.

But thank you for the recommendation for the data API - while I spent the time making the Daisy Chain and got good results, I’m at the point where I’ve solved other annoying workarounds to get data to display, import, and export, where I think having utlized the data API would have been a single, better solution to achieve the results I needed. And from what I’ve seen from other posts, it likely has even further benefits like faster performance and drastic WU decrease - especially as my DB continues to scale.

[mkenton1]

Coming Back to this…

I still like the custom event approach with the “display data in repeating group” and :filtered functions. Makes my complex filter conditionals way easier than setting all their permutations in the conditionals tab > data source, where for some filters I need “ignore empty constraints” and for other ones I specifically do not.

However… I’m second guessing the reason to actually “daisy chain” these custom events.

Why run through a bunch of “trigger custom event” workflows that have individual workflow actions that are sometimes bypassed by the “only when x is not empty” conditional? Why not just make your custom event steps and throw 'em in order on the main trigger? In fact, then the order doesn’t really matter, so we don’t have to keep track of it with the labeling.

Custom events run sequentially, so I think it makes more sense to have a single linear custom workflow. You do still need custom events for your filter/display actions, but their conditionals can lie on their entire custom workflow, not inside them on the individual actions.

It’s not all that functionally different, but no need to trigger Filter 2 inside Filter 1, and Filter 3 inside Filter 2, etc. Just have your CEs in a row!

Is there some concern that without daisy chaining, the filtering actions might not complete on the display of the data, before the next one is triggered? I see no difference in the approaches, but I could be wrong.

I’m not privy to Bubble’s nuanced WU practices these days, but seems like a better practice to set “only when” conditions as high as possible.

Note: I have the “only when” set on the custom event WFs themselves, as illustrated for the example “Trigger 01” wf action above.’

I have no idea if there’s any performance/WU differences in setting the conditional on the Custom WF or the trigger of the custom WF. I can hypothesize reasons it would go either way so hopefully they’re run identically for both performance and WU.