I have a classic setup of a table of Notes and another table of Categories. Notes can optionally belong to one or more Categories.
I’m currently using the In-app Filter feature to add filtering to my list view of Notes, and it works fine. But for the UX of this app, I’d love to have category filtering be prominent and available with a single tap.
I set this up with a Choice Component (thanks to this video), but I can’t figure out how to make the filtering work as I’d expect. It works fine if I only allow one selection, but if I allow multiples, they are exclusionary rather than inclusionary. I.e. if I choose “Home” and “Media”, I only see notes that belong to both of this categories, where I’d like to see the notes that belong to either.
What would be ideal would be a “Chips” display option for In-app Filtering (which works the way expect), but I have a feeling there’s a way to manually build that functionality that I just haven’t figured out yet.
Any direction would be appreciated!
1 Like
I know the choice component gives you a comma delimited list, but is that the same in notes when they have multiple categories?
If so, I personally prefer using a Split Text column in both tables to create an array. Then create a relation linking both split text columns together. Then you can source your collection from the relation.
2 Likes
I’m thoroughly confused by relation columns but splitting the comma-separated Categories did help me get where I wanted to be, I think.
1 Like
Is it working correctly that if you select both Home and Office, you only want to see items that contain both? I assumed you wanted more of an OR condition when any item can contain either Home or Office or Both.
A relation isn’t overly complicated once you understand it. Think of it like a Parent and Child relationship. Let’s assume we have a Parents table that lists all of the parents…and we have a Children table that lists all of the children. You could have an array column in that Parents table that lists all of the children names or IDs that belong to each parent. Alternatively you could instead have an array in the Children table that lists all of the Parent names or IDs that belong to each child.
If you create a relation in the Parents table, you are taking a value in that row and looking for a matching value in any row of a different table. With the Parent/Child example, you could take the child array in the parent table and try to find matches to the child in the children table, or if you set it up the opposite way, you could take the parent and look for matches in the parent array in the child table.
Basically, relations just look for matching values in both tables. The result in the relation column is a list of all rows where a match was found when comparing those two columns in each table. It’s important to realize that a relation returns rows and not a specific column value from each of those matching rows. The values you see in a relation column are irrelevant. If you see something, that means it found matching rows in the other table. If it’s empty, then it did not find any matches.
Relations are like mini subsets of data from a related table. Treat them as if they are temporary tables with a subset of rows that contain all columns from that related table.
1 Like
That’s very helpful, thank you!
And you’re right, the “OR” matching you describe is what the In-app Filter feature does, and that would be preferable. I just can’t figure out how to replicate it.
I did have a Relation column set up in Notes, relating to Categories, from the start of this project. I’m just not sure how I can tweak it or add a new one to enable the functionality I’m after.
I really just wish the In-app Filter feature had a Chips display style.
The relation should be located in whichever table is the source of that screen. In other words, the table where the choice component is writing the selections. That’s because you want to take those choices, use a split text column to convert it to an array, and use the relation to find the matching notes that have the same categories as the categories in the split text array. The screen table is your parent table. The notes table would be your child table. The collection should be sourced from the relation instead of a table.
If you can show screenshots showing how you have it set up, I can point out where it’s going wrong.
