Refactor Compendium Browser to use a Predicate for filtering entries

[In3luki]

I finally had some more time to work on this. Pulled out from #20282

This PR only includes the switch to predication and no other additions or UI changes. If this is approved I can start to pull out the other changes from the old PR.

Current filter:

Predicate filter:

[CarlosFdez]

Fix it one more time and poke me on discord.

Is this the smallest you can get it? Are there no refactors here you can section off?

[In3luki]

I may be able to do this without refactoring the options from objects to arrays. That should make the diff a bit smaller. I'll take another look over the weekend.

[CarlosFdez]

Most everything here is fine so far but this gives me pause. What is the purpose of using predicates if you end up having to add the roll options anyways?

[In3luki]

Using a predicate should make it easier to implement new filters without the need for custom logic. It already covers pretty much anything that a filter could need and especially exclusion is much easier.
And for adding roll options, I'm pretty sure a predicate without options wouldn't do anything? I might be misunderstanding what you mean.

[CarlosFdez]

It looks like you're creating options, rather than using the item's existing options. So there's potential for desync or forgetting that an option has to be added for the predication to even work.

[CarlosFdez]

Maybe make the options an array? You might be able to cut down on a lot of lines of setup code if you use options.push(...traditions.map(stuff)).

[In3luki]

Updated with the suggestion. Options are now converted to a Set as the last step. They could technically stay arrays in the filter data but the Predicate would convert them anyways on each filter operation.

The basic shape of the roll (or filter) options can't really be changed as the Predicate expects a colon as a separator for some things. The only thing I could think of would be to add a filter: prefix to all options to make it clear they are not normal roll options.

[CarlosFdez]

Can you keep the simple one liner additions together? In other words move this up to the other options.push? It saves only a bit of whitespace if you do it throughout, but right now the main wart of the new style is the manual addition of options, so if the code can be kept tight, I think it'll be fine.

You could do this as well I suppose to save on whitespace

const options: string[] = [
    `action-type:${system.actionType.value}`,
    ...system.traits.value.map((t: string) => `trait:${t.replace(/^hb_/, "")}`),
    `type:${actionData.type}`,
    `category:${system.category}`
];

Try to keep option initialization LOC tight for each object type if possible.

[In3luki]

Should be better now.

[CarlosFdez]

The basic shape of the roll (or filter) options can't really be changed as the Predicate expects a colon as a separator for some things. The only thing I could think of would be to add a filter: prefix to all options to make it clear they are not normal roll options.

Don't worry about it. While it being confused for genuine roll options is a problem, I don't think making them different is going to help anyways, nor is it enough reason on its own to deviate for the sake of deviating.

[CarlosFdez]

Code looks fine to me, but I plan to check for bugs personally.