In fact, in this case, I don't even think I have a test for the caching aspect. Yeah, although I probably should. All right, let's keep going. Now you'll see here, we start by fetching those database-specific featured collections that we had here, right? But then it starts prepending the dynamically generated collections here and here. So with that in mind, what if I created a method something like this? And again, if only temporarily. Let's start with this. And this is going to return an array of all of the class names that are dynamic.

Let's start with this. And this is going to return an array of all of the class names that are dynamic. So for example, Trending, RecentlyUpdated, Watchlist, and then finally, InProgress. And in fact, what I could even do is new those up. So quickly collect them, map over each one, and then instantiate it. All right, so now this method returns a Collection of all of our dynamic class instances. Now it sure would be nice if I could remove all of this junk and just say, get those featured collections, and then merge in all of the collections from this method call. All right, that would be nice. But if I ran it, it's all going to fail.

All right, that would be nice. But if I ran it, it's all going to fail. And that's because once again, some of these should only be run if you're signed in. So I'll show you an elegant way we can deal with this. Really what we're doing here when I say ifAuthCheck, yes, we're checking if the User signed in. But I'm really checking if that featured Collection should display when the person visits the Series page. So what if we made it the responsibility of each of these classes to let us know if it should be displayed?

So what if we made it the responsibility of each of these classes to let us know if it should be displayed? We are reassigning that responsibility. So if we took that approach, what we could say is on the featured collection, by default, I said shouldDisplay. So why don't we call it shouldDisplay? By default, that returns true. We shouldDisplay any featured collection unless we override it. OK, so now if we come back, let's see. If authCheck, so we want to update watchlist and inProgress.

OK, so now if we come back, let's see. If auth check, so we want to update watchlist and inProgress. Let's do this one. Should display depends on if you're signed in. And by the way, if you don't like to reach for auth here in a model, I get it. That can be kind of weird sometimes. If that's an issue for you, you could pass through the User model here when you call it. And we might even do that. But to get us started, we'll reach for that.

Is there a way to do that in reverse, where I basically say merge it, but whatever here comes first? I don't know. Here's what I'm going to do. Let's, even if this is only temporary, let's extract a method here called databaseFeaturedCollections. And then I'm going to get rid of all of that, all of this. And I'll explain this in a minute. Let's grab the dynamicCollections. Those come first, then merge in the databaseCollections, which is right down here.

Let's grab the dynamic collections. Those come first, then merge in the database collections, which is right down here. Then filter. I think we should be able to get rid of that in a moment. But then do one more. Filter it down to where the featured collection should display. So we've reassigned or moved that responsibility onto the class itself. So recentlyUpdated gets to know if it should display, as you see here. watchlist gets to determine if it should display. Okay, so how are we doing?

Watchlist gets to determine if it should display. Okay, so how are we doing? Give it a run. It fails. The return value should be an eloquent collection, but we got a base collection. Oh yeah, that's because we're now starting with a base collection. And that's fine. We'll just do the top level. So that's just a test here. Give it a run.

I have an Idea. What if the featured collection is the parent and we have should display? So what if we were to say, well, this should authorize and then check if we have any series? Yeah, I think this would work. So what we could do is add our authorize here. And the default authorization is yes. You can see it. So we call that. And then the next check is if we have any series. So this series count.

And then the next check is if we have any series. So this series count. Yes. So now our subclasses don't override shouldDisplay, although they can if they want. But instead, they're going to override authorize. So this would become authorize and progress is authorize. So I'm changing a lot of code here. It makes me nervous. But let's see if this works. So get rid of all of this, bring it back to a single filter.

But let's see if this works. So get rid of all of this, bring it back to a single filter. And with any luck, it still passes. Yes. So that's a way we can handle this. All right, let's keep going right down here. Featured collection with series, get the results and then shuffle them. This is fine. But what if we just said, just shuffle them? Like, do I need to be more specific than that?

But what if we just said, just shuffle them? Like, do I need to be more specific than that? Of course, the only problem is that doesn't work. Okay, let's add a little helper method at the top. shuffle. And that returns our query. Eager load the series, get the results and then shuffle them. Reformat, rerun the code. And that's a decent refactor. Okay, getting a little cleaner.

And that's a decent refactor. Okay, getting a little cleaner. Next, I don't have a problem with this being its own method. But let's see if I can just get rid of that entirely. Run it, that works as well. Is there anything? Actually, a couple things. Right here, we could refactor this to use higher order messages. So we're going to filter down and for each item, we're going to call a method on that item. So in those cases, we could rewrite this like this.

So we're going to filter down and for each item, we're going to call a method on that item. So in those cases, we could rewrite this like this. And if this is confusing, again, research or Google Laravel collections higher order messages. I think that's how he calls it. Yeah. So that's the exact same thing. Should display is not being called on filter. It's being called on what's passed to filter effectively. It's just shorthand.

We've optimized it. We've isolated it. But there's one more approach I want to show you. And that will involve service providers. So we'll take a look at that in the next episode.