[5.2] Optional query builder calls via a when() method

[tomschlick]

I keep finding myself in situations where I need to break a chained query builder to add in optional calls. For instance, recently when working on an api, I needed to add optional sorting / filtering for the query. If the sort parameters existed in the url, then they should be added but if not it should follow its default sort.

To do this in the current QB you have to break the chain...

$query = $model->where('customer_id', 1234)
    ->where('created_at', '>=' '2016-01-04 20:34:56');

if (! empty($sortParams)) {
    $query->orderBy($sortParams);
}

return $query->get();

with this new when() method, we apply the new commands via a closure if the first parameter evaluates as true...

return $model->where('customer_id', 1234)
    ->where('created_at', '>=' '2016-01-04 20:34:56')
    ->when(! empty($sortParams), function($builder) use($sortParams) {
        return $builder->orderBy($sortParams);
    })
    ->get():

This is a simple example but if you were trying to add many things based on conditional arguments you could see how the top would get unruly pretty quickly. The lower example alleviates that a bit, at least in my mind.

[dvlpp]

IMO, maybe because of the PHP closure "use" complexity, your proposal makes it more difficult to read than conditionnals. But I'm not saying that the PR should be rejected: in some cases, it could be useful.

[eddiewebb]

Leaning with @dvlpp, extending the chain with conditional logic is less readable, and does not seem to shave any verbosity.

[robclancy]

PHP already has an if statement why are you trying to make a new ultra specific one?

[GrahamCampbell]

"truthy" is the correct word here

[tomschlick]

@dvlpp yeah i put the use() to be syntactically correct but in real life you may just use the request()->input('whatever') call directly within the closure instead of passing it through

@eddiewebb exactly, not perfect for every situation, and shouldn't be abused, but in some cases I think it makes total sense when you're trying to keep the "flow" of a longer query going instead of breaking it out into 5 or 6 chunks for each conditional

@robclancy of course PHP has ifs, which I'm utilizing here, problem is that we don't have that ability within the chain for a query.

[vlakoff]

Agree with the others, I often "break the chain" as such and I think it is the lesser evil.

Still, you may add this method to your codebase like so:

use Illuminate\Database\Query\Builder;

Builder::macro('when', function ($value, $callback) {

    if ($value) {
        return call_user_func($callback, $this);
    }

    return $this;
});

[tomschlick]

Of course. I already do that. Just thought it would be useful to some others. 

Tom Schlick

On Sun, Mar 27, 2016 at 12:02 PM -0700, "vlakoff" notifications@github.com wrote:

Agree with the others, I often "break the chain" as such and I think it is the lesser evil.

Still, you may add this method to your codebase like so:

use Illuminate\Database\Query\Builder;

Builder::macro('when', function ($value, $callback) {

if ($value) {
    return call_user_func($callback, $this);
}

return $this;

});

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[drbyte]

@tomschlick I feel your pain. I have a project where I've had to break the chain frequently to handle a number of "orWhere" clauses, which have various dependencies. I'm doing similarly to what you and @vlakoff have posted.

I'm torn as to whether it helps with readability, or just makes me feel better that I can keep the chain together. I think "not breaking the chain" helps with readability, even with the closures in the middle.

I'm not casting a vote here, just raising my hand to wave and say "I hear you".

[tomschlick]

Wooohooo!