Skeleton v3 Update - Zag 1.0 and Preparing for Release

[endigo9740]

Hey everyone, Chris here from the Skeleton team. With Skeleton v3 RC2 now enabling support for Tailwind v4, I wanted to take a moment to detail a quick follow up or our existing RC2 users. As well as share our plans between now and the upcoming launch for Skeleton v3.

RC2 + Tailwind Vite Plugin Quick Fix

First up, if you're already using the Skeleton v3 RC2 with Tailwind v4, we wanted to alert everyone to a last minute configuration change to avoid a known Tailwind v4 issue where components from node_modules may suddenly lose their styling.

Note that this ONLY affects projects using the Tailwind Vite plugin, which includes: SvelteKit, Vite/React, Vite/Svelte, and Astro. This will not affect Next.js projects or anyone that chose to stick with the Tailwind PostCSS plugin.

The change is simple, simply append /dist to the end of the @source path in your global stylesheet configuration.

@source '../node_modules/@skeletonlabs/skeleton-{react|svelte}/dist';

Please note that all related documentation and migration guides have been updated accordingly.

Zag 1.0 and Svelte Component API Change

Update: This change is now live. Update your respective component packages to receive and test this directly.

As you may know, Skeleton currently utilize Zag.js as the foundation for all Skeleton v3 components. This provides a headless solution for implementing common component patterns, including state and logic in an accessible and cross-framework manner.

Recently Zag has launched their big v1.0 release, which includes some significant performance improvements. As such, we're currently implementing these changes. Thankfully this has no inherent breaking changes to the component APIs.

However, the Skeleton team is going to use this opportunity to revisit our components and make a very specific change for Svelte components. Essentially we're going to move away from Svelte's two-way data binding syntax, bind: and $bindable(), in favor of matching Zag's intended data model:

• Data In - use props to pass data in
• Data Out - use event handlers to resolve updated data

Here's a quick before and after comparison of this change:

<Example bind:value={someState} />

<Example value={someState} onValueChange={(e) => (someState = e.someState)} />

While a bit more verbose, it's worth considering why we're moving away from $bindable specifically:

1. The separate i/o model is easier to hook into as it's just a simple transaction
2. No need to use $effect() to be notified of changes (which is an anti-pattern)
3. It's impossible to spread attributes <Example {...attributes} />, as bind is explicit.
4. It's impossible to use rest ..., as again, $bindable() is explicit

Additionally, by moving away from $bindable, Skeleton can now implement components much closer to the original Zag spec. The result is a MUCH slimmer implementation of the component logic:

NOTE the below shows the Zag standards on the left, compared to a $bindable implementation on the right.

Simplifying the logics helps us avoid misinterpretation and errors in the logic. In fact, we've already been able to resolve number of current v3 bugs by stripping out the extra abstraction required to support $bindable, including the following:

• Reorganize monorepo to include /packages and /playgrounds #3194
• Mark . (dot) notation components as PURE. #3225
• Skeleton-Svelte: Replace useId with $props.id. #3215
• Revisit Tailwind 4 Implementation for all internal monorepo projects #3268
• Font size is different on <Navigation.Tile> between RC1 and RC2 #3269
• v3 docs typo: materRounded => meterRounded #3260

Additionally, one of the primary goals is to standardize our component API cross-framework. Doing so has a number of benefits:

• It allow us to more easily add and support more Zag-based components in Skeleton
• It allow us to more easily implements and support other frameworks - such as Vue and Solid
• It enables end users that operate cross-framework (for their personal and professional lives) to have a uniform component API cross-framework
• It simplifies the contributor process, so users don't have to learn different conventions per framework
• It helps us avoid unforeseen edge cases that can creep up when we diverge from Zag's specs and standards. Avoiding the bugs as shown above.

While we have already implemented this change, and we're fairly confident about merging this soon, we do actually wish to hear the community's thoughts on this. I know change in itself is scary. Most of us prefer to stick with framework specific paradigms when we can. However, I hope you'll approach this with an open mind. Especially once you get your hands on the update!

Preparing for the v3 Launch

With Tailwind v4 support now in place, and the Zag update dropping soon, we're coming to the end our dev roadmap for Skeleton v3. Some final documentation and bugfixes aside, we're beginning to prep for the full v3 launch.

As such, we want to give as much notice as possible that this is coming. We don't have a firm release date, but essentially we're going to aim for roughly 1-2 weeks after the Zag updates are released, which should arrive sometime next week.

If you have any questions about what remains, or our plans before or after launch, please feel free to reach out and let us know in the comments.

Thanks everyone!

[stalkerg]

Additionally, by moving away from $bindable, Skeleton can now implement components much closer to the original Zag spec.

If I can't use $bindable and everything same as in React, why do I need to use Svelte in the first place?
Yes, I have a few more reasons, but this changes deprives of a unique experience. Also I 100% understand why it's simplify and improve Skeleton.
Anyway, thank you for your explanation.
PS I know it's started from Zag integration itself, when my vision of Skeleton library as user is became more and more different. I can't change it, and I have no resources to do fork. Anyway I hope other parts of project be strong as usual.

[stalkerg]

One more thing - this issue is 20% technical and 80% matter of taste. You can't expect many technical arguments why you can't do it. It's more about code style and ideology.

[rChaoz]

I agree that, from an end-user perspective, the issue is indeed a matter of taste (and I prefer binds too!). However, you also have to understand the library-maintainer perspective, where it's the exact opposite: mostly technical challenges, barely any code style changes.

While I really don't want Svelte to feel like React, at the end of the day it's a rather minor change in my code, and I will still use binds for everything else which is 90% of the places. In the meantime, by asking us to do this, the Skeleton team has less technical challenges and many other advantages, as it was described in their posts.

Hopefully this helps you understand the change from a different (non-end-user) perspective 🙂

In the end, I, too, would prefer binds, if the Skeleton team can somehow universally fix this issue, with something like a wrapper for the props. Otherwise, the current solution is very much fine.

const props = wrapBinds("value", () => $props())

(no idea if this would actually work)

[stalkerg]

Yes, seems like the next stop will be in the Svelte repo. It should be solved on that level.