Roadmap Discussion

[endigo9740]

>>> View the Roadmap <<<

How This Works

This post is meant to foster discussion and and allow the community to review the current proposals. Please check it out and let us know if you see anything we missed. If you see a feature you're keen to see implemented, chime in here and let us know. We only know if you tell us!

Contributors

If you're interested in contributing to any proposed tasked, please use this space to discuss the details and set requirements. Generally the process should go like this:

• Read through the Contributions Guide before you proceed
• Make a post below mentioning what you would like to contribute and build
• Use threaded comments to talk with other contributors to gather ideas and set requirements
• Create an new issue to to stake your claim on a feature, track progress, and of course keep everyone in the loop
• When ready, send a PR
• QA testing will begin asap and feedback will be provided

Expect critical feedback and constructive criticism during this process. Try to keep an open mind and don't take anything personally. Especially if your PR is rejected. The goal here is to write high quality code, and provide features that meets the demands of everyone using the library! We want to make sure we get it right!

[endigo9740]

I've seen several requests for Tailwind alternatives, such as Windi and UnoCSS:

• https://discord.com/channels/1003691521280856084/1003691521721245791/1008914371877011528
• https://www.reddit.com/r/sveltejs/comments/wmnkoi/comment/ik3yw0z/?utm_source=share&utm_medium=web2x&context=3
• https://www.reddit.com/r/sveltejs/comments/w8odl6/comment/iht0kth/?utm_source=share&utm_medium=web2x&context=3

As far as I'm aware we would need to create replacement plugins for each alternative:
https://github.com/Brain-Bones/skeleton/blob/master/src/lib/tailwind.cjs

Level of effort seems so so I advise we bump up priority for this. Leaning towards Windi first.

[niktek]

Overall agree with most of it, comments:

General -> libs - definitely need discussion as there are implications for packaging/tooling
Documentation -> don't see a need for a blog yet, it would only be saying stuff that should either be in the docs or should be a guest post somewhere off site for awareness/seo building.
Components:
-> File Button - wouldn't mind seeing a file drop zone as well so that any data structures for the file list to send to the backend are consistent.
->App Bar/Nav Bar - have been queried about this one a few times, so priority++
->Collapsible Hierarchy ala Mantine LHS menu, just feels like we would need this for docs sooner rather than later (in addition to page nav of RHS)

Couple of other things that I would like to discuss - defining a bit more clearly what is in and what isn't in Skeleton (or where it might sit in an alternative package). For instance I can see some upside for more presentation only components like Hero's/CTA's/PicLeftorRight Header boxes that aren't really components and more at the presentation layer, but could work really nicely with mdsvex//ssg based sites, especially if they play nicely with transitions/animations for instance. Likewise I would love to create a full complement of Login/Logout pages/components that might work with Lucia/SSO/OAuth providers as that would provide great developer value for getting a heavy project started etc.

[endigo9740]

General -> libs - definitely need discussion as there are implications for packaging/tooling

Agreed, I'm actually thinking what I'd rather do is rather than trying to reorg everything, that we just make accommodations for a couple things. Like doc-only components need to be grouped separately. Plus themes will be introduced to this direction soon. Otherwise I'm fine with keep the majority of the lib directory a flat list of components for the package.

Documentation -> don't see a need for a blog yet, it would only be saying stuff that should either be in the docs or should be a guest post somewhere off site for awareness/seo building.

Yep, agreed. I don't know that I mentioned it on the roadmap itself, but each group is prioritized by our preferred order of operation. That means blog is low on the priority list. My gut is telling me it should arrived around the v1.0 launch. Long form articles, tutorials, plus a place to host video tutorials would be valuable.

File Button - wouldn't mind seeing a file drop zone as well so that any data structures for the file list to send to the backend are consistent.

Yeah drop zone is a good idea. Could be a sibling component to the file button.

App Bar/Nav Bar - have been queried about this one a few times, so priority++

So far I only recall one request for this, as opposed to the 3-4 for Tailwind alts like Windi, but any request should come with some priority influence. I have some ideas for a UX/UI update for the doc site prior to v1.0 launch, so we might introduce this component FOR that to help dogfood it. I'd probably pair it with the app shell to be honest. Both would be useful for what I have in mind.

Collapsible Hierarchy ala Mantine LHS menu, just feels like we would need this for docs sooner rather than later (in addition to page nav of RHS)

Left/Right hand sidebar, right? The drawer supports right hand right now FYI. But yeah, collapsable sections goes along with the UX updates I have in mind to the docs.

defining a bit more clearly what is in and what isn't in Skeleton (or where it might sit in an alternative package).

Agreed, the roadmap is the start to this conversation. We built a lot of stuff in isolation the first 6 months, so right now I'm wanting to gauge what the public wants. The more feedback we can get (like yours) the better for that. As per dividing packages - I think a lot of what falls under the "Utilities" may quality for that (though maybe not dialog/toasts).

more presentation only components like Hero's/CTA's/PicLeftorRight Header boxes that aren't really components and more at the presentation layer, but could work really nicely with mdsvex//ssg based sites, especially if they play nicely with transitions/animations for instance.

Agreed, the biggest challenge we have with Skeleton is deciding if something NEEDS to be a component. Because Tailwind makes a lot of that really easy. Plus stuff like Daisy UI could potentially be plug and play with Skeleton. At that point we're just reinventing the the wheel. But, I think it makes sense to have everything we can over time, just a matter of priority.

Likewise I would love to create a full complement of Login/Logout pages/components that might work with Lucia/SSO/OAuth providers as that would provide great developer value for getting a heavy project started etc.

The concept of full page or app designs has crossed my mind. Seems to be a hot thing these days (even Tailwind does it with Tailwind UI). But again, definitely some foundational level stuff we should prioritize first. Then the rest can snowball from there.

[endigo9740]

Per #114

We should document what components currently use $$restProps as it's not immediately clear. Something like "this component can accept any standard native attribute", etc.

[niktek]

Just a note on the Windi support from their discord:

Might be worth investigating further once the engine migration is completed

[endigo9740]

I had that on my list to review soon, thanks Nik! May be worth waiting until v4 in that case, but could be a ways out, eh? Bummer.

I noted their current version only officially supports up to Tailwind v2. We're probably using some TW v3 features here and there that could pose some issue.

[endigo9740]

My be worth a read soon, could influence how we're doing some things. I'm pretty happy with how we manage state currently, but always room for improvement!

https://joyofcode.xyz/svelte-state-management