Episode Details

Hey everybody, right now. It is pouring rain outside my window in my office and I just love that so much. I love the sound. It makes me feel like I'm in a cozy shelter like a fort when your kid anyway. So I titled this new design pattern the plug-in pattern so this may exist or not or whatever.

But basically it's something that I've been pondering about this new way of writing code that I want to move the live work or two. And I think it'll be interesting and useful for really any project but probably more open source projects, who knows. So the idea is I'm actually coming up with this off the cuff.

So it's going to sound like like it's well thought out but it's not the idea. That all or as much functionality as you can for a core four core features inside of a plug-in or package. You should write as plug-ins for for that package what I mean by that is so Livewire offers all these directives.

So wire: click while your colon pole, you know, anything like that. I eventually would like to allow the user to register their own hooks so that you could make wire: funada Ledoux. I don't know and and the syntax might be something like Livewire dot directive register the name and then some call back or something like that.

Well, what if. Even the internal hooks. Sorry the internal directives what if they used the exact same system so that if your Source diving you're not, you know, it's not like I guess userland and whatever the opposite of that is core core software land feels. The same so an example of this in laravel would be lets say so when you register a custom blade directive and laravel.

So blade directive is the at whatever so a diff is a blade directive if you want to register a custom one, it's Blade the blade facade:: directive you pass in a name and then you pass in a callback that you know that you return the rendered HTML from when you Source dive laravel, you'll find it's not as simple like you don't find any place in laravel core that all the.

Are registered that way they're inside of these compiler traits and they're like the it or the like let's say the unless directive is a method called compiled unless and there's magic happening and do that which I think you know isn't a great experience as a source diver. Maybe it makes sense for somebody writing the laravel framework, but how cool would it be if even the core laravel?

Directives were where actual you know, custom register directed. So somewhere in their vocal cords, he played:: directive so this this could apply to so many different areas of Livewire the obvious one. The one that I the one that I sort of came to this with was custom directives, but I start to think about it how I could apply it in all sorts of different ways.

So there's custom directives. There's custom actual blade directives inside Livewire that I'd like to offer where you can register blade directives that only. Run within a live wire request. So you're not, you know messing with the global blade namespace. So there's actually only one right now that exists the at this directive for JavaScript stuff.

But but I want to make those extensible and actual plugins like right now. I have a trait called use pagination. I think that basically makes a Livewire component all. It adds functionality for for pagination. It kind of hijacks levels default pagination. So maybe there's a way that I could make this more extensible and use it in the core.

Another thought I had was data tables that's going to be something that a really common use case for Livewire at some point. I really want to sink my teeth into it and make a data tables implementation like a first-class API that you can use to make data tables in your apps with Livewire. And I think this is the kind of thing that maybe I wouldn't want in core.

Maybe I would want it to be like a composer require Livewire / data tables and it all just kind of works. So anyway, this is