Bright Ideas

[00:00:00] Hello, everybody. Welcome back to another episode of bright ideas. I'm one of the hosts, Alex,

Dan: And I'm Dan, uh, one of the creators of Filament.

Alexander: and we are really happy to have you all here with us today. Today's episode is going to be kind of a shorter, more snappy episode than we typically do. Mostly just a lot of updates, uh, this time around for both the Filament org and, V4 as a whole. So we are going to go quick. We're going to roll through some stuff, but before we start, I want to give a huge shout out and a big thank you to Kirschbaum development group for being an official Filament partner and for in large part, helping make this podcast a reality.

So. Kirschbaum, thank you so much. We really appreciate all that you do for the Laravel community and for Filament. So to start off just on Filament organizational level updates, uh, we have added Kenneth the team. Y'all might've seen tweets or posts on blue sky about it. We are so excited. If you don't know [00:01:00] Kenneth from the community, he is the creator and maintainer of the advanced tables plugin.

Which is ridiculous, by the way. Every time I look at the stuff that he does in that package, I feel dumber and dumber and dumber. It is incredible what he's been able to do with that, well, filament tables, and we're so excited to have his expertise and his help with keeping Filament going in what I would like to think is a really nice upward direction.

Obviously he'll be helping a lot with the tables package, but already he's been a massive help and honestly, just a great presence to have around the team. So welcome Kenneth. Thank you for working with us and listeners, if you see Kenneth around the community, give him a hello and a congratulations for joining the team.

We're super excited.

Dan: Yeah. Welcome, Kenneth. Uh, I'm always very impressed with Kenneth's work. It's very clear that he knows the table builder package like inside out in ways that allow him to extend it without breaking things, without [00:02:00] causing the code to be brittle between updates, it's very impressive.

And also, there's a lot of potential for, for this partnership with him and the core team.

Alexander: Yeah. Very, very excited. But I think as far as organizational updates, that was really the big one that I kind of want to get out. I guess I'll put it in the show notes. There is a, like a get to know you Q and A blog post, with Kenneth out on the Filament site. So definitely give that a read.

It's awesome. We're going to be doing that for the remainder of the, the Filament core team as well. I've got to pick my next victim to see who's going to answer all my questions, but, you should see one of those coming out shortly, but definitely check out Kenneth's article. I'll I'll link it in the show notes below.

But with that, do we want to turn over to V4 updates? What people are probably really excited about.

Dan: Yeah, for sure. I think my first, so I looked through all of the pull requests that I've merged since, our last episode on v4, just to have a look to see if anything stood out. So I've, I've got a few things written down. The first one that I added was, email change verification. The concept of this is that, usually an application will [00:03:00] verify an email address when you sign up for it. Some applications will also verify you when you change the email address of a user from their profile. A lot of the time this involves just like removing the email verified at timestamp. I kind of wanted to avoid that because, it means that you're kind of like locked out of your account.

Like you can't really use it in the meantime, and if it's like a malicious change, there's no way to like undo that, you know, like no one really gets notified or anything. So I wanted to make it a little bit more like interactive and comprehensive. So the way I've built it is that, when you have this feature enabled, it's optional, the change doesn't get immediately saved into the users table. So what actually happens is a link gets generated with a signed URL and that contains, the encrypted email address that you want to change the account to, and a notification gets sent out to the old email address and the new email address. [00:04:00] So the new email address gets sent the URL to confirm the change, so that's the verification part, but the older email address also receives a link to block the change. So, for example, a change was done maliciously and a user was able to catch it before it was verified, um, they're able to do that.

And essentially how that works is that we store the signature of the URL while it's valid in the cache, and then we remove it from the cache if it gets blocked and we only make sure that we, change the actual email on the account, if the signature is valid and also it's contained inside the cache, so it means that, you can actually block those changes. I think that's about it for email change, but I think that kind of like, um,

Alexander: I was going to say quick before we moved on that these are the kinds of changes that really draw me to Filament or the kinds of features that really draw me to Filament, right? It's like one step above, Hey, we're a toolkit for tall stack apps, which we are. And that's awesome. We do really [00:05:00] well at that.

But man, email change verification is one of those things where is it really difficult to implement? No, not really. Is it a real tedious pain to do it? Yes, so much. It is one of the things that I look forward to the absolute least when I'm spinning up a new application where I'm like, uh, now I got to like, make sure people can't maliciously change emails.

Right. It's like such a seemingly small thing that's so important, so I'm, I'm really happy to hear that we've got that built right in now.

Dan: Yeah, and I'm, I'm quite happy with how it's turned out because there aren't any extra like database migrations involved, like in some solutions, you might need to like track those within a database table, but because we're using the cache, it, It means that there's no extra setup for users. And also, it means that we can easily expire the links like, because cache records only live for an hour or however long the link lives for.

Alexander: Right.

Dan: There's no pruning process of the [00:06:00] database either, which is nice.

Alexander: That is really nice. Yeah. I'm curious to see how people, how people like this one. I feel like most people are going to love it and just use it for everything. Cause you might as well. That's just one less thing to build.

Dan: And obviously there are alternative solutions that you can use if you didn't want to enable this feature. This isn't like included out of the box unless you enable it. So, it's just one option you have.

Alexander: Well, in a similar vein, I think that's where you're going next. Talk to me about two factor auth. I feel like we've talked about it a couple of times in a couple of episodes now. So can you quickly recap kind of what it is and then what we've updated?

Dan: Yeah. So I think last episode I introduced it and, um, we also talked about some potential improvements that I could make. To it. I think that, um, the basis of it is that there are multiple different two factor drivers that you can add to a panel. And, the previous implementation was that when the developer added these providers, there was no, requirement for users to set them up to start with. Users can set them up, if they wanted to. [00:07:00] And also if the user sets up multiple, cause you can add multiple drivers to the same panel, it would require them to go through all of those steps before signing in. And I decided that, well, I mean, we had a discussion last time and we thought that maybe that wasn't the best default.

We discussed a few options, maybe making it configurable, like how many are required. Um, I decided to just keep it simple for now and change the implementation so that to start with, a developer can require you to set up two factor and that will be, you choose at least one, two factor methods set up.

You don't have to choose multiple. And also if you do have multiple set up, then you can choose when you sign in, which one to use, uh, which is, I think a better default. So that's nothing, nothing else has really changed. I've done a few like UI updates to make it a little bit more cohesive with the new schemas and stuff. Like previously I was. using some custom blade views to handle, like setting up the two factor [00:08:00] modal. But now I've refactored it so that there are only schema components and everything in that modal is now a schema component.

So it kind of like also demonstrates, the flexibility of how you can build different views with the schemas in, in Filament V4, which is nice.

Alexander: Yeah, I was going to say, I think the more, the more examples we can put of schemas or really using the schema components in Filament itself, the better. And that is such a great example of where you can really pull together all the different pieces that we've now bundled into this schema namespace.

Dan: Cause there's like

There's like obviously introductory text. So imagine you were setting up a Google two factor, there's like introductory text, then there's a QR code. So you can just put an image in line. there's also then more text and then there's a card containing your recovery codes and each recovery code is in a bullet list and each item in the bullet list is copyable and there's links at the bottom of the card to copy all of them and things like that.

So, there are, yeah, there are quite a few [00:09:00] different components that I added in. I added like a, um, I called it like a secondary section. So like a section in

is like, um, usually like a, card that's quite prominent. It's, it has a white background on light mode and a dark background in dark mode and, has like a border and everything, but the secondary one, it's kind of more like flat and it has a slight ring, but it's not, it's not as prominent.

It's not like a white background. so I introduced that for the recovery codes and I think it's quite a nice, um, a new component that works quite well with other schemas, but also looks better than having a normal section nested inside a normal section. So it's nice to having like a, a secondary section inside a modal or inside a, another section.

Alexander: I was going to say, is the point of the, I know we're kind of going off from what the original point of this topic was, but is the point of the secondary section to be nested inside of a normal section?

Dan: I think nested inside anything with a white background like there are quite a few different [00:10:00] components like tabs I don't think sections work look very nice in tabs because it's kind of already got a white background also modals like sections look fine and fine issue modals, but think that a secondary section would look nicer. They have the same sizing options as sections as well. So sections come in like normal mode and then compact mode. So there's also compact mode for, uh, secondary sections. And obviously like you can have a heading, you can have a description. You might, you might choose not to, I don't use a heading or description in this case. but, uh, I just think it's, it's nice. Even if you aren't using a parent section, there are cases where you might not want to, use a normal one.

Alexander: Very cool.

Dan: Yep. Next up is, I've got, you've got a few accessibility things, that I worked on. I think that accessibility is one area that we lack a tiny bit in Filament V3.

There are some like longstanding issues. One of them is to do with heading [00:11:00] tags. So, let's take a section, for example. A section can have a heading. if you nest a section inside a section, in Filament V3, both of those sections, the headings would be the same heading tag. So it would be like, heading 3. But that isn't semantically appropriate since a section could be nested inside a section and other things like repeater items, like can have labels and stuff. Uh, maybe they use headings. So we basically need a way to dynamically know where we are in the schema and generate the correct heading type, depending on how deeply nested you are. And also we need to make it so that the root heading number is configurable based on the schema that you're in. So for example, when you're in a table, a table has a heading already, so we can't reuse that heading tag inside the filters form or anything like that. So we have [00:12:00] to kind of like have the root, the root level configurable as well. So I implemented that. So now that, depending on where you are in the schema, the heading tag is generated dynamically, and when you get past heading six, it just generates paragraph tags.

Alexander: That's awesome. So is there any way to manually select what the heading size should be. Theoretically, we shouldn't need that. Right. But is that something we could do?

Dan: Not on a per element level, you can manually select what the root heading size is, so you can pass to the form, I think.

Alexander: And then that just cascades down.

Dan: Yeah, and that cascades down, so if you need to start on a different thing, maybe your layout contains an extra heading, then you can change what the root is, but I don't want people messing around with like, making it not fit,

Alexander: Taking all the accessibility work you did and then throwing it out the window.

Dan: it's kind of a complex implementation because it's not like, oh, if you're two levels deep in the schema, [00:13:00] then it has to be two levels consumed of headings. And also like, not all components that can have headings always do have headings. So it's like, does this component have a heading? Yes, then cascade down. If it doesn't, then we have to ignore it. right, but like, that's different for every component. Like a section heading is handled differently to, to another component. So, yeah, it's, it was an interesting one because I don't want like a heading can be, to be consumed when there's something inside a section without heading.

Alexander: Right, that is going to be a really interesting piece of code to dig into and see how you did that. Obviously not probably the best thing to talk about on a purely audio format podcast, but, yeah, I would, I'm going to have to go looking for that one and dig in and see what you did there.

Dan: Yeah, so slight tangent for the next one. Uh, I upgraded tailwind v4 or it went quite well. It didn't really break anything in our styling, which was nice. Like the, the automated script worked quite nicely, even though we have an untraditional [00:14:00] structure. One thing I did spend a lot of time on was the colors. Tailwind 4 uses OKLCH colors instead of a hex and RGB. And this is good for a number of reasons. But it did make the upgrade for us a little bit difficult because currently all of the colors in filament are defined in RGB so that we can use alpha values and stuff. And also like users can define their own RGB and hex colors as custom colors and I wanted that to continue to work inside Filament 4, without them having to convert all of those. So I ended up having to actually write scripts to convert RGB and hex values into OKLCH colors. I was struggling a little bit on this, specifically on the to OKLCH direction, because I was struggling to convert, this should have been the easiest part converting normal RGB to linear RGB, but I completely missed some little details, with that so I got some [00:15:00] help from Arthur on GitHub, who was kind enough to help out and we managed to sort out some scripts to convert those. So it's nice. So now it's all backwards compatible. I've also changed because in Filament three, you could generate a color palette based on one color. I've changed that so that it uses the OKLCH, lightness value and changes that to generate the palette, which is nice. So that's kind of easier than what we had before as well. So top of that, I've also been working on another accessibility thing, which is color contrast throughout Filament. Using some tailwind colors in Filament 3 is accessible. It's all to do with like how light the like specific shades of the color are compared to others. So, all buttons in Filament three use 600 background, in light mode and a 500 in dark mode, but on white text that might not be meeting the contrast ratio that we need. Even like the default Amber doesn't. meet that properly, which is disappointing. [00:16:00] So I've written a script to, to start with convert the OKLCH colors back to RGB, because then we need to convert, then we need to find what the lightness is for that color, based on the RGB value. Which only really works in RGB space and not in OKLAB space.

OKLAB has different lightness and it isn't necessarily the same as the lightness used when comparing contrast. So I wrote a script that can calculate contrast between two OKLCH colors from an accessibility point of view. and then I, I use that to actually dynamically generate the correct text color for a background color, and make sure that the text color is accessible both on like the normal state and the hover state or the focus state of an element. There are also other situations where icons need to have the correct contrast, like accessibility guidelines state that if an icon is like integral to how the page [00:17:00] functions, uh, and the user, the understanding of it, then it needs to have at least a three to one contrast ratio. So, icons in that situation also have the correct contrast ratio. And it kind of the colors of the text adapts based on what the background is like on Amber. Now the Amber buttons have a dark text color, because it, If you made Amber dark enough for a light text color, it just looked bad. And I think the darker ones look better. So, you can also, because this is kind of handled on like a component by component basis, because each component has different background colors. Like a, a button has different background colors to a badge, like a badge is. Quite transparent and has a much lighter background. Each component has its own color class that, determines what the colors should be. So you can actually override that color class if you wanted to change like the algorithm that we choose when deciding what colors to make certain elements, um, so that's just like a binding and you want to the container. Which [00:18:00] is nice.

Alexander: Yeah, that's really cool. And the flexibility there is nice. I don't know how many people are actually going to go out of their way to change the algorithm, but if you need to,

Dan: At some point

Um, but yeah, it's, it was quite eye opening for me, like doing this work. But I'm quite happy with, like, what I've settled on. Yeah, I'm just implementing that through the rest of the code base as I'm refactoring the rest of the views remove the tailwind and put it in CSS files.

I'm doing the colors at the same time.

Alexander: Putting my DevRel hat on for a minute. That sounds like it warrants a whole blog post about, you know, How we went from, you know, Tailwind three to Tailwind four, and especially about all the color contrast, because I feel like there's a lot of material out there on accessibility, specifically accessibility with colors.

But I, I feel as though there's a lot of folks who don't go out of their way to go look for it. And so putting it on the Filament site, I mean, You know, adding one more place for people to be like, Oh, that's right. I probably should like check my filament apps, uh, and see if they're, they're actually [00:19:00] accessible.

Dan: I also would like to open source the script for converting the colors between RGB and OKLCH as well, because none of the scripts that I tried were actually accurate, and it's really, it's

quite a complex problem. But also I don't really want to maintain that. That's not something I want to do. Not that it really requires maintenance, but yeah, if people want to copy it from the vanilla code base, they can. I've, I've got nothing against that. So, i, that was hours of difficulty.

Alexander: I just can't believe that such a script didn't already exist.

Dan: They do exist, but seriously I tried, I tried certain colors and if they were not like, aligning with, uh, what What the colors should be like based on the OKLCH website, uh, there's a website that can convert them. And obviously there were like implementations in JavaScript as well, but I can't run those in PHP and it will have to

So

Alexander: You just open source it and then just give it to the, the OKLCH people

do it. Yeah. Copy and paste at your own [00:20:00] risk.

Dan: Yeah.

Alexander: No, that's awesome.

This, this next point I'm really excited about if I think these are what I think they are, cause this is new. I haven't heard about this yet. Um, yeah, because these are my favorite new addition to CSS.

Talk to me about container queries.

Dan: Yeah. So obviously most browsers now support container queries; not all of them, so these are features that are opt in and we also, we do have a couple of places where we use them, inside Filament and we have done for quite a while actually, but we actually have browser fallbacks to make sure that if your browser doesn't support a container query, then it uses normal sizing. If you don't know what a container query is, a container query is similar to a media query. So a media query is going to be looking at like the size of the browser or the device e and showing you different content or applying different CSS rules based on those that size. Container query is doing that, but on a element by element level, so you can select a specific [00:21:00] element as a container, and then you can, say any element inside that can then react to how large that container is.

So. This might not sound very useful, but it's very useful in situations where containers change sizes unpredictably For example, if you have like a sidebar on the page, the actual width of your page content can change quite a lot as you resize the browser. Like, It gradually gets smaller as you make the browser smaller, but then at some point, the sidebar property hides and it becomes collapsible, which means that then there's actually more content space when you make the browser smaller, even though you've made the browser smaller, which means that then you're stuck with like a mobile friendly experience on a larger screen size.

You don't need to. So container queries and Filament allow you to. They're in schemas and they allow you to select a specific element as the container. So, for example, you might have a section and all of the elements [00:22:00] inside that section react to the size of the section. So then, it's all integrated within the grid and grid column, and column span and column start methods that already exist.

But instead of using, MD, LG, XL to, to dictate how many columns or call it, or what the column span is on that level, I've taken inspiration from the Tailwind syntax, which is an at sign and then at sign, and then there's the break point, like large, medium, small. And you can use all of the available Tailwind breakpoints for the container queries in there. You can also, because, obviously not all browsers support that, but you might want to support browsers that do and browsers that don't at the same time. You can also, prepend it with a exclamation mark. What that will do is it will say when there are no container queries available in the browser, use this break point, but when that is [00:23:00] use a different break point, like use a normal responsive break point.

So it means that you can basically support both at once by having two lines instead of one. So maybe you have like a large container break point with the at symbol, but then you have a separate item in the array, which is like an exclamation mark at symbol for a browser window size break point that is only applied when container queries are not supported in the browser So you can have kind of both at once There are a few cases where we do this within the Filament core as well like tables pagination has had it for I think definitely over a year now. Pagination reacts the size of the table when that's available. However, there are certain elements that we aren't able to add containers to yet because the floating UI package doesn't support using floating UI within containers at the moment. So anything with an action group inside, like a, like the entire table, not just like a small part of the table when that is, while [00:24:00] that still is still a bug. I'm not able to use containing queries anywhere else.

And you can't add an action group inside a schema with a container for that reason, which is a shame, but hopefully it will be

fixed at some point.

Alexander: Yeah, that is a bit of a shame. Hopefully soon, I mean, I just pulled

up, can I use just to look at the container queries browser support and it seems like as long as you're not targeting IE 11, you're, uh you're good to go. I mean, I, I mean, my gosh, Firefox has even supported it since version 109 and we're on.

What like 130 something now, I think last I looked, um, yeah, the only thing that the only part of the spec that isn't supported is CSS container style queries, but those are still in working draft. So those aren't even like a part of the official CSS spec yet. Um, and even then, just in a working draft, it covers, they estimate 84 percent of all browsers.

So, yeah. That's, that's exciting stuff. [00:25:00] I'm very excited to see that. I, I've seen a lot of stuff online recently where people are like, Oh, I don't, you know, I don't really bump into situations where I need container queries. I could just use, you know, normal window queries or something, but maybe it's just like what I do at work with all the cards and widgets and stuff.

We have to move around, but holy smokes. Container queries would just make that so much easier. Did, are we using. Like in line in the class attributes, Tailwind to do container queries. Or are we writing kind of hand rolling our own CSS for that?

Dan: Everything's our own CSS. Technically in Filament v4, when the refactor is complete, you should not have to add Filament views to your Tailwind config at all. Like we cannot, we cannot rely on that. And it's going to make installation a little bit easier as well, but um basically we have, a set number of classes that we always compile.

There isn't, there aren't actually that many. I think we might use CSS variables actually to pass through, things. So,

Alexander: If we don't, we should.

Dan: yes. Uh, the only problem with that [00:26:00] is that it's using inline styles. So we're actually defining the CSS variables in inline styles and. I have a feeling that at some point we're going to have to be, we're going to have to support CSP like strict CSP and Filament at the moment, LiveWire doesn't support it as far as I know. So we can't do that yet, but at some point we probably will need to do that. And we will not be able to use inline styles at that point because inline styles need to be signed and we can't predict what they're going to contain, when the page loads because content doesn't even load in at that point, right?

Like it needs to be in the header of the response. I think so yeah, I at the moment it works great and we've been using inline styles with css variables for like definitely over a year with like the grids like the Filament grids everything you can have an unlimited number of grid columns because we just define the number of columns inside a css variable and then use that in the Tailwind class to dynamically generate that. So the only parts of the CSS that we repeat for this, so like the actual break points. So we have, an MD [00:27:00] class that reads from the MD CSS variable. And then we only add that class to the view when that variable is present.

Alexander: Nice, that makes sense. That's really cool. I'm looking forward to that a lot.

Dan: Next up is icons. So I've been doing a lot of UI stuff recently. So icons in Filament 3 are usually just strings. So you can pass in a string and that's going to read from the blade blade icons package and find the correct icon and render it. That is still supported completely, cause it would be a nightmare for people to upgrade large applications. However, I've added an enum for Heroicons and you can use any enum, for the icon names now, which is nice. The Heroicon enum also has a feature called auto sizing, which means that it can choose which variant of the Heroicon to use based on the size of the icon that gets rendered in the browser. And the size of the icon is not [00:28:00] configurable. So like if you have a small button, the small, the icons made smaller for you. If you have an icon button, it's a certain size. Basically just depending on where it gets rendered, it's in a different size. And that means that, you have to know what the size of the icon is to be able to select the correct icon variant for that, because there are three solid variants for different sizes. So what I've done in the Heroicon enum is only declare the icons once for the solids, and once for the outlines, and Filament will choose the correct variant to render based on the size of the icon that it's looking for. The way this works is like if Filament detects that we're using an enum with the has icon size interface or something, then instead of just reading the value of the enum, it's actually going to call the get icon for size method on the enum and then it's the enum's job to return the correct [00:29:00] icon string for the size that Filament tells it. So like for outlines, it doesn't change anything because there is only one outline variant and you just have to be responsible, you shouldn't use an outline when it's, it's not like a large icon, but for the others, Filament will do that for you if you use the Heroicon Enum.

Alexander: Honestly, I'm just happy. They're all, they're all enums now.

Dan: Yeah,

and people can add own enums and stuff.

it's just like a backed enum, there's no interface or anything. So

just use any backed enum.

Alexander: Which is awesome because then, oh, I don't use heroicons. I use

material icons or whatever else. Oh, here. All right. Here's your enum. Right. I made it or somebody wrote a package for it.

It feels like that would be a really low hanging fruit package for somebody who wants to like jump into the Filament package ecosystem. Those would be. Pretty, pretty nice to knock out. Honestly, hot take, get rid of all the magic strings in Laravel, all of them, make them all enums, every single one.

Dan: Rules is one on my hit-list for Laravel,

like I [00:30:00] wish that rule strings and especially the rule syntax with the pipes just disappeared.

Alexander: It's actually, it's, it literally, it's funny you say that. It's on my to do list to start a discussion around. can we just use the rule classes or if we really have to use the strings upstream, like it would be a real pain to edit all of that. Can we just make an enum that is backed by, you know, the required string or the accepted string?

That would be awesome if we could do that. I mean, theoretically we could do it now, right? In your rules array, you could like, you know, rules, enum required arrow value, but I don't want to do that. I just want to pass in the enum that I want.

Dan: Yeah, I think like most of the rule class in Laravel, and I might be wrong with this, most of them just serialize to strings.

So either way you're dealing with the string,

Alexander: Right.

Dan: I think there's a few exceptions, like exists rule and stuff,

you pass like a function, I don't think they serialize that, but maybe they do.

Alexander: Yeah, I looked into it a while ago like maybe a year, year and a half ago.

Um, [00:31:00] and I don't really remember the outcome of that, except for it didn't seem like there was one cohesive way to do it. Like, depending on the rule, like you said, it was either serialized or not. And now it's just an object. It feels like we could clean up a bunch of the code paths by, by doing that.

But I'm not going to stand here and pretend to be Taylor Otwell, like if that's the way it is, there's, there's probably a reason, but it's worth opening a discussion up for it at least, because the amount of times that I typo a required or something, and it just goes unnoticed is unbelievable. Um, but yeah, the enum is exciting and also exciting, something I feel like we've been talking about our next topic since Filament V2. Like I feel like I remember talking about this for the V3 upgrade. Talk to me about TipTap.

Dan: Yeah. So tip tap is finally being introduced into the core. It is not an extra component is replacing the rich editor, with Trix, obviously like the default configuration is just using HTML. So it's backwards compatible with Trix, but it does require, like, it does allow us to, [00:32:00] really extend it.

Like, Trix is not that extensible, but TipTap is built for that. So, already we've been able to make some nice improvements to the default experience. So, for example, um links now open, like when you add a link, it opens in a modal instead of like a silly little dropdown pop over thing that was in Trix.

And it is really difficult to style in Trix as well. And image uploads as well are now done in a modal as well. So, that works, uh, also pasting images from external URL will now not just paste the URL, but also upload them to your storage so they're permanent links and also dragging and dropping from your computer works, obviously. I'm, I've also laid the groundwork for images to work with the Sparty media library. So the way that we've done this is images gets assigned an ID. Randomly when they get uploaded on the javascript side and this can be then be used to track the life cycle of the image across the editing experience, [00:33:00] When I get to this feature, which I haven't yet, it will allow us to store the images in Spatie media library and then prune them from Spatie media library when they get removed from the tip tap content because the tip tap content is usually in like JSON format when we receive it back before we convert it back to HTML. And we can actually just like traverse all of the nodes in the tip tap content tree to find all the enums, uh, enums, images that have been removed. And the ones that have been added and store them in media library properly. So nice to have in core. I've been working with Adam on the core team a little bit on this. And he's had some really nice insights, cause obviously he maintains the tip tap package. So, yeah, I'm not, I'm not sure if we're going to have all of the features from the TipTap package in core, but I do want to also work out a way to allow it to be extensible, like registering your own JS extensions for the tip tap and on the PHP side as well, it needs to happen so that we can convert JSON [00:34:00] into HTML properly.

Alexander: I think registering custom JavaScript extensions would be the biggest new feature for TipTap if we could get that figured out in an ergonomic way. Right. Um.

Dan: In the tipped up plugin, I think they read from like a global window object.

So if you've put your plugin in like some, variable on the window, then it means that it will import those when it creates the editor. But I kind of want to avoid that because all of the JavaScript and Filament anyway, is asynchronously loaded.

So I don't want extensions to have to be loaded at the start of the page so I'm thinking about trying to work out how to like a dynamic import from url Like javascript from url,

Alexander: Mm.

Dan: So like make a request only when we need it

Alexander: Right.

Dan: the extension and then import it dynamically.

Alexander: It's a big step. I think it, that seems like a really small change, but I think it's [00:35:00] one that's going to unlock a lot of potential functionality within Filament, specifically within the panel, but obviously just kind of wherever forms are used.

I think that is, I mean, I can already just off the top of my head, think of two or three different projects where I would have loved to have TipTap in just by default. Cause I ended up just swapping out the, you know, the, the default rich text editor with, with, uh, with tip tap. So, big moves. I'm excited about all that, but we are almost exactly at time, which is crazy.

We never hit time. Anything else you want to announce or talk about or update us on.

Dan: No, that's it from me for v4 updates,

Alexander: All right. Well, I think that's about it then. A lot of stuff coming down the pipe for V4, obviously stay tuned. We'll be announcing updates as things go. We're currently just working through the, the roadmap, which is visible and public on Github. If you're ever curious about what we're working on, what we've just finished, always feel free to go take a look there.

[00:36:00] But keep up with us on social medias as well. You can find Dan and I and Filament on Twitter on Blue Sky. And if you really want to jump in and join the community, which I would recommend, come take a look at our Discord. All those links will be in the show notes. So feel free to grab them there.

Once again, thank you to Kirschbaum for being a filament partner. Thanks for listening. It's been great to have you and we'll see you next time.

Dan: thanks for listening

Alexander: Bye.