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.