Great work around for multiple filters
This is great! Wondering about how to adapt for filtering if more than one choice per category can be selected. Ie, I have an Industry list, and someone selects both Design and Education filters. Ideally the list would then be filtered to include anyone with either of those in their Industry list.
Ya, I need to update this post to account for multiple choice…@gvalero has a decent alternative that can be found here:
Thanks, I’ll check it out!
You can follow the steps below:
- Split the industry choice using comma as the delimiter.
- In the Directory table, split the list of industries of each person using the same approach.
- Create a relation using the split array in the Directory table to the split array in the table where you store the industry choice.
- Filter the inline list to only show items where the relation is not empty.
Ok, cool - I tried this initially and it didn’t work but just switched the order in the relationship and it worked. Not sure why? When I create the relationship where value in item’s industry list array matches value in filter array, the rel only populates the matching rows. If I flip it and create the rel with the value of the filter array matching the value of the item’s array, all rows show a relationship. Excited that it is working, but also curious about why the rel works one way but not the other. What am I missing about how rels work?
Hi @Robert_Petitto thank you so much for this tutorial. I tried on my side and it works but somehow only once.
The first time, the selection appears in first row of the Selection column and after that, it appears on the 4th row, any idea why ?
This means your screen is being filtered or sorted. Instead of using a single value column, try using a join list column to bring in the selected filter.
Check out the original post for the updated video.
- Using Users Table as the source for the details screen
- Show/Hide Filters toggle
- Multiple choice selection filtering
- Displaying an alert if filtering yields no results
am I the only one to start deactivating any such filters with the new update limit/pricing model?
multiple choice filters could be very costly on updates in an app, true?
I’m afraid that’s not correct. If your filtering technique involves making edits to User Specific Columns, then those edits are counted as changes.
Some of us have quite strong views about this, which have been expressed elsewhere. So I won’t repeat them here.
Although I don’t know what Glide’s plans are here, my gut feeling is that as we see further changes and improvements rolled out, this will in time become a non-issue. One thing to keep in mind is that Glide are not in the business of ripping their users off. If it turns out that this becomes a huge issue, I’m sure they will make adjustments.
But at least for now, @rayo is correct.
thats if you use the Glide’s built in filter.
But if you build custom filters based on choice components. I assume every time you change your choice you will be editing the data field that holds the value of that choice and hence it will count as 1 update. (I think, but i hope not …)
i completely agree with what you said. I’m sure Glide will try to provide the best service for its customers… and i really hope they make adjustments. The Updates is really a big scare for many i assume… You sleep with a $99/mon plan knowing that it could become become $249 the next day but then you wake up to find out that most likely you have to go with a $1000/mo plan.
I’m not saying Glide could not be worth that much for our business and many others. Its just the speed you need to take actions and that fact that you go with the new plan ONLY to sort out the updates issue, whilst many other questions remain unanswered …
scary times and worst of all, co workers or managers will start to ask you to look at other solutions which deep inside you don’t want to replace Glide for.
Hm. Ya, one of my clients went WAY over the update limit because the app has several screens with this type of filter. All write to user specific columns, but USCs still count as edits.
@DJP … we once discussed the possibility to ignore edits that write to USCs. Is this still on the table?
its is going to be very challenging to avoid going way over the limit. No more customized edit screens, no more multiple choice filtering, the floating buttons which switch list layouts or update tab design…
How many more updates are we talking about here?
Thousands. I can’t speak on behalf of every developer, but a good number of us use user specific columnS simply for navigation and UI (eg. Write “true” to a USC which shows or hides a component).
With this use case, our intention is not to “update” data records…so using a USC in a way that counts it as an “update” is going to severely hamstring creativity, UX, etc.
I’ll shoot you a DM to discuss further
I’d still like to throw this out there as a viable option if possible.