add filterFunc to model

[trevorstarick]

I think the FilterFunc stuff is pretty solid, but I think I need to spend some more time working on the way that the column sizes are calculated. There's a bunch of unnecessary copying of the m.columns slice.

[trevorstarick]

I'm using both features in tandem locally, but if it makes more sense to have them as two PR then I'll split them

[Evertras]

Would we want the filter function on the column or the table?

I'm wondering if the table itself might be better, so that there's a single filter func attached to the table. Then, when filtering, instead of checking the filterable columns, it instead checks the filter func for each row. This would allow someone to use data in the row that isn't in any column, or combine data across columns, etc.

[trevorstarick]

Would adding both make sense? In my use case I'm filtering on all the data in the table, but I could imagine where a per-column filter makes more sense.

[Evertras]

I suppose both would work. Technically you could do everything if you had the table-wide filter, but you would have to go through the extra step of checking for the column yourself. So having a shortcut on the columns could be nicer in some situations.

My only concern would be clarity of use. If I define a column filter, and a table filter, what happens? How can that be made clear? 🤔

[trevorstarick]

My only concern would be clarity of use. If I define a column filter, and a table filter, what happens? How can that be made clear? 🤔

That's a good point. In that case, I think I should refactor my changes to focus on just the table-level filtering. If I hit a case where that isn't good enough in the tools I'm working on, I'll see if I can come up with a solid solution to the table vs column filter.

One quick way I think would solve the issue is if all the filters get popped into an array, and the results are OR'd together, but then someone will want to do just ANDs which means having to also have a toggle for the "joining" of the filters. In my experience dealing with a collection of filters is a pain 🫤

[Evertras]

Yeah, I think the table level filtering is a good catch-all for all scenarios someone might have when they really want to go for custom filtering. We can revisit later to add more convenience wrappers around it if it makes sense.

In my experience dealing with a collection of filters is a pain

Also my experience!

[trevorstarick]

I'm off work next week and am aiming to wrap up the changes when I've got some time to "relax". All I believe I need to do is move the FilterFunc into a Table method instead of on the Column, and then I'll update the PR.

[trevorstarick]

Ok finally found some time to change the filterFunc. Should have more time this week to make any adjustments that you think might be needed @Evertras

[Evertras]

I may further fiddle a little with wording later but that's separate from the functionality, which seems reasonable. Now it just needs some tests.

[trevorstarick]

I do want to provide some examples use cases of FilterFunc, but wasn't 100% sure how to implement testing since the FilterFunc either does nothing, or it does something that's set outside of the scope of the repo. Any ideas?

[Evertras]

It's more testing that the filter func is called and applied. As a simple test, you could have a table with rows that contain '1', '2', and '3', and then a filter func that checks for 'a', 'b', and 'c' and should match 1/2/3. It can be totally arbitrary, we just need to make sure that it's applied.