The easiest way to show you the issue we have with genre and subgenres in our book is to create a new book. So I'm going to head down to the bottom here where we have the genre and subgenre picker and I'll open the select box and note that we have a huge range of genres. But the problem is they're not all genres. You can see in TablePlus that we have a parent_id column and if that parent_id column is null then what we're actually dealing with is a genre. But if a parent_id exists then we're dealing with a subgenre. So how can we solve this? Well from a data validation point of view we can solve it with basic rules. Let's add those. For a genre we might say rules. Let's add required for consistency and then I'll use the rule exists method. I'll say that it should exist in the genres table under

those. For a genre we might say rules. Let's add required for consistency and then I'll use the ruleExists method. I'll say that it should exist in the genres table under the ID column where the parentID is null. So that's a correct rule for making sure that the genre is selected. The issue is that that won't change anything on the front end. Sure enough if we try and select say alternateHistory which is a subgenre and attempt to create the book one of the issues we get is the selected genre is invalid. But that is a terrible user experience. Thankfully Nova allows us to fix this. So we'll jump back into the IDE and I'm going to add another method called relatableQueryUsing. relatableQueryUsing receives the current Nova request which is just a request object with a few added methods and properties along with a query which is an instance of an Eloquent

query using receives the current Nova request which is just a request object with a few added methods and properties along with a query which is an instance of an Eloquent query. You can think of these as scopes. So a way to alter the items that will be available to Nova on the front end. We start with the default scope which will be all genres but I could simply edit this to say query where null parent ID. If we now go back into the front end and reload and head down to the bottom I'm limited to only genres which have no parent ID top level genres. So this is completely correct. And now we have fixed genre inside this resource. But subgenre still poses a problem. If I select subgenre you'll note that we show all possible genres. So let's go ahead and add similar logic as before. I'll copy and paste this code seen as we're only going to be tweaking a few small bits.

note that we show all possible genres. So let's go ahead and add similar logic as before. I'll copy and paste this code seen as we're only going to be tweaking a few small bits. I can change this to say we're not null parentId and I can change the rule exists to also say we're not null. Has that solved our problem? Well let's jump back into the browser and take a look. If we select a biography I can select subgenre and sure all the top level genres have gone but I still get a huge list and most of these are not subgenres of the biography genre. So it's sort of working but it's not really completely working. In fact the only way to get this working is if our Nova resource is able to update the genre in real time. Thankfully Nova provides dependent fields to solve this problem. Let's create a dependent field for our subgenre. So in the subgenre I'm going to chain on a new method

in real time. Thankfully Nova provides dependent fields to solve this problem. Let's create a dependent field for our subgenre. So in the subgenre I'm going to chain on a new method called dependsOn and the field I want to depend on is the genre. This accepts a function that receives the field you're currently using, in this case it's a belongsTo field, the Nova request and formData. formData is going to contain the information currently set inside the frontend form. So what will happen is as we update the genre here, this method will be called allowing the subgenre to be edited to our liking. So let's think about it. When you first go to create a book the genre will be null. In that case let's say if the dataGenre is equal to null I'm going to hide the field. In other words if there is no top level genre we cannot select a subgenre. However if there is a top level genre then

if the dataGenre is equal to null I'm going to hide the field. In other words if there is no top level genre we cannot select a subgenre. However if there is a top level genre then we want to do similar to what we've already defined here. So I'll cut that out and I'll paste it here and I'll prepend this with field. I'll add the data to this scope and inside here rather than saying we're not null I can say where the parentId is equal to the dataGenre. The same is true of rules down here. I'll say where the parentId is equal to dataGenre. And as easily as that we're able to create a dependable field that will dynamically update on the frontend. Let's check it out in the browser. So I'll reload. When it first loads there is no subgenre because we've asked it to hide when the genre is null but as soon as we select a genre the subgenre appears. The options for subgenre are limited to the

loads there is no subgenre because we've asked it to hide when the genre is null but as soon as we select a genre the subgenre appears. The options for subgenre are limited to the items available based on our dependsOn. If I change from biography to fantasy then my list is going to change here. If I change from fantasy to western then my list is going to change here. And if I select a subgenre but then change the genre this will be set to null again so we can select it once more from the dropdown. So dependsOn is an incredibly powerful way of creating a dynamic experience as necessary in your forms. And it's not only the belongsTo relationship that supports dependent fields. In fact all of these fields listed here in the documentation can depend on other fields. And there's only a small handful of fields that cannot be depended on. So most of the time you can build very

listed here in the documentation can depend on other fields. And there's only a small handful of fields that cannot be depended on. So most of the time you can build very dynamic field sets that react based upon the values that you've selected in earlier parts of the form. It's incredibly powerful and yet it's very easy to implement. Simply define which field or fields you want to depend on, add a closure that accepts the field you're currently editing, the request and the current data and then the sky is the limit. You can change that field as much as you'd like and you'll see that reflected in the front end as you change and update values.