Best practices for reusable queries

I’m wondering what the best practice is for centralizing the query logic that’s relevant to multiple elements on a page. For instance say I have a dropdown that allows the user to select any Home (Thing). Then I have a bunch of repeating groups (or other elements) that all need to access that Home’s Occupants.

That’s simple - I just have every element pull the Home’s Occupants and use those.

But now, on top of that, maybe I add a few other filter elements (age, favorite color, whatever). I want every element to only deal with the filtered set of Occupants. Is there a good way to share the filtering logic between all of the components (rather than repeating the filter logic everywhere)?

Right now my workaround is to have a single Repeating Group where I access the appropriate set of Occupants, and then every other element that needs the list of Occupants, uses that. Still seems hacky though, and if I want to delete that Repeating Group I can’t.

Any suggestions here for a more elegant approach?

You should use custom states for this, and everything would reference the custom state(s).

I’d like the query to auto-update based on the inputs, without having to write workflow. Can I do that with state? It looks like the only way to update state is with a workflow.

There’s nothing wrong with your setup of using a repeating group to store the list of things, and then use that as a reference point for the rest of the elements. It’s a completely reasonable approach.
You could achieve something simillar with a few ‘input changed’ workflows + set states. There’s even ways to do it with a single workflow + set state, but they’ll feel even more hacky than your current set up.

The only consideration is that the ‘auto-update’ functionality consumes a lot more WU than using States + a button to Apply Filters. You’ll end up doing a search every time any filter is changed, instead of just once after the filters are applied. If you are dealing with filters that are lists, then this is even more true, as every time the users updates the list, a search is made. Using states + apply button is the bubble meta :grin:
However, if for UI/UX reasons, you really want the autoupdate functionality, then using a RG to store the list is completely fine, i’d even say it could be considered good practice.

1 Like

Gotcha. I guess if I don’t need that particular RG to be visible I could hide it.

Instead of making it not visible, just delete all the elements inside of it, remove all visual styling, and make it 0px wide&high.
The RG will essentially turn into a list of things that you can reference from anywhere instead of an actual visual element for your frontend.

Setting elements to not visible will slightly delay how quickly their data is ready. There is a hierarchy/order that define which elements get loaded first, and not-visible elements don’t score very high in this hierarchy. Their loading is delayed because they are generally not needed straight away; loading them later can make the page load quicker. If other elements reference the datasource of the hidden element, the browser then realises that it actually needs to load the datasource, and loads it. But this is introducing unnecessary delay.

1 Like