Now, we're going to be moving on to a filament table column. Now, custom columns are probably one of the more popular custom components to make in filament, aside from things like form fields. And they are actually very similar to an infolist entry in the way that they usually render read-only information. So, let's generate our table column with artisan. So, php artisan make:table column. And it's going to ask us for the name of the column. I'm going to stick with the example of colors here.

And it's going to ask us for the name of the column. I'm going to stick with the example of colors here. So, I'm going to use color column. Again, we do have a color column in the filament core. But let's use our own one here. So, color column. And of course, this has generated both a class, color column, and our view, so color column blade. Now, you might notice that this is quite similar to how an infolist entry is generated with this getState in the view. But this one doesn't have the entry wrapper dynamic component in it.

to how an infolist entry is generated with this getState in the view. But this one doesn't have the entry wrapper dynamic component in it because we don't need to render any label within this view. That's handled by the table itself. So, let's go into our table. And as you can see, each of the color codes for these users has been output. Now, this has been output by this echo statement here. We can access the state. We can also access things like the current record. So, for example, if we dump getRecord,

We can also access things like the current record. So, for example, if we dump getRecord, you'll now see that we have access to the entire model instance for that table row. Let's remove that again. And similar to our infolist entry, let's make this a block of color. So, div, class, h5, width 5. And the style is going to be background-color and then the state. As you can see, our color's output nicely. Let's add a little bit of padding.

As you can see, our color's output nicely. Let's add a little bit of padding. So, padding x4, padding y3. And that looks quite aligned. And let's make it rounded as well. So, rounded. Cool. So, as you can tell, this is very similar to an infolist entry. The difference is that with a table column,

it's only going to be rendered once within the infolist. Whereas with a table column, the object is going to be shared between each row in the table. However, when we render each row, we are passing a different record to that table column object. And that then allows the table column to extract the color from that record for the row and output it. Now, we could go ahead and add some other features to the table column. For example, the width method that we added to the infolist entry and the tooltip that we added there as well.

For example, the width method that we added to the infolist entry and the tooltip that we added there as well. However, there is another interesting feature with table columns. You can make them editable within the table. So, for example, you can use a text input column to make this text editable. I'll show you an example. So, let's replace this with text input column. I'm going to refresh, and this has replaced the static text with an input. If I change this to now two, and I click outside, and now I refresh,

If I change this to now two, and I click outside, and now I refresh, it's actually saved that straight to the database. So, what I'm going to attempt here is actually making this color editable, probably not with a JavaScript library or anything, but just a standard HTML color input. So, let's replace in our view this with our input. So, input type="color". And we should be using AlpineJS to build these sorts of editable columns. So, let's make an Alpine component around here.

And we should be using AlpineJS to build these sorts of editable columns. So, let's make an Alpine component around here. So, div and define x-data. So, here x-data needs to be storing a few things, but the main one is going to be the state of the color. And the state is our hex code in this case. So, we can use state as a property and pass in getState. Now, I'm using the JS directive, so this string is escaped properly. Now, I'm going to get rid of that first div, and I'm actually going to x-model this input to the state.

Now, I'm going to get rid of that first div, and I'm actually going to x-model this input to the state. Now, similar to a form field, if the state changes, we want the backend to be notified and the new state to be sent there. So, let's refresh here. As you can see, there is now an input, and it's been prefilled with each of the User's colors, and that's because the default value for this state property is getState. But this isn't a wire:entangle like we had in the form field. We actually need to send the new state to the backend manually.

But this isn't a wire entangle like we had in the form field. We actually need to send the new state to the backend manually using a Livewire method. Now, the reason for this is because you can only wire entangle to an actual public property in Livewire. But since tables are rendered without any public properties like that, we actually need to send it straight to a method in the table builder, and the table builder will update and save it, and then re-render the table. So, we need a way to listen for when the state gets updated.

and then re-render the table. So, we need a way to listen for when the state gets updated. So, we could use something like x-on:change here in the markup, but we can probably use a watcher for this in Alpine. Let's use x-init and register a watcher. So, you can register a watcher with the watch magic, and you're going to pass in the name of the property you're watching, so state in this case. And then the second argument is going to be a function that runs each time the state is updated.

And then the second argument is going to be a function that runs each time the state is updated. So, in this case, we can just console.log the state. Let's now inspect the console. And when I pick a new color, it's going to trigger the watcher and console.log. Now, we don't want to be sending all of these to the back end. We only want to be sending them when the user's finished with the component. Now, to do that, we can use x-model.lazy.

when the user's finished with the component. Now, to do that, we can use x-model.lazy. So, let's pass lazy here. And now, when I use the color picker, it's only going to send me that console.log when I've finished and clicked out of it. Great. So, this is the perfect time that we can now send something over the wire to Livewire for it to be saved. The first thing we need to do is use wire,

to Livewire for it to be saved. The first thing we need to do is use $wire, and the name of the method is going to be called updateTableColumnState. And the first argument to this is going to be the name of the column we're updating. So, I'm going to use getName again, and getName is a public getter on the Column class.

and I'm going to pass in getName. And getName is a public getter on the Column class. And this has Name trait. So, we can call it from the colorColumn Blade. So, we've now got a name as the first argument. The second argument is going to be the key of the record that we're going to be updating. So, this is actually exposed to all table column views as recordKey as a variable. And the third is going to be the actual new state.

as recordKey as a variable. And the third is going to be the actual new state that we want to update this column to. So, we can just pass in state here. The last thing we need to do is tell the column object that it can be edited. So, let's implement the editable interface from filament tables, columns, contracts, editable. And this interface has two methods. So, the first one is validate,

And this interface has two methods. So, the first one is validate, and the second one is updateState. And we can get access to those two methods using some traits. So, the first trait is going to be canBeValidated from Filament tables. And the second one is going to be canUpdateState also from the same namespace. Let's check our browser. And when I pick a new color,

Let's check our browser. And when I pick a new color, that should now be sent to Livewire. And when I refresh, the new color has been persisted in the database.