Feature: Also allow filtering by URL not just by request name

[N-Ziermann]

Description

Closes #2806. It enables users to not only filter their request by name, but also by URL.

I also added unit tests for the function I edited and therefore needed to add a custom jest-config to the bruno-app package that uses the compilerOptions.paths property from the jsconfig.

This was necessary because jest doesn't automatically read that property from the jsconfig file and therefore couldn't understand the utils/common imports from the collections/index file used in search.js.

Contribution Checklist:

• [x] The pull request only addresses one issue or adds one feature.
• [x] The pull request does not introduce any breaking changes
• [x] I have added screenshots or gifs to help explain the change if applicable.
• [x] I have read the contribution guidelines.
• [x] Create an issue and link to the pull request.

[helloanoop]

Hey @N-Ziermann Thanks for working on this.

One issue with this approach is that the search results displayed do not indicate the context for why they were matched. This becomes problematic when there are many collections loaded with a variety of requests.

[N-Ziermann]

Hey @helloanoop Thanks for your reply.

I understand your concern. I'd suggest we highlight the matching part of the request name using <mark> tags if the name matches and maybe turn the outline of the request path yellow (same yellow as when searching for something in the browser) if the path matches (to prevent issues with the syntax highlighting).

What do you think?

[tlaloc911]

There is another unmerges PR related to filtering #1230 , to allow folder name search, and it added a button to alternate between regular and by folder search, you culd add something similar

[N-Ziermann]

Thanks for pointing that out @tlaloc911 I'm afraid a toggle between different filters might not scale well. Having more than 2 options (as 2 are already described in the PR you just linked) would need a lot of space and might make it even more confusing at some point.

What I could see as an option is a filter (kebab menu) to control which filters you want to have active combined with the indicator I described previously. This would allow users to completely turn off filters they dont like whilst still seeing which attribute caused the filtered value to be visible

[N-Ziermann]

Here is a little illustration of what I mean. It's of course not to scale and the colors aren't ideal, but it should get the point across. If this is something that would improve this feature for you @helloanoop then I would love to implement it (with proper scaling and better looking colors of course 😉 )

[helloanoop]

@tlaloc911 @N-Ziermann I am thinking of a collection level search that not just filters by url, but much more like search inside body, scripts, tests etc

Let me know your thoughts.

Here is a draft PR I have on this - #3823

Demo

https://github.com/user-attachments/assets/5778b1f0-9891-4dbf-90f0-bcc53ebb43ae

[ghandic]

This would be super useful - any updates?

[sreelakshmi-bruno]

This functionality is available in Bruno via the cmd+k option. We are also planning an enhancement around filtering which is being tracked in #6283.

[helloanoop]

Closing this PR as we currently don't agree with the design proposed here.