Why don't we, so we have the name and the start time, we also need the name of the podcast, or perhaps maybe after we create this listening party, we're creating it, and then adding that episode later, maybe in like a modal, for example, but if we take a look at our listening_party table, we actually have it set to an episode. So we cannot create a listening_party unless we have an episode. So with that case, perhaps we need to also create the episode here as well. So why don't we add another field for the podcast_link? So we have, in our dashboard, we have an x-input, and we can wire:model this to podcast_url, and we can have the placeholder to be podcast_url. We could say maybe podcast_episode_url.

URL, and we can have the placeholder to be podcastURL. We could say maybe podcastEpisodeURL. When the description for the podcastEpisode, we can say RSS feeds will grab the latest episode. Now we have this description here, direct episode link or YouTube link, RSS feeds will grab the latest episode. Okay, why don't we wire model this up? So we have the podcastURL, and we'll set that here as well. So public string podcastURL, and just for simplicity's sake, why don't we go ahead and just dd(variables), so that way we know what we're saving or going to.

So public string podcastUrl, and just for simplicity's sake, why don't we go ahead and just dd these variables, so that way we know what we're saving or going to be saving to the database. And in this X button, why don't we say that this is a type of submit? There we go. So now we have listeningPartyName of the podcast episode, as well as a startTime. There we go. So we have the listeningPartyName, the dateTime, in this case, 1400, I said 7 a.m. So that is good to know, that it does take local time into effect for this dateTime picker.

So that is good to know, that it does take local time into effect for this date time picker. And that's very helpful for us. Okay, this is looking pretty good. So now we have all of these variables ready to be entered into the database. Let's validate them first. So this should be required, and as a URL, we can bring in the use Livewire attributes to validate. Same thing for the name, we can validate this as a string and probably a max of 255. We don't need any more than that for a listening party name.

Same thing for the name, we can validate this as a string and probably a max of 255. We don't need any more than that for a listening party name. And then the startTime is going to be just a validate of required because we are casting that on the back end. Now we can call this validate. We can first check if there is, so what we want to do, we can first check that if there is an Episode with that URL. I think in listening party, we said the name, yeah, the name doesn't have to be unique. So we're going to first check that there are not existing Episodes with the same URL. And then what we can do is, if there is, use that, if not, create a new one.

So we're going to first check that there are not existing episodes with the same URL. And then what we can do is, if there is, use that, if not, create a new one. So that way we can say, okay, I'm going to use this URL to create a new Episode. From there, we can kind of do the scraping of gathering the data for that Episode. We don't have to have the user submit that information, but then we can create a new ListeningParty with all that information. We would probably want to have this be done in a background job that runs right away because what we need to do is get the information so that we could set the end date of the ListeningParty. So when a new Episode is created, grab information with a background job.

party. So when a new episode is created, grab information with a background job. And then what we're going to do is then use that information to create a new listening party. And we might want to think through how this works because when the User submits this, we do want to give them perhaps a link to the listening party, even if the episode hasn't been fully scraped and created just yet. And so knowing that because we want this to be as quick as possible on this initial request, we probably can create a listening party without a end_time date. So maybe we can make this nullable.

we probably can create a listening party without a end_time date. So maybe we can make this nullable. What we're wanting to do is create the Episode. We're going to then create a new listening party from that Episode. But since we might not have ran that background job or that background job might not have been completed just yet to get the information for, okay, what is the end_time of that Episode? We don't want that to hold us off for creating a new listening party. We want it to be as succinct as possible. And additionally, we want the podcast_id on the Episode to be nullable as well. What we can do here with Laravel's Eloquent ORM is down the line after we have this metadata.

And additionally, we want the podcast_id on the episode to be nullable as well. What we can do here with Laravel's Eloquent ORM is down the line after we have this metadata information from an episode, we now know once this background job has run what the podcast_title is, what all this information is. We can then associate this episode with a podcast, but we don't necessarily need that right off the bat to run this request. So what we do here in the createListeningParty is create a new episode with, and maybe even in the createEpisodes, we don't necessarily need a title of the episode. This can also be nullable. So stick with me here because we don't want this initial request to be that expensive.

This can also be nullable. So stick with me here because we don't want this initial request to be that expensive when we, in our dashboard, say I'm going to create a new listening party for our User. We first want to create an Episode and we have that podcast URL, and maybe for consistency's sake, we'll call this the media URL, and we'll do the same thing here. So media URL, because we're going to be saving that and creating a new Episode with it. Well, because this podcast ID can be nullable, we don't necessarily need to create a Podcast right away. We can wait for that background job to kind of scrape this information, to grab the title and the Podcast, and then update it at that point.

We can wait for that background job to kind of scrape this information, to grab the title and the podcast, and then update it at that point. So now we can create that listening party. In our dashboard, we can say we're going to create an episode with this media URL, kickstart a job that says, I want to take information from this episode, create a podcast and update the episode, and then in this initial request, we create the listening party. Because we have all the necessary information that we might need, we've created the episode, we have the name, a default value of isActive so that we know this is going to happen at some point in the future, and we want to make sure we have some validation for the startTime of that.

some point in the future, and we want to make sure we have some validation for the startTime of that. We don't want someone to start a listening party in the past. And we have the startTime, and the endTime will update after we get that information from the episode. So we can create a new episode and say that the mediaUrl is going to be this mediaUrl. Then we can go ahead and create a listening party. And we can say that this episodeId is going to be the episodeId that was created. We have the name of the listening party, as well as the time when the listening party should start.

We have the name of the listening party, as well as the time when the listening party should start.