The Eloquent Query Method
Playing
02. Visual appeal

Episodes

0%
Your progress
  • Total: 23m
  • Played: 0m
  • Remaining: 23m
Join or sign in to track your progress

Transcript

00:00
Okay, so the first and probably least important reason to use query would be visual appeal. If you've ever found yourself building up a query and pulling things down to multiple lines, which is kind of like a Laravel convention, you'll find yourself making this a little bit harder to read.
00:17
Now by this I mean if we were to get rid of the query method here and we were to do something like this, for me at least the first thing I go to is this post and then down to the second line. That's just personally how I read this.
00:28
Now some people prefer to pull in the query method specifically and then go ahead and chain the most important parts on each line so they have a line of their own. Now for something as simple as this, it doesn't really make too much sense. Of course there's nothing wrong with doing this.
00:45
It's entirely personal preference. But when things start to get a little bit more complex, that's where sometimes the visual appeal of query comes in handy. Now over in the database, if we just have a look, we've also got this published column
00:58
here which we can use to scope this. So I could then say where, I could even use a dynamic method, where published true for example, and that would only give me back things that have been published. If for example we chose post two, that should give us back an empty collection.
01:14
Or we get a 404 because we've used first or fail. So it's really entirely up to you. If you would prefer to pull these important parts down to their own lines, then using query like this can be really handy just for the readability aspect of your code.
01:30
However, let's look at a much more complex example here just to see how this would work nicely. Let's say that the published option came from the query string. So we're allowing the user to control whether they wanted to see published posts or not.
01:45
This could be in some kind of filter within a form. So we're going to go ahead and pull in the request just here so we can access this. And doing this is a little bit more complicated. If we think about what would come through from the request, we might have something
01:59
like include underscore unpublished for example, which might just be an empty value. We're not going to want to immediately pass that through to where published or where published equals something. So what we would typically do in this instance is we would build up the query that we wanted
02:16
to see. So we could do something like the following. Then we would come down and we would add in an if statement. So we would say if request include unpublished, so if that is available and filled in, you
02:29
could even compare it to a string value or a Boolean value and cast it. Then you would go ahead and continue to chain this on. This would be how you would just do it normally. So let's just say where published true.
02:43
So we're specifically saying that we want to use that. And let's go ahead and make this not. So if we don't want to include unpublished, we're going to go ahead and set where published to true to scope that.
02:53
And then down here, we can go ahead and say post equals post get because ideally we would want to get a collection of posts regardless of their state. So let's just give this a refresh. You can see at the moment we've got a list of empty items.
03:05
Let's just have a look why that is. That is of course because we are scoping this by the slug. We don't actually want to do that. So here we get one item, one post back because by default, we are only grabbing back things
03:16
that are published. But if now we go ahead and we say include unpublished true, then we get back both of these. So obviously this is just a really, really simple example.
03:26
But we could actually tidy this up with an eloquent method. And then we can use query to make this a little bit tidier and better to read in my opinion. So let's go ahead and just get rid of everything that we've done here. And let's just do this all in one line, which is always a little bit better.
03:42
So we're going to go ahead and say post, and we're going to say when. So we're going to say not request include unpublished much like we did before. And then with this, we get a callback in here that gives us through a query builder, which we can then use to scope this.
04:02
So query where or where published true. And then we can go ahead and say get like this. So if we head over now and give this a refresh, we get exactly the same result including unpublished is being taken into account.
04:16
But sometimes you might have additional things in here that you might want to scope before this for example. So you might have something that you want to do here. And I tend to find that doing this and then pulling this down and indenting both of these
04:29
so they kind of match up just is a little bit better for readability. It might not be for you and that's absolutely fine. But the point is that using query and bringing the important things down to another line tends to make things a little bit more readable.
04:44
So you can just scan down and each line has its own part of the query builder. Okay. So like I said, the visual appear of this isn't the most important part of using query. Let's look at something a little bit more useful in the next episode.

Episode summary

In this episode, we're focusing on the visual appeal (or readability) of queries in Laravel. While it's not the most crucial reason to use Laravel's query() method, it's still a nice bonus. We look at how breaking queries into multiple lines, especially when using Laravel conventions, can make your code easier to scan and understand—especially as things get more complex.

You'll see some hands-on examples of filtering posts by a published column and dynamically filtering results based on a request input (like a query string parameter for including unpublished posts). We play with both the "classic" chained format and a more readable, indented multiline format using when for conditional logic.

Throughout the episode, you'll get a sense of how little things like how you break up your code can make a big difference when you need to navigate or update it later. While visual organization won't change the functionality, it can save you headaches during maintenance or when collaborating with others.

Stick around, because in the next episode we'll dive into more practical benefits of query()!

Episode discussion

No comments, yet. Be the first!