I'd like to focus on this section here. This is how we declare and determine what our dynamic collections are. So as a first refactor, let's move this to a field, something like collections. And we'll store it here. Save it, rerun it, and we're still passing. So now I've isolated these further. But again, I'd still have to return to this query class every time I add a new one. Not a big deal. We've optimized for that. But if you want to take it a step further, yeah, why don't we consider adding a service

We've optimized for that. But if you want to take it a step further, yeah, why don't we consider adding a service provider? FeaturedCollectionsServiceProvider. All right, we'll extend that. And then, of course, I need to register that in my config/app.php file. So I'm going to do that. And then I'm going to pass featuredCollectionsServiceProvider. Okay, so now, this is going to register and boot for every request. Okay, so have a look.

Okay, so now, this is going to register and boot for every request. Okay, so have a look. What if rather than declaring these on the query class, we instead injected them? Like this. We remove that, and we switch it over to FeaturedCollectionsServiceProvider. Now if I come back, we need to accept it. So we'll declare it here. And then accept it through the constructor. Like so. Okay, so now if I run the code, of course it's going to fail.

Like so. Okay, so now if I run the code, of course it's going to fail. And that's because it's trying to resolve the query class, but it has no idea what we want for collections. Okay, let's tell it. In my register method, we will bind into the container. And we'll say, when you ask for that query class, I actually want to give you this instead. Return new query. And specifically, that array of collections that we've defined here. Okay, so does that make sense?

And specifically, that array of collections that we've defined here. Okay, so does that make sense? Whenever you, for example, in a controller type hint query, normally Laravel will try to resolve it for you. But if it ever comes to something like this where it doesn't know what you want, it'll fail with that binding resolution exception. So that's why here we're saying, well, if you ever come across this string, don't try to figure it out on your own. Just call this function. This is specifically what I want.

Just call this function. This is specifically what I want. And in fact, that can even be a singleton, I believe. Let's give it a shot. We run it, and it passes. Okay, so now for all these custom or dynamic collections, we no longer have to update the query class to declare them. We instead visit our service provider and add our new item here, and everything will just work. Now, granted, that's still not quite open for extension.

just work. Now, granted, that's still not quite open for extension. You still have to modify this array here, but it's just a matter of how extreme you want to go. If you want to take it to the point where each of these classes will effectively register itself, that's called the registry pattern. You could do that, but I'm perfectly fine leaving it at this. Okay, so in fact, we could even go one further. You'll notice we're expecting an array, but then we immediately loop over that array and instantiate it.

You'll notice we're expecting an array, but then we immediately loop over that array and instantiate it. We could also just give it the collection of classes. So for example, I could say, well, yeah, exact same thing. It doesn't really matter, but you could collect these, map over it, and then new it up like that. So you're just doing all of that work once. Now return to the query class. We no longer need this method. We could just defer to our collections, and in fact, we could type into that if you want,

We no longer need this method. We could just defer to our collections, and in fact, we could type into that if you want, or it could be a custom collection, but I don't want to take this too far. Run it, and yeah, there we go. So now it's looking a lot better. So a quick note here. I find often with newcomers, they will note, well, you created four or five more files. That's not better. One file is better, and sometimes, I'll be honest, that is true, but in this case, just because you have more files doesn't mean the code is worse because each of these files

One file is better, and sometimes, I'll be honest, that is true, but in this case, just because you have more files doesn't mean the code is worse because each of these files is really easy to understand, and in fact, we're even going to clean these up quite a bit more in the final episode. They all follow the same shape. It's easy to understand versus that really long Query class that you have to parse and rebuild in your head every single time you return to it. We don't have to do that anymore, and in fact, you don't ever have to edit this Query class again. I'll show you.

class again. I'll show you. Let's create a new FeaturedCollection. We'll call it thingyThing. It's going to extend FeaturedCollection, and then we'll give it a title of something. It needs a description. Here is more about that thing, and then finally, a getter for the series. This is where we fetch all of the relevant series. Why don't we skip four, take two, get the results, whatever logic you'd want there. Give me all series in this category or all the series that the user blah, blah, blahed.

There's our custom featured collection. This is what I mean when I say open for extension, but closed for modification. I didn't modify a single line in this code. Instead, I created brand new code when I wanted to extend the series page with a new featured collection. Further, we've even added support for things like authorization. Now, if I just turn this off, nobody is going to see this collection. Give it a refresh, something. It doesn't show up because nobody is authorized to see it. Maybe you have one that is only visible to guests.