Bright Ideas

Filament Wizard form component: https://filamentphp.com/docs/3.x/forms/layout/wizard
Ralph’s onboarding plugin: https://filamentphp.com/plugins/ralphjsmit-onboarding-manager-pro
Guava’s tutorials plugin: https://filamentphp.com/plugins/guava-tutorials
Jibay’s tour plugin (another alternative to Ralph’s and Guava’s for onboarding): https://filamentphp.com/plugins/jibay-mcs-tour
Advising App™ by Canyon GBS™ (open source Filament app): https://github.com/canyongbs/advisingapp
Dan’s Livewire partial rendering discussion thread: https://github.com/livewire/livewire/discussions/7903
Lightning CSS: https://lightningcss.dev
Tailwind v4 initial blog post: https://tailwindcss.com/blog/tailwindcss-v4-alpha

Thank you to our Filament Partner, Kirschbaum Development Group for their support of Bright Ideas! Find more about them here: https://kirschbaumdevelopment.com/solutions/filament-development

Follow us on Twitter!
Filament: https://twitter.com/filamentphp
Alex: https://twitter.com/alexandersix_
Dan: https://twitter.com/danjharrin

Join the Filament Discord server: https://discord.gg/filament

Have questions, topics, or people you’d like us to talk about in a future episode? Reach out to us on Twitter or in the Filament Discord server with your ideas!

Creators & Guests

Host
Alex Six
Senior Software Engineer at Zillow, head of DevRel for Filament.
Host
Dan Harrin
Lead developer at Kirschbaum, creator of Filament.

What is Bright Ideas?

Join Dan and Alex on 'Bright Ideas' for all things Filament! From product updates to community news, we've got you covered.

Alex Six:

Hello, everybody. Welcome to Bright Ideas. It's a Filament podcast that we're gonna be doing once a month, maybe more than once a month. I am your host, Alex here with our other host, Dan. We're both part of the Filament core team.

Alex Six:

Dan is the brains behind the operation. So today, we've got a lot of really exciting updates in the Filament world for v4 , some exciting v4 news. So we'll dive into that. But before we do, I wanna just take a couple seconds and say a big thank you to Kirschbaum Development Group for being, a Filament partner and helping make this show possible.

Dan Harrin:

Thank you to Kirschbaum for sponsoring my work on Filament every day. I wouldn't be able to spend so much time in open source without them, so it's really appreciated. And thank you for joining us on our podcast. We're just starting out, so hopefully, you enjoy what we have to say and hearing some few insights on we're doing in the Filament world. So, Alex, anything new with you?

Alex Six:

Yeah. I, you know, always always work in Filament stuff. Right now, I'm actually working on building an onboarding form for a a couple friends of mine who have an application where their back end, we're porting it over to Filament. And one of the things that we wanted to to figure out is how do we take this very large complex data entry that is kind of the barrier to entry for new clients, new users coming in the system? How do we take that and simplify it so that people can more easily get into the system?

Alex Six:

Right? Because that's the whole there's a whole idea behind the SaaS product. You want people to be able to onboard onto your product easily without multistep wizard. I I have somehow ducked around using the wizard for, I mean, however long, I've been using Filament at this point since version 2, at least. It's been it's been wild.

Alex Six:

It's been really, really nice to be able to logically break up these different steps, and then, you know, shove repeaters and builders inside of each individual step. So we can have this dynamic data that these users are gonna need without having to have them email us a giant Excel spreadsheet of all the things they need to put into the app. So Mhmm. That's been pretty fun. I'm I've been excited to to use that.

Alex Six:

It's definitely interesting building this kind of Filament application where it's Yeah. Very form heavy.

Dan Harrin:

So I guess you're outside of the panel builder, and you're using the form builder in the in a Livewire component, or are you to are you trying to attempt this inside the panel builder?

Alex Six:

So we're doing it inside the panel builder. So we have a panel that is for just general administration of the app. And we decided, since we already have that there, let's just go ahead and, tack on this onboarding form. Because what's gonna end up happening is the onboarding step happens in between when a user signs up and then when they get access to the application. Like, they could theoretically sign up and jump into the application.

Alex Six:

They're just gonna see a bunch of empty states, which isn't super helpful in this very specific case. So what we ended up doing is the user signs up. You know, they pay through I think we're paying through Stripe. And then they get redirected to this onboarding form, which is just it's it's one page in its own dedicated panel, so you can't actually access the admin panel. Obviously, if you're not an admin, they go through the onboarding flow, the resources get created.

Alex Six:

So we're we're hijacking the save method on the form. We're we're saving, like, an onboarding record just so we have record of what they put in in case things change down the line or we have a bug. But then the logic actually goes out, and it creates all the different resources. And then we kick them back to the actual view and inertia application that they would interact with day to day. So it's a it's a little bit of a strange workflow, but overall, it's actually it's really smooth.

Alex Six:

I'm I'm kinda surprised and pleasantly happy with how it's worked out. I think it helps that the styling of the inertia app with the main app that the users are gonna, interact with Looks similar enough to a Filament admin panel, but it's not this really jarring jump. The only thing I had to do was move the sidebar to the top, but there's no options. There's no other pages to go to other than this form. So Yeah.

Alex Six:

It's not like Yeah.

Dan Harrin:

Yeah. Actually, I probably should shout out a couple of plugin here because you might be able to use one of them at least. There's the Onboarding Pro plugin from Ralph, and that allows you to do onboarding wizards. And I think that is also tracking steps for you, so say the user is partway through the onboarding process, it can land you back on that step. And another one that might not be relevant to you, but could be relevant to other people who are doing this within a panel is the Guava tutorials plugin, and that would allow you to basically have little pop ups of little UI elements in the panel, and allow these to basically, like, click through each step in the tutorial, and it will highlight a different path of the UI and and choose into it.

Dan Harrin:

So, yeah, if you're I know you said you're using view and inertia for the main app, but if you had, like, a main app infillment, then that's something you could use there.

Alex Six:

Yeah. I would be so curious to see the percentage of people that are building their entire application in Filament. I feel like I see a lot on Twitter, but I also feel like you and I spin in very Filament heavy circles on Twitter, so it's probably skewed way off to the to one end. But I would be really curious to to see. Hit us up on Twitter if you're building your full app on on top of Filament.

Dan Harrin:

If you're if you're brave enough.

Alex Six:

Yeah. If you're if you're brave enough to deal with all of Dan's breaking changes.

Dan Harrin:

Don't talk about those.

Alex Six:

So, what what's what's new in your world? I mean, obviously, v4, but anything else going on Yeah.

Dan Harrin:

Other than that? Yeah. So at work, we are building a a large filament app that also happens to be open source. And the client is looking to onboard the first users in the next few weeks. So we're we're, finishing up and getting ready to properly deploy it.

Dan Harrin:

So, yeah, that's been that's been good to see, like, how the solution scales as well. And introducing, like, Octane to handle some stuff. A lot of the features that you've seen in Finland 3.3.1 and 3.2 have originated from this app. So it's really great to be able to work on it and contribute back.

Alex Six:

How long have you been working on that app at this point? It feels like it's been a a bit.

Dan Harrin:

I think I've been on it since August or September, but I think the app was created in, July. Wow. So this is 2023. Yeah. But it's now turned into 3 apps instead of 1.

Alex Six:

As it is.

Dan Harrin:

Yeah. As it as it as it gets bigger and splits up. But, yeah, each each app is using Filament independently, and at some point, they would all communicate.

Alex Six:

And it's open source too.

Dan Harrin:

It is open source too, and it's been featured on, the Laravel Daily channels, and some code review videos as well.

Alex Six:

Oh, man. That's stressful.

Dan Harrin:

Yeah. Yeah. Having your code analyzed on on YouTube.

Alex Six:

Yeah. No kidding.

Dan Harrin:

Yeah. But yeah. No. It's it's nice to see how fast we've been able to move because we have hundreds of pages, as far as I know. Navigating between all those prompted sub navigation and clusters and stuff like that, and also making that faster with caching, like com like page caching and stuff so that the pages don't need to be discovered each time you request.

Alex Six:

Oh, interesting.

Dan Harrin:

And also optimizing the Octane integration that we already had to make sure that the panels weren't being booted each time a request happens, and that all happened once. There wasn't any leakage for 2 requests as well. Right.

Alex Six:

And that's all come out in in v 3. Right?

Dan Harrin:

Yeah. Yeah. Yeah. That's that's all been that's all that's all v 3 stuff. But, yeah, we're working on we start to work on v 4.

Dan Harrin:

I had a call with Sap last week, and I think he can tell when I'm excited because I I just call him and info dump my ideas on him. But, basically, we are we've got a really strong direction now, and that's something I kinda wanna talk about today. It's a bit of a paradigm shift, and it will hopefully make things better while also minimizing the amount that you need to change your code to make this work from version 3.

Alex Six:

So Breaking changes, you're saying?

Dan Harrin:

Minimal breaking changes. I don't like to say the words, but, yeah, minimal hopefully, minimal breaking changes if I get the layer correct that sits between what we're trying to achieve and and this.

Alex Six:

That would be awesome.

Dan Harrin:

So the whole idea is that we are trying to unify all of the packages so that they can be combined in ways that were much more difficult to do before and then viewers can't see Alex cheering, but Alex has got his arms up.

Alex Six:

I'm so excited. I'm so excited for this change.

Dan Harrin:

So I'll just give you a little bit of a rundown. So you wanted to have, a form, and an info list, and a widget, and a table all in one view that's absolutely possible. In the view you would basically define some divs or some elements and output each individual component inside those elements. Now, that's all separate lines of blade that output the different components, and that's good if you are building an app in your own Livewire components and you're not using the panel builder. But one thing we found is that if people want to change the layout of the panel builder pages, they actually have to then publish the view of each page, like, copy it into their app, point the page class to the new view, and then change things around.

Dan Harrin:

And that's fine, but it and choose a new file in the code base that you don't really need because you already have a file that can manage how a a page, is structured. So what we're trying to do is we're actually trying to make, like, a page schema where you can override the content of a page from one method in the page class without having to publish the view. Now, if you imagine this, it might be a little bit like how you use layout components inside forms, because you can define, like, which fields might be in a section, which fields might be in a grid, which filter in a wizard as you mentioned. And those layout components could be useful outside of the form builder on the info lists individually, like, you might want a section which contains a form and an info list. You might want a section that contains widgets or tables for a relation manager.

Dan Harrin:

You wanna change where a relation manager has been output on the page, maybe you want it on the top above the form. Maybe you want I mean, this is possible already with relation groups. Maybe you want some relation managers in one group, in a tab, others without a tab. We're also trying to make it easier to be able to do that.

Alex Six:

Is that within the scope of your resource, or is this only for custom pages?

Dan Harrin:

So this is within resource pages.

Alex Six:

Okay.

Dan Harrin:

So, obviously, you've got you've got your resource, and your resource is gonna remain the place that you define your film and your table. But then resources have the page classes. Right? So each page class corresponds to a different page for that resource, and you should be able to override the content. So, like, say you want to change how the relation manager that were shown on an edit page, you could override the content method on an edit page, and then change the order of which the components are, and that should allow you to then do that without creating an extra file.

Dan Harrin:

So, yeah, this isn't just custom pages. This actually may be useful for built in pages and minimizing the amount of code you have to write to override those, because customizability is what we're trying to strive for here with Filament all the time, and making that easier is something that we try and take a lot of care with.

Alex Six:

So when we're combining these different elements from the different packages, right, tables, forms, info lists, is the plan to put them all at this kind of top level package, or is a a text field still gonna be in the forms package and, like, a text column sort of being in the tables package?

Dan Harrin:

Yeah. So I've started refactoring this already. Essentially, what's gonna happen is we will have a new package. The moment the name of the package is schema, but you won't really install schema on its own. Schema will be installed by the forms package or the Infillis package or the widgets package.

Dan Harrin:

Those packages then build on top of the base schema components. So schema will contain the layout components. So it'll contain the section grid group, field set, wizard, tabs. All of those different layout components will be in the schema package, and any of the forms in full list widgets can use those components. All of the base components that we extend for each of the different packages also belong in the schema package, and that's kind of what ties it all together.

Dan Harrin:

But, yeah, like, that is the abstraction layer that we've gone with at the moment, and it's really improving the maintainability of the components as well for us because, currently, we have duplicate classes for infilless and forms for the different layout components when they're essentially the same they're the same sort of code, really, in the view and the class. So we'll be able to have one class that controls both of those.

Alex Six:

That makes sense. And then I have to ask. So currently, there are 5,000,000 different places that I can import an action from. Are we are we are we roping actions in on this too? Because then I might fall out of my chair.

Alex Six:

I'll be so

Dan Harrin:

happy. Yeah. Yeah. So actions is one that we've we've heard a lot, and, historically, I've always said that it would be very difficult slash impossible to do that, because each action has its own features and interacts with the packages in their own way. For example, like, actions in the form builder can access the values of fields, whereas actions in the Infinix component don't have fields, so it kinda makes it a little bit more tricky from us.

Dan Harrin:

Also, table actions have access to, like, deselect records in the table or select them. Bulk actions are completely different, but we are trying to unify these at the same time, so that you'll be able to use the same action plus within forms, info lists, and actions stand alone. Because the goal is to unify forms and info list into one schema. So it wouldn't really make sense to them, force the user to choose between form action or info list action or normal action kind of makes sense to have them all combined. So that's what we're gonna go for.

Dan Harrin:

So, yeah, hopefully, that makes you and some people happy, but I'm not promising that every action class is gonna be like that, because as I said, like, the table actions I haven't looked at yet, and they might be a little bit too too much to extract out into that base plus.

Alex Six:

Yeah. But the rows and the bulk actions that Mhmm. They're very different.

Dan Harrin:

I think definitely the definitely the bulk actions, I don't think are gonna change. Then there's a possibility that the the normal actions in tables might, especially the header actions. I think there's a possibility that header actions might, but the question there is do you want a different action plus between header actions and row actions? Because at the moment it's the same one, so does that make sense? Like, then importing might make it a little bit more difficult to import because they have to use aliases and

Alex Six:

Right.

Dan Harrin:

Yeah. It's just a lot to think about.

Alex Six:

Yeah. I definitely see that. I'm also on the other side of the fence where we have section header actions too. So if if a generic action, so to speak, could be in the header of a section, you know, why wouldn't I also expect That's

Dan Harrin:

very true. Yeah.

Alex Six:

The header of a table. Yeah.

Dan Harrin:

But I guess I guess table header actions can also control which records are selected, and they can access things like the table instance if they're a table action. But there might be some ways that we can inject that sort of thing from the table conditionally. Another thing so now we'll probably get get into the new features we can introduce with this. One of them is something I proposed in the Livewire repository a few weeks back, and that is partial rendering. So I made a proposal in the discussion section of Livewire, and I propose that you should be able to render part of a Livewire component independently from the rest of it.

Dan Harrin:

So this isn't just sending part of the HTML over the wire to get replaced. This is only making blade render the part that you need it to. This is especially important if you are calling getter methods or computer properties from your LiveWire views because if you use a heavy getter or a heavy computed property in one part of the view and you're not even rendering it, then that is still gonna get called if you render the entire view. But what we want to do is make it so that you should need to call those get us in computer properties if you're not using the results of them. And that would require a separate blade view or some sort of preprocessing.

Dan Harrin:

Now we have this schema, which is a layer on top of views at the moment. So in Filament, we might choose to implement our own version of that proposal and apply it to schema components. So when you edit a form field, you might want to reload a different component in the schema. You might want to reload a different form field or maybe an info list component or maybe even a table. Now you don't wanna have to render the entire schema.

Dan Harrin:

You could just select which components to render and only the HTML for those components get rendered. And it's very easy for us then to control which components we're rendering because we control the schema anyway. We control exactly when a component renders and we can extract a component from the schema, get the object for it, and render it, and then set it to Livewire, and then replace it on the front end. So, hopefully, that will then allow us to do that sort of thing. Because also in the past, we've had people who want to make certain back end interactions, but don't want the entire view to refresh, especially if it's like a huge form or even a table.

Dan Harrin:

We want to we want to minimize that. So

Alex Six:

So is this then an extension onto the the live method that is on, say, a form field?

Dan Harrin:

That's that's one of the implementations we could do. Yeah. So a form field could define a live method with the partials, the updates. One thing that we need to be careful about there is deferred requests and batch requests. So because LiveWire might batch multiple live updates in one request, or it might defer live updates on blur, for example, that could mean that we then have to choose which partials get rendered based on multiple components, which could get a little bit tricky and maybe if one component gets updated that needs the entire blade view to refresh and one only needs one component to refresh, then we'd have to ignore the fact that one component needs to refresh a tiny view and render the whole thing anyway because it's all in the same request.

Dan Harrin:

Right? So I think that there are definitely some use cases where you could only end up rendering 1 component at a time.

Alex Six:

Interesting.

Dan Harrin:

I also think that, like, from actions, like, if you if you run an action and you know for certain that only a certain part of the view is being affected by the action, then you could tell the action somehow to only render that part of the view instead of the entire thing.

Alex Six:

Just thinking about, you know, fill up an apps that I have worked on in the past and even I'm currently working on, Once those pages start getting large, I think of, you know, we have a couple builders, a repeaters on there, and we're we're putting all sorts of form fields in there. Those live updates get not slow necessarily, but they definitely don't feel crappy.

Dan Harrin:

They do. They do get slow. Yeah. Especially when you have, like, tons of repeater items or boiler items, and that's also something we could improve because we could say that when you add a new repeater item, only render the view for a new repeater item and then add it onto the existing repeater. I'm not sure how viable that is, but hopefully that's something we could then work out how to do.

Dan Harrin:

Same for, like, deleting. We shouldn't need to render the entire view just as late an item. We should be able to kind of remove that item from the from the view with JavaScript. But, yeah, like, also batch requests could be a little bit tricky there. But

Alex Six:

Yeah. I'm excited for the performance implications of this one. I think that's gonna be a massive improvement for for certain workflows, like the one I'm working on now.

Dan Harrin:

Yeah. I know. So wizards, as you're using, they actually have to render all the steps at once because the current wizard step is stored in an Alpine property. And when you switch between steps, you are calling you're making a request to Livewire to validate, but then you're actually switching the steps in Alpine and not Livewire because there's no, like, Livewire property that is tied to that wizard. So one thing that could improve is we only render the next step.

Dan Harrin:

That that could be another form of partial rendering. So it's not all about the live methods or having an API for all components at once to partially render. It's also about Filament making smart decisions about what to render on your behalf and giving ourselves, like, a set of tools to be able to do that.

Alex Six:

Yeah. Love it. So what my my one last question about that and you may have said this already, and I'm just confusing it with the the combined schemas we talked about. Is this something that would be available for just the panel, or is this something that we're planning on pushing down into, like, the forms package or the tables package?

Dan Harrin:

I definitely want it to be available inside the form package, table package, because I feel like people are using those packages in the very similar way to how we use them in the panel builder anyway. Mhmm. I think that's definitely gonna be a world where people are gonna be using both. Right? They're gonna be adding a form on its own, and they wanna define a form just how it was defined in v3 .

Dan Harrin:

So we want to add some sort of backwards compatibility to allow them to do that. But if they want to then add an Infosys component inside that form, we shouldn't be up we shouldn't need to stop them. Right? That's already a feature. So, yeah, hopefully, we can then add this layer into people's normal Livewire components, allow them allow them to use it, and also allow them to use the partial rendering features and and everything.

Dan Harrin:

Also a new component we want to introduce is a table that runs on static data.

Alex Six:

Oh, man. I think I I I can hear it now. The sounds of people falling out of their chairs

Dan Harrin:

and off of their

Alex Six:

beds as they're listening to this. They're so excited.

Dan Harrin:

So the the table builder currently works with Eloquent, and all of the features that we have tie in very closely with Eloquent, like the fill, the filters, the columns, the actions, they all work with specific eloquent records and they modify the eloquent query. Now a lot of the time people don't have the data coming from eloquent, maybe they have their own queries, maybe they have, like, a cached set of data, maybe they have an API they want to call. And one thing we want to investigate is introducing a new table component, not changing the existing one, but introducing a new one that allows you to use static data with a lot of the same APIs, but it's probably gonna be a little bit more limited to what we have in the table builder because a lot of the features that we have are geared very much towards usage with adequate models. And one thing we don't want to do is make it more difficult to use the table builder with Adequate models, because I feel like 90% of tables are built with Adequate, But we don't wanna block people off from making tables that look very similar if they have static data.

Dan Harrin:

So that's something we want to do. How that will probably work is we will have many of the same UI components, but it will not have any of the logic to change what data is being rendered. So potentially we have column objects just like we do at the moment, but we also have a method that returns a function to get the data on the table, and that function can accept the current columns made that's being sorted. It might accept the search value of the table. It might accept the filter form data, and then you can then interpret that data that's coming from the UI and customize the query or the API call that you're sending and then return back to fill them in exactly the data you want to render.

Dan Harrin:

So that's kind of put into your hands. It's less magic. I feel like that's the direction we want to go with that. And that will probably be part of the table builder as a component that's available in schema. So that's another reason to use a schema because then you can use that sort of component.

Alex Six:

Yeah. I think the API data is the most interesting to me out of all it. Obviously, the whole use case is is fantastic, and people have been clamoring for it. I mean, for as long as I've been involved with the project, if not longer. But so much data comes, at least for projects that I'm working on, come from these external APIs where I clearly do not have eloquent models for every single thing that's coming back from these APIs.

Alex Six:

I just wanna show some data. The project I'm working on right now, I can already think of no less than 10 different places where I wanna reach out, grab API data, and just show it. Like, I don't I'm not doing anything with it. I'm not even really storing it. It's just contextual information.

Alex Six:

So being able to put that into a table that just matches the rest of my Filament panel, that would be awesome.

Dan Harrin:

I can especially imagine this is gonna be useful for people who are building with APIs that contain query builders and GraphQL interfaces because those really do allow you to drill down into the results of the API query and tailor them. So APIs that allow you to sort records, APIs that allow you to filter, you can pass in the values of the sort the sorting column and the filter form into that, and and the API can do the rest, and then you just return what you wanna render.

Alex Six:

Epic. I love it.

Dan Harrin:

Yeah. And so that's that's one thing. That's all of the the schema stuff we wanna introduce with v4 .

Alex Six:

That's one thing. Just one.

Dan Harrin:

Yeah. And one thing we've already discussed quite a bit is the UI side of things, and this is especially what I've been talking to Zap about as well because he controls a lot of the UI work in Filament. And I think we both have a very similar vision on what we want this to look like in v4 . Essentially, we've always said that we want to start extracting out more blade components, and we already started to do this in version 3 with our blade component library. So we've got inputs and cards and tabs available outside of the schema.

Dan Harrin:

But we want to go further than that and extract all of the UI that we use inside schemas into blade components so that you can use those without the schema syntax. So if you don't like or you don't need the PHP classes that back up the UI in Filament, then you can ditch those and you can utilize the blade components that we use ourselves to build Filament with. Part of how we're gonna do that is make a rule for ourselves, maintaining Filament that we don't ever put CSS classes into schema views. We are only ever allowed to use blade components that then abstract those CSS classes away, and that will kind of force us to make a good blade component API because we have to use ourselves. Right?

Dan Harrin:

Because it's very easy for us to just stick a CSS class in the schema view and then forget about it. But if we force ourselves not to do that, we are then pushing that into something that the user can use on their own.

Alex Six:

Does that hamstring us at all? Like, is is there a world where forcing ourselves to push CSS just in these components? Is there a world where that makes maintaining the panel, for example, more difficult? Or does it mean we're just gonna have more components, like, more layout components and things that we would use, say, in the panel that then can be used wherever else blade can be used?

Dan Harrin:

It's gonna make it more difficult for us to maintain because we're gonna have to step through more files when we're managing stuff. But we're already having a lot of file savings by merging schemers together. And also the files that we are gonna be managing are gonna be smaller. And they're gonna have more of a specific role instead of handling everything so the schema v files are only gonna be used for translating the schema definition into UI whereas the UI blade components are purely gonna be dealing with props and transforming that into HTML. So they're much more specific roles for each view.

Dan Harrin:

They are gonna be smaller views, but it will make it more difficult for us to maintain, but hopefully for good reason.

Alex Six:

Right. Well, and and talking about CSS, let's I'm very curious about this. Let's let's talk about our CSS plan in general for these components. Yeah.

Dan Harrin:

Yeah. So we want to stop using Tailwind CSS inside the HTML. Now, this sounds very radical and I love Tailwind. Don't get me wrong. But I feel like Filament is at a point now where tailwind in the views is becoming more of a hindrance than is helping us.

Dan Harrin:

And this is not to say that apps should be doing this, because I when I build an app, I'm absolutely gonna keep putting tailwinded views. That's not a problem. But when I'm building a UI library like this, it does feel like it's slowing us down a bit. Firstly, because there are so many classes in these components, that these views are getting huge in size. And while compression can make that okay, it is hurting our performance a little bit, because Livewire does send the HTML over the wire, including all the towing classes.

Dan Harrin:

So that is something we want to try and minimize a little bit and hopefully get a little bit performance saving on that. Additionally, we want to improve how you're customizing those styles. So actually moving to semantic class names will force us to improve our semantic class naming strategy anyway, which we already kind of have started, but we can improve that even more. And it will allow us to make overriding those CSS classes much easier. Because when they're in a CSS file instead of in the HTML, we can apply a layer to them and that will allow the style overrides that you make in your own app to override that layer and make it easier for you to change how something looks without having to use specificity hacks or important or similar.

Dan Harrin:

There are also a few more improvements here, because you'll no longer need to add the Filament views, that the vendor views into your tailwind config. So that's gonna improve your Tailwind build speed, because you're not scanning many many many views for classes. You will also be able to minimize the CSS that you need to build, because in theory you could only import the component CSS files that you actually need to be able to render the components that you're actually using. So if you wanted to, you could, instead of importing the entire Filament CSS file, you could just import the components you need and make your build smaller. And also, when you put your semantic classes with their rules aside your overrides, you can deduplicate some of the rules, if they override each other.

Dan Harrin:

So, Tailwind V4 is actually moving to use a tool called Lightning CSS, which has this built in, and it can merge adjacent CSS rules that become obsolete. So, say, you have 2 statements in your CSS, both at target the same class and both that change the text color. Now, the one that comes after that is always gonna override the one that comes before, so we can safely remove the one that comes before because it will never be used. Now, light in CSS should be able to save us some CSS file size by doing that and that will kind of make it, so that the styles that Filament is using don't get included if you are overriding them anyway, because say we have a text color set to to grey 600 and you set the text color to gray 700, there's no point in us sending through gray 600 for that component. We should only send through your one.

Dan Harrin:

So hopefully, lightning CSS will be able to do that. I haven't played with it yet, but from what I've read, it should help us out there.

Alex Six:

So then so so, obviously, you say we're moving away away from using Tailwind in our components, like, in the actual HTML. Is the plan in those CSS files for each component to at apply tailwind classes into them? Okay. I I figured that was the case, but I thought we should probably say that.

Dan Harrin:

So, yeah, if not apply, then we'll probably end up using the new CSS variables that Tailwind 4 is introducing. So a lot of the a lot of the values will be available as CSS variables. So maybe we will just go with using normal CSS and then using the Tailwind CSS variables, but tailwind will still be required to use Filament. We're still gonna be building on top of it. It's to a tool stack product, and you'll still be able to use tailwind in your custom views, and in your overrides if you wanna use apply.

Dan Harrin:

But it's just a change that we're making internally that shouldn't affect you, but it should have positive impacts.

Alex Six:

That's awesome. Yeah. I'm on a slightly unrelated note, I'm so happy that Tailwind CSS is moving towards CSS variables. I think that's

Dan Harrin:

Yes.

Alex Six:

Such a good decision.

Dan Harrin:

It's a great move. Yeah.

Alex Six:

I'm so excited for the performance improvements too with Tailwind that Adam keeps tweeting about. I keep seeing him kinda

Dan Harrin:

Yeah. I saw that one.

Alex Six:

Yeah. I I am I'm so excited about Tailwind v4 . Do we know when that's gonna be released? Have they announced to release it yet?

Dan Harrin:

So they said it, hopefully, it will be released before the summer. That's crazy.

Alex Six:

That's so fast.

Dan Harrin:

But I'm obviously, I don't wanna hold them accountable to that, and they can release it in their own time because I understand how it is having people pressuring you about when something's gonna get released. So whenever they release it, it's gonna be absolutely adequate for everyone who's using it because it's not a life or death thing. But, hopefully, that will then allow us to upgrade to tailwind 4 before we release any Filament 4 things, which we're also aiming for the summer.

Alex Six:

Yeah. Yeah. That makes sense.

Dan Harrin:

So we want to be able to launch with tailwind 4 because that kind of feels like a good milestone and a good reason to make a major version too.

Alex Six:

Definitely. That's also exciting. There was only technically two things. All of that for the last half an hour has been 2 things we're adding or changing in v4 . Are there we don't I I we don't have to.

Alex Six:

I don't think we should talk about them now, but are there other v4 ideas, or is that Yeah. Kind of the the bulk of it?

Dan Harrin:

Yeah. So we'll probably discuss on other episodes things like nested resources, rewriting documentation, and and how we're gonna work on improving that because that's also a big a big thing we want to improve in version 4. Also documenting our UI library, our new blade components, because there's only so far that markdown can take us there, I think. So I think that documenting how we're then gonna build the documentation for the blade components is is gonna be interesting topics. So, yeah, there's definitely some more v four stuff that we wanna do.

Alex Six:

Yeah. More more, more topics for more more podcasts. So Yep. I'm, like, yeah, I'm excited to dig more into those. I feel like we we went through a lot today, and I I think folks are gonna be excited about it.

Alex Six:

I'm excited about it. I'm excited about v4 .

Dan Harrin:

Yeah. And, hopefully, I'll be I'll be able to provide an update as well in future episodes about where I'm at with that. I mean, I've already started the refactor, but might be able to give more specific details later on.

Alex Six:

Yeah. Well, the people wanna hear it. Yeah. You made a you made a pretty bold tweet with us not ever needing a Filament v 5 after

Dan Harrin:

these changes. No. I think we all need a Filament v 5. However, I don't think that the changes we make here will be reversed or changed in any way. I think that this is quite an ultimate implementation.

Dan Harrin:

Mhmm. Though I can't imagine how we would improve the way that schemers interact more than just combine them anyway.

Alex Six:

Right.

Dan Harrin:

So

Alex Six:

Right.

Dan Harrin:

Yeah. I'm not saying no Filament v 5, but I'm saying the smaller Filament v 5, maybe. I don't think people would be happy about that.

Alex Six:

Small major versions are usually received well.

Dan Harrin:

Popular.

Alex Six:

Yeah. Nevertheless, this has been a ton of fun. This is, yeah, like I said, for 1st episode of our our Bright Ideas podcast. So as always, enjoyable time talking with you, Dan. For the listener, definitely make sure to follow Phil and PHP on Twitter.

Alex Six:

If you want more of these updates, that's where you're gonna find it. Follow Dan and myself as well and and the rest of the Filament core team. If you want more updates and information on v4 and just on Filament in general. And make sure to to drop us a review and rate us 5 stars in your pod catcher of choice. That would definitely help the show.

Alex Six:

We'll be coming back every month, talk a little bit more about Filament in general. But, yeah, thanks for coming along on this crazy ride, and we'll see you next time.