novacbn / kahi-ui

Straight-forward Svelte UI for the Web
https://kahi-ui.nbn.dev
MIT License
187 stars 5 forks source link

a few suggestions #22

Closed samuelstroschein closed 3 years ago

samuelstroschein commented 3 years ago

Finally, a Svelte UI lib that's somewhat similar to Chakra UI!

A few suggestions:

  1. I am missing passing CSS as property as in Chakra UI.

<Button marginLeft={2} height="500px">Click me</Button>

which eliminates the need for CSS/TailwindCSS.

  1. Why do you use underscores for properties e.g. alignment_x instead of standard camelCase e.g. alignmentX?

  2. Most websites use CMD+K to open the search bar. The documentation site should probably follow that convention.

  3. Why both is and type properties?

  4. Use Link instead of Anchor. Most UI Libs use Link which is shorter and makes more sense -> everyone says link right? Maybe more generally, why not copy all Chakra props, naming, and conventions?

novacbn commented 3 years ago

Thanks for taking an interest in the library!

  1. I am missing passing CSS as property as in Chakra UI. ...which eliminates the need for CSS/TailwindCSS...

I've been considering being able to pass CSS values as a shortcut. That being said, I wont be dropping the built-in stylings via CSS files. Since one of my use cases is using the CSS in backends without scripted frontends.

  1. Why do you use underscores for properties e.g. alignment_x instead of standard camelCase e.g. alignmentX?

My preference for attribute / property stuff is kebab case (e.g. alignment-x), and you can't really export like so AFAIK:

<script>
    export let alignment-x = ...;

    // not this either
    let alignment_x = ...;
    export {alignment_x as alignment-x};
</script>

I could've use $$props["alignment-x"], but at the time you couldn't add TypeScript annotations to it. So I kept it the way it was. Maybe in the future will change into proper kebab case.

  1. Most websites use CMD+K to open the search bar. The documentation site should probably follow that convention.

Yep. I just haven't gotten around to stuff like hotkeys and auto focusing yet.

  1. Why both is and type properties?

is="..." is for selecting HTML tags where appropriate, e.g. <Heading is="h3">. Functionality working as as=".." in supporting Components. In some cases like with <Button>, other properties to me, better signal the intent like <Button href="...">. Since only <a> elements would have that attribute. So I kept that as a shortcut.

type="..." is purely for changing <input type="..." /> since those aren't separate elements.

  1. Use Link instead of Anchor. Most UI Libs use Link which is shorter and makes more sense -> everyone says link right? Maybe more generally, why not copy all Chakra props, naming, and conventions?

Generally I try to stick to nomenclature of the underlying HTML element, if applicable. e.g. <Anchor> -> <a>, <Card.Section> -> <section>. IMO, I don't see a reason to change from that.

On the point of Chakra / others. My intent isn't to copy the API and to work as a Svelte port. So while I might look for inspiration from those libraries. Some things might turn out different due to personal preference.

samuelstroschein commented 3 years ago

Thanks for the in-depth reply.

  1. Why do you use underscores for properties e.g. alignment_x instead of standard camelCase e.g. alignmentX?

My preference for attribute / property stuff is kebab case (e.g. alignment-x), and you can't really export like so AFAIK:

<script>
    export let alignment-x = ...;

    // not this either
    let alignment_x = ...;
    export {alignment_x as alignment-x};
</script>

I would prefer regular camelCase nonetheless. Kepab-case okay, similar to CSS properties but seeing snake_case in Javascript just "seems wrong".

  1. Use Link instead of Anchor. Most UI Libs use Link which is shorter and makes more sense -> everyone says link right? Maybe more generally, why not copy all Chakra props, naming, and conventions?

Generally I try to stick to nomenclature of the underlying HTML element, if applicable. e.g. <Anchor> -> <a>, <Card.Section> -> <section>. IMO, I don't see a reason to change from that.

Understandable but if most UI libs use nowadays, I think Kahi should not deviate especially considering that one might not immediately identify <Anchor> as <a>in contrast to e.g. <Section> -> <section> .

On the point of Chakra / others. My intent isn't to copy the API and to work as a Svelte port. So while I might look for inspiration from those libraries. Some things might turn out differently due to personal preference.

Related to the previous point: I would try to stick to the API of other popular UI libs. Developers coming from React, Vue etc. will adopt a Svelte UI lib with familiar API more likely. Generally, a proper UI lib (that is not IBM carbon) is one of the last bigger "things" that are a barrier to use Svelte. Whoever builds (copies) ChakraUI (clean API + pre-styled components) for Svelte will make money. I have not come across any better UI lib than Chakra yet. The GitHub stars seem to confirm that observation. Therefore, I would copy the API instead of trying to come up with yet another API for a UI lib.

novacbn commented 3 years ago

I would prefer regular camelCase nonetheless. Kepab-case okay, similar to CSS properties but seeing snake_case in Javascript just "seems wrong".

To be fair, camelCase seems to be a React-centric way of doing things. In a lot of Vue libraries I looked at used kebab-case in templates. Including chakra-vue. So I don't think kebab-case will be completely out of the norm.

...The GitHub stars seem to confirm that observation. Therefore, I would copy the API instead of trying to come up with yet another API for a UI lib...

When looking at other very popular UI libraries, I noticed most of them have different similar-but-different naming schemes / APIs. Which suggests to me, as long as you keep naming contextually understandable and documented, it shouldn't be a problem.

Heck, the very popular Ant Design which has even more stars than Chakra UI, has an Anchor Component which seems to be div wrappers around of Link Components (effectively Anchor.Link).