Is this project going to be typescript only?

[planetaska]

A lot of the documents and samples are only in typescript. This makes it really inconvenient to work with if our project is not in typescript. Is this project going to be typescript only?

[endigo9740]

@planetaska I don't believe any part of the project has a hard requirement for Typescript. We just tend to show our examples using it for two reasons:

1. We build Skeleton using Typescript, so in most cases it's the most natural way to document things
2. It's more useful to show examples with Typescript types, which can be removed, rather than without and leave folks guessing at how it should be utilized.

Take Conic Gradients for example:
https://skeleton.brainandbonesllc.com/components/conic-gradients

With a Typescript type added:

const conicStops: ConicStop[] = [
	{ label: 'Primary', color: 'rgb(var(--color-primary-500))', start: 0, end: 33 },
	{ label: 'Acccent', color: 'rgb(var(--color-warning-500))', start: 33, end: 66 },
	{ label: 'Warning', color: 'rgb(var(--color-accent-500))', start: 66, end: 100 }
];

Pure Javascript:

const conicStops = [
	{ label: 'Primary', color: 'rgb(var(--color-primary-500))', start: 0, end: 33 },
	{ label: 'Acccent', color: 'rgb(var(--color-warning-500))', start: 33, end: 66 },
	{ label: 'Warning', color: 'rgb(var(--color-accent-500))', start: 66, end: 100 }
];

Had we not included ConicStop[] in the examples people might not know this type was available for them to use. But for JS users, they just need to prune this. Pretty straight forward, right?

Unless there's an example you can reference that is not coming to my mind, this is really the only change needed to use this within a standard Javascript project. If I've missed something let me know and we can discuss though.

That said, I'd HIGHLY encourage the use of Typescript given the simplicity of setting it up in Vite/SvelteKit/Astro projects. Plus the benefits you get for strong typing in general. But obviously to each their own!

[planetaska]

Thanks for the detailed explanation! I think part of the issue is the documentation is not quite complete for some components - like the Dialog component - but that is understandable as it is still in development.

What I noticed (and some of my colleagues who's not a typescript user at all) is that: take the Dialog component for example,
https://www.skeleton.dev/utilities/dialogs

The doc has a section Dialog Variants, which is purely for typescript. But until we look carefully into it, we wouldn't realize these were for typescript only. So some colleagues (including me at first) will think we should use these to create a Dialog - which will not work in a vanilla Javascript environment.

import type { DialogAlert, DialogConfirm, DialogPrompt } from '@brainandbones/skeleton';

Because the import statement is actually importing types, for people not familiar with typescripts, they will not know they should just ignore the types. In our case, at a first glance, I didn't even notice the type and thought we were importing components.

But anyway, I think these issues can be addressed with a more clear statement in the docs for "typescript only" sections.

By the way, I noticed currently we have no way to add content to the Dialog component without passing HTML string directly to a dialogStore. Is this intentional and we have to use HTML string instead of a slot, or is the slot going to be added later?

Sorry I know that's a lot of questions. Thank you for answering and thank you for the hard work. Excellent project and I really hope to see it grow!

[endigo9740]

That makes sense. If you're not familiar with Typescript or new to JavaScript in general one may note be able to differentiate. Sounds like you've already started picking on it, but here's a few tips:

• Type imports include type as you mentioned. They're also capital case (ex: big D at the start of DialogAlert).
• Typescript types are the bits after :, so const foo: string means : string is the type. Leave that off for pure JS
• Additionally we do opt for ts (typescript) as the default for code blocks, but js (javascript) is available. It may be worth updating code blocks to only us ts when Typescript is actually present to be more explicit. I'll take that into consideration.

By the way, I do hope you had a chance to see the polls I setup. The results are interesting. There's more folks that prefer pure JS than I expected, but TS does dominate:

• 16/5 votes on Discord, with TS being favored
• 80%/20% from 32 votes on Twitter with TS being favored

If you don't mind some advice from someone that's been doing this stuff for 20+ years - Typescript isn't going away heh. The cat is out of the bag. If you and your team have the ability to learn it, I do recommend it. In fact, here's a course I've been hearing some buzz around if it helps!
https://www.totaltypescript.com/tutorials/beginners-typescript

Per Dialogs:

When setup properly the Dialog component will be in a completely different scope than where you're triggering it. We recommend you setup the Dialog component in the root layout, to put it in global scope. But slots are only accessible locally within the layout. What you're asking for is not possible, so passing markup through the store, which acts as an event bus, is really the only way to handle this for the current implementation.

That said, I have experience with Angular Material's dialog system and they have a novel approach to this. They allow for creating custom "templates" (components in our case). These could be triggered on demand and replace the standard structure. I have already created a proof of concept of this, but it's not fully flushed out yet. If this sounds interesting please see the ticket linked below. This is an upcoming refactor for the feature that may include additions like this. I'd recommend making a comment explaining your desire for this or similar features:
#197

Thanks for the feedback though. We can't always facilitate every request, but sometimes it can help inform future decisions. I'll keep everything mentioned in mind going forward!

[endigo9740]

If it helps, here's a visualization of how the current dialog store works.

• Dialog component is implemented once in the root layout
• The store is shared between the layout and any page
• Any page can trigger the dialog to appear via the blue arrow path (the .trigger() method)
• The Dialog slots (green) are only accessible in the root layout. Not accessible to the various pages

[planetaska]

Thanks for the reply! I use a little typescript in my personal projects, but for projects that's not in my control, sometimes ts is just not an option (not everyone is willing to learn it, not every project has ts support, the owner may not want to add ts to the stack, other times the client's own dev just refuse to receive ts code). But not every project needs to use Skeleton, so I think it is fine!

For the Dialog, interestingly I also faced a similar situation for another Svelte calendar component library - it has the same 'decision' where you need to pass pre-structured HTML string into a calendar cell. For that case I created DOM elements with js and use the root element to output the generated HTML string (it is dynamic content). I think I can do the same thing here. It's just writing HTML template is easier when the content or structure needs to be updated. I have subscribed the ticket you linked and will provide feedback when needed.

Anyway, I appreciate the detailed answers, and can't wait for the 1.0 release!

[endigo9740]

Oh absolutely, I meant to say something along those lines in fact. I've certainly been a part of projects where Typescript wasn't an option. But still wanted to encourage it because it's valuable info to have, even if it's just for knowing what to strip for Skeleton examples.

Yeah, template literals can you get pretty far when passing HTML around. The only limitation is that components are not allowed. We're facing the same dilemma with Data Tables, so you might have noticed another ticket related to that. Having too much to do is a good problem to have for a project like this though :)

Well glad you've been giving Skeleton a shot though, and thanks again for the feedback!

By the way, don't be afraid to stop by our Discord if you get a chance. We have several contributors there. A few folks just submitting ideas and being a part of the discussion. We need that just as much as folks submitting code. All are welcome!

[endigo9740]

By the way, you're only the second person to raise this concern since we launched the project, but I do take this kind of comments seriously. Out of curiosity I'm running a poll on Twitter and Discord asking people which they prefer:

https://twitter.com/SkeletonUI/status/1580591588438577153
https://discord.com/channels/1003691521280856084/1003691521721245788

Feel free to participate, but I'm hoping this sheds light on how people are using and prefer to use these technologies.

Either way thanks for reaching out on this!