Now that we've kind of written out these thoughts, we can start by creating the models that are relevant to the first step that we want to build within our application. Again, we want to have the User be able to add a link to a media, maybe an RSS feed, a YouTube link, or just an MP3 link. And with that, start the creation of a listening party, an Episode, and a Podcast. So let's get those models ready to do that. We'll say php artisan make:model, and we can start with the Podcast model, and why don't we create a migration and a factory just so we can get some test data up and running. So we'll do that with, we'll also do that with the Episode, so php artisan make:model, Episode. And for the listening parties, these are rooms or sessions centered around a particular Episode.

So we'll do that with, we'll also do that with the episode, so makeModel, episode. And for the listening parties, these are rooms or sessions centered around a particular episode. The naming could be maybe listening party or a podcast room. Why don't we call it listening party? So we'll say php artisan make:model listening_party, and we'll create that as well. So let's start off with the migration for the podcast itself. So if we go to our podcast migration, then we can say the podcast has a string of title, and maybe we want this to be unique in the sense that a podcast is probably the only name of the podcast. If we added new episodes, we would want to link them to that podcast in some way, shape,

name of the podcast. If we added new episodes, we would want to link them to that podcast in some way, shape, or form, and the title is probably going to be the most unique thing about that. And maybe we can call this a string of hosts, and perhaps this could be nullable, as well as maybe the artwork of a podcast, and we could put that in a string as well. So we could say the artwork URL, and that could be nullable as well. We could add a description just in case we wanted to have pages for specific podcasts to also add the string of the RSS URL. That way we could perhaps pull an additional podcast. Right now, we're probably just going to be focused on the title.

That way we could perhaps pull an additional podcast. Right now, we're probably just going to be focused on the title. So when someone adds a new episode or maybe an RSS feed, then we can create a new podcast grouping, a podcast collection from that. Okay, why don't we do the same for the episode? We can start by adding the name of the episode. We don't need this to be unique for this one, but we'll go ahead and we'll create a string of the media URLs. We could be grabbing the audio URL from the RSS feed, or we could be grabbing the YouTube link, for example.

We could be grabbing the audio URL from the RSS feed, or we could be grabbing the YouTube link, for example. And so this could be an audio format or video format. And then we also need this episode to be linked to a podcast as well. So we could call the foreign ID of the podcast ID, have it be constrained and cascade on delete. So if podcasts were ever deleted or perhaps the podcast author or host didn't want their podcast on the application, then all of the episodes would be deleted as well. So the episode has a podcast ID, so it's linked to a podcast. A podcast can have many episodes.

So the episode has a podcastId, so it's linked to a podcast. A podcast can have many episodes. An episode has a title as well as a mediaUrl. And the good thing to note as we're creating these migrations is these could change. That's the beauty of thinking through and building an application from start to finish. We have to be flexible. We might add a bunch of different columns by the end of this series. Right now, we just need to start moving forward. So we have our episode ready. We have our podcast ready.

So we have our episode ready. We have our podcast ready. Why don't we create the listening parties? So in a listening parties, this is the room, the session to listen to an episode. So we need to be linked to an episode. So first, we want this linked as a foreign ID, and we want this linked to episodes. So episodeId. And then why don't we give a listening party a name? So users can maybe create a name for a listening party. And so that'll be a string of name.

So users can maybe create a name for a listeningParty. And so that'll be a string of name. So we need to have a startDate for the listeningParty. So we can have a table of date, and we should have a dateTime because we would really like this to be a specific time that it starts. So dateTime, and we can just say startTime. And that's starting to shape up really well. So when a user submits a new media, we can create a new episode. If a podcast has not already been created for that episode, then we can create a new podcast and a new listeningParty for the date and time that the user has selected to.

If a podcast has not already been created for that episode, then we can create a new podcast and a new listening party for the date and time that the user has selected to listen to that episode. Why don't we go ahead and run these migrations, and then we can create the relationships in the models themselves. So php artisan migrate. There we go. And let's start off with the Podcast. So a Podcast has multiple Episodes. So we can create that public function episodes as hasMany, and we can return the episodes for

So a Podcast has multiple Episodes. So we can create that public function episodes as hasMany, and we can return the episodes for that Podcast. We can do the same for listening parties, just in case we wanted to have analytics for how many listening parties a Podcast has had or maybe is having currently. And then why don't we create the fillable fields for the Podcast? I actually, instead of fillable, like to use the protected and guarded command. That way I can just set it to the ID. Let's do the same thing for episodes. So for episodes, we have the podcast, which this belongs to, and we can set this to a

Let's do the same thing for episodes. So for episodes, we have the podcast, which this belongs to, and we can set this to a podcast. Same thing for listening parties. So a episode can have many listening parties as part of, perhaps someone wants to listen to an episode multiple times throughout the next week after an episode has been released. And then we'll go ahead and bring that in and use the protected guarded feature. And again, we'll set this to ID. The guarded feature is the inverse of fillable. If you ever use fillable, where you set each specific column that you would like to be

The guarded feature is the inverse of fillable. If you ever use fillable, where you set each specific column that you would like to be mass assigned. In this case, this is just the inverse saying everything can be assigned except for anything in this array, which is id. And then lastly, we'll do the ListeningParty model. We'll start with the guarded of id, an episode that belongs to, and then that should be everything we need for the ListeningParty. And now in our dashboard, Livewire component, why don't we start by creating the form in this dashboard component with Livewire.

And now in our dashboard, Livewire component, why don't we start by creating the form in this dashboard component with Livewire? We can, of course, abstract that form into a new Livewire form class, but for now we'll just put it in the component and abstract it when needed. So the first thing I like to do is bring in whatever data we would need in this Livewire component. In this case, we're going to be showing a list of listening parties that are going on. So we can call the public function with, and what this is going to do is anything in this function, in this method, is going to be passed into the view layer of this Livewire component. So we want to return the listening parties.

function, in this method, is going to be passed into the view layer of this Livewire component. So we want to return the listeningParties. And we'll go ahead and say that this is perhaps the listeningParty all for now. We'll adjust this in a little bit once we actually get listeningParties in because we only want the listeningParties shown on the dashboard that are active right now or are going to be active. If they're listeningParties that have already since been completed, we don't necessarily want those shown on the page. And now that I'm thinking of it, one other column that we could add to the listeningParties table is we need to know when this has ended.

And now that I'm thinking of it, one other column that we could add to the listening_parties table is we need to know when this has ended. In this case, we have a start_time. It might be good to have another date_time field for end_time. Or perhaps we can just have a Boolean of completed or finished. And maybe we want both. Perhaps we need a finished or a completed listening party Boolean just so that we could easily query for that. But we also maybe want an end_time to show how many minutes are left to users who are looking for any listening parties.

But we also maybe want an endTime to show how many minutes are left to users who are looking for any listening parties. So maybe we'll do just that. We can have an endTime and maybe we'll have a boolean. And we can say isActive might be a good way of putting this. So we could instead of saying completed when it has been created, it isActive. It is displayed on the dashboard. And we could set isActive to false after the endTime has passed. I do quite like that. So back in our dashboard, we're grabbing the listening parties of all.

I do quite like that. So back in our dashboard, we're grabbing the listening parties of all. And that way we have this accessible in the view. Let's see if we ran our php artisan migrate. We did. Why don't we rerun that now that we have the new columns in our listening parties? So I'm just going to run php artisan migrate:fresh. And now we have everything ready to go. So we're going to have a public function of createListeningParty. And we can start by adding the $state for our Livewire form at a public string.

So we're going to have a public function of createListeningParty. And we can start by adding the state for our Livewire form at a public string. And we'll call this the name. One thing I like to do is pull open the listening_parties column in the side right here. Okay. What are we actually creating when we're creating a new listening party? We're having creating the name. The episode is we're linking this to an episode. So a new episode has to be created at that point. is_active is already set to true.

So a new episode has to be created at that point. isActive is already set to true. So we don't need to input that. And then we need a startTime. And the endTime is going to be one that we'll probably calculate once this has been added. So create a listeningParty. We have a public string of name. And next we'll add the startTime. So we'll say public startTime. And we will just add that there.

So we'll say public $startTime. And we will just add that there. And one thing that we can do here is in our ListeningParty model, we also want to set this startTime to be cast as a DateTime. Here we can say protected $casts equals. So isActive is a boolean, startTime is a DateTime and endTime is a DateTime.