📌 Temp Components & Roadmap

[huntabyte]

I'm sure most of you have realized that we're lacking some of the "cooler" components from the original project, which also happen to be some of the more difficult components to build (the right way). This is because there isn't a battle-tested, actively maintained, and feature-complete headless UI library for Svelte at the moment (at least from my extensive searches).

The ideal state of this project would be to use the same headless UI library for >90% of the components. This keeps the component APIs familiar and enables us to easily track breaking changes, updates, and issues.

However, I don't want to hold this project back while our primary headless UI library is being developed and refined. Not only does that apply additional unnecessary pressure to the maintainers of that project, but also keeps us from building complete projects while that development is underway.

So what we've decided to do is work on some "temp" components, which will eventually be replaced by the single headless library's implementation once it's ready. The goal is to do our best to make the APIs as similar as possible to their final state, so that migrating to the newer ones is as simple as changing a few imports/replacing a dependency, but of course no 100% guarantee on that. Since you own the code/components, you can ride out the temps for as long as you'd like, and upgrade to the final version when it works for you.

If you're thinking, why "temp" and not "beta" or "experimental"? Well I couldn't make a decision on what to label these, so I asked ChatGPT and here's what it came up with:

"Experimental" suggests that the component is in the early stages of development and may undergo significant changes or may even be removed altogether. It indicates that the feature is not yet stable or fully tested and is primarily meant for evaluation purposes.

While this somewhat aligns with what we're going for, experimental would be a better label if we were to release a partially-working, untested component, which is not what we'll be doing.

"Beta" is typically considered to be in a more advanced stage of development compared to experimental versions. It implies that the feature is mostly functional but may still have some known issues or require further refinement based on user feedback. Beta versions are often released to a wider audience for testing and gathering user input.

Also partially true, but since the entire API may change and we aren't continously iterating over these components, it doesn't really fit.

"Temp" is an abbreviation for "temporary" and is commonly used to indicate that a component or feature is intended for short-term use. It implies that the element is not final and may be replaced or removed in the future. This term is often used when a placeholder or temporary solution is implemented pending the development of a more robust feature.

Right on the money.

Temp Component Roadmap

The issues below are to be used for discussion around these temporary components. If you know of a solid headless component that would fit in one of these places, first check the issue to ensure it isn't already being developed, and then provide your feedback via a comment.

I've also created a project which makes it a bit easier to visualize the status of each of these components, you can check that out via the "Projects" tab, or this link here.

Don't forget that the goal of this project is to align with shadcn/ui as closely as possible, so ensure to consider/compare before making any suggestions.

• Temp Component: Calendar #96
• Temp Component: Combobox #97
• Temp Component: ContextMenu #99
• Temp Component: Datepicker #98
• Temp Component: DropdownMenu #100
• Temp Component: Menubar #101
• Temp Component: NavigationMenu #102
• Temp Component: Popover #103
• Temp Component: ScrollArea #104
• Temp Component: Select #105
• Temp Component: Toast #106

[phenomen]

radix-svelte is discontinued. What does it mean for the future of shadcn-svelte?

[huntabyte]

@phenomen - We'll eventually migrate all the Radix Svelte components to MeltUI components. It should be seamless!

[huntabyte]

Hi everyone! I've been hard at work helping Thomas (creator of Radix Svelte) get his new project, MeltUI stood up! The progress has been phenomenal so far, which is why I haven't added any of these "Temp Components" because I have a good feeling we'll be able to skip the temp and go with our dedicated headless UI lib sooner than I imagined!

If you want to help expedite the process, definitely check out Melt UI and see if you can contribute in any way! Don't do it for yourself, do it for the ecosystem ;)

Thank you all for your patience, feedback, and support on this project! It has been incredible!

[huntabyte]

Closed by #150 - will begin new issues for remaining missing components, all of which are being actively worked on by us at Melt UI!