Adding filterByRegex method to Laravel Collections

[mohammadrasoulasghari]

Hi everyone! I'm considering contributing a new method to Laravel's Collection class called filterByRegex.

What it does

The method would allow filtering collections using regular expressions in a clean, readable way:

// Filter strings directly
$collection->filterByRegex('/^p/');

// Filter by a specific key
$users->filterByRegex('/@gmail\.com$/', 'email');

// Filter with dot notation for nested arrays
$data->filterByRegex('/PHP/', 'user.profile.bio');

// Filter with a callback
$products->filterByRegex('/2023/', fn($product) => $product->sku);

Why I think it’s useful

While this can be done with the existing filter() method, filterByRegex would:

• Make regex filtering more readable and explicit
• Support dot notation for nested arrays out of the box
• Follow Laravel’s pattern of having specialized filter methods
• Reduce boilerplate when working with regex filters

Questions

1. Would you find this method useful in your projects?
2. Are there any edge cases or parameters I should consider?
3. Is this something that belongs in the core Collection class or would it be better as a macro?

I’d appreciate your thoughts before submitting a PR. Thanks!

[henzeb]

While it is possible using filter, that one uses a closure. I would opt for altering filter to accept a string that executes the regular expression.

[mohammadrasoulasghari]

Why would you assume that?

My concern is that for some developers — especially those who are newer to Laravel — it might not be immediately clear, since filter() has traditionally worked with closures.
That said, I believe this bottleneck could be resolved if the documentation is clearly updated to reflect the new behavior.
Overall, I'm just bringing this up to help ensure we're choosing a clear and thoughtful path that keeps developer experience in mind.

[shaedrich]

Doesn't filter() accept callable and not just Closure?

Touché.

function filter(string|callable $filter)
{
    match (true) {
        @preg_match($string, '') !== FALSE => preg_match($filter),
        is_callable($filter) => call_user_function($filter),
        default => 'filter does not support arbitrary strings',
    };
}

[mohammadrasoulasghari]

@rodrigopedra I need your opinion about this.🙏

[rodrigopedra]

Hey @mohammadrasoulasghari, I would have it as a separate function, as per your suggestion.

JavaScript takes both a string and a regular expression on some String methods (replace(), match(), ...), and more often than not I had to explain the difference of using each to new developers. I guess if there were different methods, it could be somehow easier to spot the difference.

In JavaScript-land, one could argue those ambiguities don't happen, as regular expressions have their own delimiters, but in PHP, that is not the case.

I also think that the lesser a method does, its intent is clearer, and it is easier to test.

And, IMHO, the more execution paths a function has, the more prone to bugs and edge cases it is.

Many methods that take a boolean argument, in Laravel, have another method with that argument hardcoded, to be clearer, and to avoid the cognitive load of remembering these implementation details.

For example, the proposal of running preg_match twice isn't my cup of coffee. Granted, one could assign the result to a variable in the condition, and then just return (($result = preg_match($string, '')) !== FALSE => $result).

Also, in the same proposal, how should a string like '_b_' be handled? This is a valid function name a user can have defined on their codebase, and also a regular expression with a valid delimiter (Delimiter must not be alphanumeric, backslash, or NULL).

Should the is_callable check should be moved up, to avoid it being considered a valid regular expression first? (e.g.: preg_match('_b_', 'b'))

This is an example where, when coding one might oversee some edge case, but later when released to users, those might appear.

Having two separate methods also makes the implementation of filterByRegex() dead simple, as it just a matter of delegating to filter():

public function filterByRegex($regex, $key = null)
{
    return $this->filter(fn ($item) => preg_match($regex, data_get($item, $key)) === 1);
}

TL;DR; I would have a separate function to make the intent clearer, to be easier to maintain, to be easier to test, and to avoid ambiguities.

[mohammadrasoulasghari]

Thanks @rodrigopedra ! 🙌❤️
I totally agree with the points you mentioned