Now we've used the AssetManager to register a JavaScript file. And that JavaScript file is loaded by the filament scripts directive onto every page. Now we can see that the iro.js file that we registered is in the form. It's also in the table. And it's in the info list. Now we don't actually use this file on the table or the info list. So filament has a strategy to only require it when we're actually using it. This strategy uses a library called AsyncAlpine. Now AsyncAlpine is a tool that allows you to load the JavaScript associated with an Alpine component dynamically only when that Alpine component is being used.

Now AsyncAlpine is a tool that allows you to load the JavaScript associated with an Alpine component dynamically only when that Alpine component is being used. So instead of requiring the iro.js file on every single page, AsyncAlpine is able to request that file only when we use it. You can skip the install AsyncAlpine step because AsyncAlpine is included in every filament installation. This is how you define an AsyncAlpine component. This is how we're going to be restructuring our compiled JavaScript file to return a function from it. We're then going to use the ax.load directives to tell AsyncAlpine where to find that JavaScript file. And then it's going to handle the rest and load that whenever we're going to use it. So let's go ahead and refactor our JavaScript to use this function syntax instead.

And then it's going to handle the rest and load that whenever we're going to use it. So let's go ahead and refactor our JavaScript to use this function syntax instead. Now we have our color picker here and all of the JavaScript currently is in the HTML. We can now move this to the JavaScript file. So let's open the JavaScript file in iro.js. And we can keep this import here, but we don't need the window.iro anymore because we're going to be using this dependency within the function itself. So let's copy this. export default is going to be used to then return that function when the script is required. And the function name is going to be what we're going to be using in the view.

Export default is going to be used to then return that function when the script is required. And the function name is going to be what we're going to be using in the view. So I'm going to call it colorPicker. Now this parameter here is going to be passed through as the parameter to the x-data function here. And I'm going to be using an object. And that will allow us to pass through the entangle of the state and also the width from Blade. So let's add those two parameters to this colorPicker function. So the first is going to be state and the second one is going to be width. Now we can use those two inside this return function here. So state and that's shorthand for assigning a state property with the value of this state variable.

Now we can use those two inside this return function here. So state and that's shorthand for assigning a state property with the value of this state variable. So we can actually make that shorthand. Now we shouldn't really need to add width as a property on our Alpine component because we're just going to reference it statically inside this init method. So let's get rid of that. And copy exactly what we have here in the x-init. Remove the x-init and move it into this init function. Now we still have some Blade here, so I'm going to refactor this to use JavaScript. And we're going to be conditionally merging an object into this object if the width has been passed in.

Now we still have some Blade here, so I'm going to refactor this to use JavaScript. And we're going to be conditionally merging an object into this object if the width has been passed in. So ... to merge. And I'm going to open some brackets. And here we're going to do a ternary. So if the width is defined, then we're going to merge in a new object with the width property set. And this is the same shorthand that we're using here. And if not, we're going to be merging in an empty object. So the iro uses the default width. Now we can get rid of this.

So the iro uses the default width. Now we can get rid of this. I'm just going to copy this to our clipboard so we can pass it in. When we're going to be initializing our colorPicker, instead of passing the object directly to xstate, we want to be calling our colorPicker function and passing it in. So we've got our state passed in, and we want to pass in the width as well. We're using the js directive to make sure everything's escaped properly. We do need to fix the alpine component a little bit to make sure that it works with this new function-based syntax of declaring the component object.

We do need to fix the alpine component a little bit to make sure that it works with this new function-based syntax of declaring the component object. So, for example, state needs to be transformed to this.state since it's a property on the object. But width can stay as it is because we're not actually setting this as a property. It's still being passed in as a variable. We do want to fix this refs here to use this.refs instead. As refs, it's a magic that belongs on the object, and it's not a variable that we can use globally. Finally, we need to actually tell AsyncAlpine where to find this color picker. So what we can do is copy all of this axload into here, along with this xignore. At the time of recording, AsyncAlpine as a package requires this xignore to be able to load things.

So what we can do is copy all of this axload into here, along with this xignore. At the time of recording, AsyncAlpine as a package requires this xignore to be able to load things. Now, since filament's going to be handling where this JavaScript file's going to be compiled, we can dynamically reference it using the filament facade. So there is actually a filament asset facade that we can use, so filament asset. That's been imported up here if you're using phpStorm. And you can use the getAlpineComponentSource method to fetch the URL of a defined alpine component. Now, we haven't actually defined it yet, so let's do that. So in the toolkit service provider, we can convert this jsMake into alpineComponentMake, and this is a completely separate type of asset that we're registering here.

So in the ToolkitServiceProvider, we can convert this jsMake into alpineComponentMake, and this is a completely separate type of asset that we're registering here. Now, I'm going to call it colorPicker, and the path to it is actually going to be exactly the same. We don't need to change that. What we do need to do is fix our build script a little bit, because currently we're building for the platform browser, and since we're using AsyncAlpine, we actually need to build for platform neutral. We can compile this using the bin build script, and finally publish our assets inside our project. And as you can see, we now have our public.js-stanharen-filament-toolkit-components directory with our colorPicker.js.

And as you can see, we now have our public.js-stanharen-filament-toolkit-components directory with our color picker js. You can also see all the other internal filament components that have been registered in the same way using AsyncAlpine. Finally, in the view, we can generate a URL to this asset by passing in the name of the asset, so we're going to be passing in color picker as the first parameter, and then the package that the asset belongs to, so stanharen-filament-toolkit, as the second parameter. Now, when we visit the browser, I can reload, and you can see that all of our color pickers still work,

Now, when we visit the browser, I can reload, and you can see that all of our color pickers still work, and they're still emitting Livewire requests. However, instead of iro.js, we now have our colorPicker.js, which is being built from this iro.js file here. And when I reload the table, for example, we now don't have an iro.js listed in the Network tab. Same when we visit the InfoList, we don't have iro.js either. Now, you may be wondering, how well does this AsyncAlpine library work with some of the Livewire features?

Now, you may be wondering, how well does this AsyncAlpine library work with some of the Livewire features? And in my experience, it does work very well. For instance, if you're adding a form component onto the page in a Livewire request that wasn't previously on the page before, AsyncAlpine will load the JavaScript file that's associated with it. If you have a loop that contains multiple color pickers, and you add a new item to the loop, that color picker.js is only going to be loaded once, and it's then going to be used again and again.

that color picker.js is only going to be loaded once, and it's then going to be used again and again for however many color pickers you're using on the page. If you're interested in the implementation of some other AsyncAlpine components, have a look in the Filament Core, because we have many different ones to check out. For example, if we go Vendor, Resources, JS, Select, you can see the same export default function, and this is being used to render the Select. We can also have a look at the DatePicker, which is also exporting a default function.

We can also have a look at the DatePicker, which is also exporting a default function. And if you're interested in the views for this, DatePickerBlade contains our AXLoad directive in the same way. We're using our getAlpineComponentSource. Everything that we do inside the Filament Core uses exactly the same tooling that we're giving you to build custom components.