Ok, let's play around with some of those methods that I talked about in our last episode. If we take a look at ID, note that Nova already automatically applies the sortable method. What does that do? Well, as you've probably guessed, it adds sorting options to the field in the index. So in this case, it's currently unsorted, but if I click the field name, I'm now sorting in ascending order the ID of a book. I can click it again to sort in descending order, and a third time to reset the sort to a neutral state. That's how simple it is to make a field sortable. It would make sense, wouldn't it, that title would also be sortable. So why don't we add the sortable method to the end of title, like so. Refresh, and sure enough, we can now sort by title.

So why don't we add the sortable method to the end of title, like so. Refresh, and sure enough, we can now sort by title. In ascending order, numerics come before the alphabet, so 1984 is first, followed by A and then B and C, but I can click title again to now sort in descending order. So Nova makes it incredibly easy to customise our fields to fit our needs. It would likely make sense that we can also sort by the number of copies, so that we can see which book we have the most copies of and which book we have the least copies of. Again, we can jump into the IDE, and on the copies field, I'll just add the sortable method, and now copies is indeed sortable, and I can filter in both directions. So that's sortable.

and now copies is indeed sortable, and I can filter in both directions. So that's sortable. What other methods do we want to play with? Imagine this scenario. Somebody comes up to you and they say, look, I'm new to reading. I'd like to read a book somewhere between 50 and 150 pages. What can you recommend? How do you find books between 50 and 150 pages? Well, of course, we could go in here and add sortable to pages. If we refresh, then I can drop to the least amount of pages and the most amount of pages,

Well, of course, we could go in here and add sortable to pages. If we refresh, then I can drop to the least amount of pages and the most amount of pages, and I could go through and find somewhere between that range. But that's not the most ideal way to do this, and it also requires that we have pages in the index, which I'm going to remove a little later on. Instead of using sortable, I'm going to reach for filterable. Filterable is going to automatically create a filter for me, and I can see those filters in this dropdown here on the right. So for a number field, it's a from to range. In our case, we want to say books between 50 to 150 pages,

So for a number field, it's a from to range. In our case, we want to say books between 50 to 150 pages, and just like that, we're able to limit to exactly that selection. So the filterable method is insanely powerful for these kind of use cases, and the filter that it shows is very much dependent on the type of field you apply it to. In our case, we've applied it to a numeric field, but we can just as easily apply it to a text field, for example. If we do that, then you'll see that the title is an open text where we can type the name of a book, and it will filter to just that instance. Not that I necessarily recommend doing that.

where we can type the name of a book, and it will filter to just that instance. Not that I necessarily recommend doing that. A search, I think, is a much better way of searching for plain text like a title, but the option is there. And many of the other field types that we'll explore in this series are also filterable simply by applying the filterable method. Now, one of the things I mentioned in the previous episode is that I don't want this pages field shown on the index. As you start adding more and more fields to your resources, the index can become quite cluttered.

As you start adding more and more fields to your resources, the index can become quite cluttered. And in my mind, an index should give me just the minimum amount of information necessary to scan and quickly understand what I'm looking at. It makes sense that the number of pages would show on the show screen, but it's not necessary here on the index. So how can I hide pages from the index of books? Well, in the IDE, I can chain another method onto pages, hideFromIndex, and you'll note from the autocomplete there that we can hide in different areas. I can hide from detail. That's the show route.

and you'll note from the autocomplete there that we can hide in different areas. I can hide from detail. That's the show route. I can hide when creating, in which case it won't show a field when I'm creating the resource. I can hide when updating. When you're editing the resource, it won't show. You can customize and add these methods onto your field as it makes sense on a field-by-field basis for your model. In this case, I'm just going to say hideFromIndex. If I jump back now into our Book resource and refresh,

In this case, I'm just going to say hideFromIndex. If I jump back now into our Book resource and refresh, note that there is no longer a pages field. Now, bear in mind our filter is still available. I can still select only books with certain amounts of pages. So this filterable method is still taking effect, but the hideFromIndex will remove the value from being displayed. It's a good thing to keep in mind. That being the case, I have a much cleaner index, and yet if I click into the resource itself to view an individual Book,

That being the case, I have a much cleaner index, and yet if I click into the resource itself to view an individual Book, I can still see the number of pages. If I click to edit a Book, I can still see the number of pages. Whilst we're in the edit view, there are a couple of methods I want to play with. All of these fields are actually required. I cannot create a Book without providing a title, the number of pages, and the number of copies I have available. If that is the case in your project, you can chain a required method onto the end of these fields.

If that is the case in your project, you can chain a required method onto the end of these fields. So I'll do that now. And if you do that and jump back into the browser, note that we now have this little star, which indicates to us as we're creating a new resource that these fields are required. They're essential. We cannot go without them. Another method I'd like to add to the form is help.

We cannot go without them. Another method I'd like to add to the form is help. If you take a look at copies, it's not very obvious what that actually means on a form. Sure, when we're in the index or when we're on the detail route, it makes a lot of sense. We understand what copies means. But when we're in this view, we could do with a bit more information. Would you believe it? There's a method called help.

Would you believe it? There's a method called help. So on copies, I can chain a new method called help, and you pass help text that will give you the information needed in order to understand what the field is for. So I'll say the total number of copies of this book that the library owns. And once I've done that, if I jump back into Nova once more, you can see this help text appears underneath the field when editing. But if I go into the index, it just says copies.

you can see this help text appears underneath the field when editing. But if I go into the index, it just says copies. If I go into the detail route, it just says copies. Now that we're starting to get a few methods chained to each of these fields, I'm going to split them down onto separate lines. I find that that makes things clean and easy to read. And you'll often find with fields, you're going to add a lot of them for each resource. So I like to add a space between each field as well. I think that gives a visual distinction.

So I like to add a space between each field as well. I think that gives a visual distinction. It makes it easy to scan with your eyes. But, yeah, you're starting to get a feel for how a field is put together. You start with the type of field that makes sense for your database column. In our case, we've looked at ID. We've looked at text. We've looked at number. And then once you define the field, you start chaining methods on to customize that experience in Nova.

And then once you define the field, you start chaining methods on to customize that experience in Nova. So you might add sortable in order to allow you to sort on the index. You might add filterable, which will automatically add an appropriate filter for that field so that you can narrow down the result set. You might hide from the index or hide from detail or use the acceptOnForms method to make sure that some fields only show in certain circumstances. Perhaps you use the required method to make a field look required.

to make sure that some fields only show in certain circumstances. Perhaps you use the required method to make a field look required to give the user insight into what needs to take place. Or you might use the help method in order to provide a little more information when you're building those resources out. Well, so far, we've played with a few different field types, but we've really only scratched the surface of the field types available in Nova. Nova provides a field type for almost any use case you can think of. So let's have a bit of fun in our next episode.

Nova provides a field type for almost any use case you can think of. So let's have a bit of fun in our next episode. I'm going to take the field types available and start adding them to our resources where it makes sense so you can get a feel for some of the options available to you in your applications.