Enhance search by filtering by URL, hostname and dns resolve server

[Ionys320]

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

Fixes #5422 . This PR is pretty simple (just three lines enhancing existing filters), but makes so much sens to me..

Note: Even if this is not supposed to occurs, the code handle the case url would be null/undefined.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots

[CommanderStorm]

At its core this is reasonable change.

I am a bit sussed out by this code in terms of performance as I implemented something similar in another project and the performance was pretty bad.
I think we should switch to Regex comparisons instead as they are faster than the call to .toLowerCase() as far as I remember and can handle caseness.
What do you think?

[Ionys320]

Hi @CommanderStorm! After some tests, it appears regex is more efficient when you have ~100monitors. Before, lower-case can be better. But because UK is designed to handle a lot of monitors, regex has been used instead. Thanks for the suggestion!!

[homelab-alpha]

I was thinking more along the lines of something like this:

// filter by search text using regex
// matches monitor name, tag name, or tag value
let searchTextMatch = true;
if (this.searchText !== "") {
    try {
        const regex = new RegExp(this.searchText, "i"); // "i" for case-insensitive matching
        searchTextMatch =
            regex.test(monitor.name) ||
            (monitor.url && regex.test(monitor.url)) ||
            (monitor.hostname && regex.test(monitor.hostname)) ||
            (monitor.dns_resolve_server && regex.test(monitor.dns_resolve_server)) ||
            monitor.tags.some(tag => regex.test(tag.name) || (tag.value && regex.test(tag.value)));
    } catch (e) {
        console.error("Invalid regex pattern:", e);
        searchTextMatch = false;
    }
}

[Ionys320]

Relevant indeed, I forgot to take into account the null/undefined values. Will do the changes, thanks @homelab-alpha

[Ionys320]

Or better: suggest the change via the review feature so you can appear in the contributors.

[homelab-alpha]

@Ionys320 , You came up with the fix, we can share the credit. 😊

[Ionys320]

So, the input is now regex friendly, that's fun. I wonder if it can broke something, I tried do search a fiew fields and it went fine.
The only issue I could fine is about . : when you search for goo.gle, it will find google.fr, even it it's not the request (logic because . is considered as any character). I wonder if it's an issue, because if so, we'll need to rollback to the lower-case method. @CommanderStorm?

[CommanderStorm]

I'd consider regexes working somewhat like a feature.
Alternatively, we could just replace special characters away by escaping them.

I am fine with both

[Ionys320]

Approved then!

[Ionys320]

Okay so: the searchbar is now escaping regex expression (#5466 (comment)).

This PR creates the issue #5466. This issue occures because the PR extends the used fiels, but the PR is not creating the issue neither. But maybe fix #5466 before merging the PR would be a good move.