How can I create a 'drill down' facility with a collection view?

Mobile
1

I've got a data source where there are multiple levels of grouped data, but the levels are determined by the data, I can't predict how many levels there would be. Each level of the hierarchy is essentially the same, imagine Site > Building > Floor > Room, where each level shows an overview of the levels beneath it, and the ability to pick a child level and drill in.

I've got a page with a collection view and can hook that up to show my first level, and I can link that to another page showing the detail, but this seems to be a 'fixed' view, I'd need several levels to cope with what can be a dynamic number of levels, and would be hard to maintain.

In the web app mode I've been able to use urlparams (hash) to refresh the query, so although I use 'openApp' I set the target level as a hash param, and the query refreshes to show that level without navigating away from the app.

I don't see how I can do the same thing in the mobile app paradigm, as the navigator won't let me target the page I'm already on. Whilst I think I could do a 'control query' trigger that would likely not given me the 'back button' that would allow the user to navigate back up the hierarchy.

Have anyone found a solution to this sort of drill down?

2

Typically, a drill down search is a collection of dropdown menus on the same page that load their content dynamically based on the selection in the previous menu - like when you would choose the year/make/model/trim of a car, for example.

retool_drilldown_example
retool_drilldown_example1965×887 151 KB

Is that the case here? Or is it more a screen-to-screen navigation at every step? From what you describe, it sounds more like a parent/child/detail view.

Some screenshots or mockups would help in better understanding what you're after.

In Mobile, temporary states are probably key to achieving most logic needed. You could have a temp state (called searchData, for example), that you could set/unset on every click with the necessary info: siteID, buildingID, floorID, etc.

retool_drilldown_tempstate

Then, in your detail view, you check the searchData state and load/show content as needed.

At a minimum, you could have a minimum of two screens with a bunch of conditional logic, or as many screens as the data model you have - in your case, five (search page, site screen, building screen, floor screen, room screen).

As you select a site on the initial search page, set searchData.siteID to the site id/name, navigate to site screen. The site screen loads available buildings based on siteID, then on selecting one, set searchData.buildingID to the building id/name, navigate to building screen. Repeat for the rest of the steps.

The back button can be done in a number of ways:

1 - As an actual back button, which takes you back to the previous screen. So, if you are on a building screen (which lists available floors), you'd go back to the site screen (which lists available buildings). The site screen would have a Visible event handler which would look at searchData.siteID and load the content - available buildings for that siteID.

2 - As a DIY icon/action link, which would run a script and refresh various screen elements on the same page/screen (or even navigate to other screens) based on the "current" model viewed. This would maybe apply more if you wanted to make everything work with as few screens as possible.

You could store the "current model" as a temp state variable alongside the other data: searchData.currentView = "building", and you'd update that as you drill down: currentView = "floor", = "room", etc.

{{ searchData.value?.currentView == "floor" ? containerFloor.setHidden(false) : ... }}

Just my two cents, I'd be curious if the Retool team has maybe other suggestions.

2 Likes
3

@27shutterclicks Thanks for the great detailed response. As you point out, it doesn't need full screen navigation (although that pattern is part of the tab group UI), and could as you suggest be done with multiple drop downs on the same page, but this doesn't leave so much room for the data related to each step in the hierarchy, which was why I was favouring the screen pattern.

However, the number of levels in the hierarchy (and the terminology) isn't fixed, the Site > Building > Floor > Room was a suggestion for context, and indeed, its a likely scenario for the way that users organised, but it could easily be Country > Region > City > Office or some such. It might not even be tied to geographic type hierarchy, it could easily be Company > Department > Desk or some such.

I think you've given some insight, in that I could do the navigation myself via temporary state and my own back button implementation. I'll give that some more thought and experimentation.

Many thanks

1 Like
4

Maybe the solution is a hybrid between what you did on the web app and the custom back button approach.

Triggering a query to refresh the current screen isn't a problem. You can hook it to the collection view's on press/click event handler to trigger a query by passing a variable/ID to the query based on the selectedIndex/selectedItem of the collection view.

I recently came up with a new way to pass variables to queries, especially if using temporary states: here's the link.

Triggering the query will automatically refresh the current's screen data, so you don't have to navigate and target the page you're on.

I don't know how standardized your data is, but I suppose there may be the issue of telling the collection view what data goes where (item.name in title, item.description in body, etc.).

With this dynamic approach, the main challenge would be the back button, but as long as you keep track of the data type you're showing at every step via temp states, it could be as simple as triggering the same query with the previous variable.

1 Like