[Feature]: Enhance the transaction type filtering feature

[csillag]

Is there an existing issue for this?

• I have searched the existing issues

SUMMARY

We want to add 3 new sub-features to transaction filtering

DESCRIPTION

Filtering for transaction type has been introduced in #1679. (Issue: #1636)

There are three more things we would like to add to this feature:

• On consensus, when the list of possible types is very long, it would be nice if we could search the list by typing.
• We would like to be able to select (and filter for) multiple types at once. (Depends on Nexus support, Support filtering transaction by multiple method types nexus#877 )
• In the filter list, we would like to be able to display the number of matches for each type. (Depends on Nexus support)

Off of these additions has been discussed with @donouwens (for design), and where appropriate, also @ptrus (for Nexus support).

[donouwens]

@csillag Please find the designs for the three mentioned additional features below. DM me for Figma link, please.

Filter default

Filter active

Filter search

[ptrus]

We would like to be able to select (and filter for) multiple types at once. (Depends on Nexus support, oasisprotocol/nexus#877 )

While support for filtering by multiple method types has been added to Nexus (oasisprotocol/nexus#877), we’ve found that enabling this in practice causes significant performance issues due to several reasons:

We always order results by round and paginate via LIMIT + OFFSET. Efficient support for this with multiple method filters would require indexes for every possible combination of method values, which is infeasible given the dataset size (500M+ transactions). Even now, we're already near the practical limit for the number of indexes we're maintaining.

Allowing multiple method values in filters makes it harder for PostgreSQL to consistently choose optimal plans—even for single-method queries—due to increased planner complexity and index ambiguity.

Given this, and since this functionality is more of a “nice to have” than a strict requirement, I’d propose we leave it out for now.

This might be better suited in the future if we introduce export-style endpoints designed for long-running jobs, where performance constraints will be less strict.