Drop camelCase to kebab-case auto-conversion for CSS classes about surface HOT 14 CLOSED

@neilberkman just to make it clear, you should be able to use "clipboard__icon" today if you write the key as a string, so:

<div class={{ "clipboard__icon" => true }}>

should be translated to:

<div class="clipboard__icon">

Pay attention that "clipboard__icon": true is different from "clipboard__icon" => true. In the former the key is an atom, in the latter, the key is a string.

In case the above doesn't work as expected, we have a bug so please let me know.

from surface.

Personally I quite like the auto-conversion feature, and I think it makes perfect sense when you think about conventions around CSS classes. As long as it's called out in the documentation clearly I think it's fine.

Alternatively you could use underscore-case -> kebab-case conversion instead; if anything I think that makes even more sense since you're going from idiomatic elixir naming to idiomatic CSS naming.

from surface.

All right, folks!

I've decided to drop the automatic camel-to-kebab conversion. For those that like this feature, I'm willing to find another way to provide similar behaviour by maybe adding a built-in function or some kind of modifier to make its use explicit.

The next alpha version should be released already without it.

Thank you all for the fantastic feedback!

from surface.

Another option would be to make this a config setting, or something passed as a __using__ option? e.g:

use Surface, convert_classes: false

from surface.

for what it's worth, I prefer to just specify the css class name without any conversion

the underscore to kebab case conversion would cause issues with BEM style CSS if i'm not mistaking what you're suggesting

from surface.

the underscore to kebab case conversion would cause issues with BEM style CSS if i'm not mistaking what you're suggesting

We're encountering this now: #50 (comment)

from surface.

I recognize that those names wouldn't be idiomatic elixir; however I feel like the edge cases get fairly extensive when we start converting things; and as the names are technically css and not elixir the non-idiomaticness doesn't bother me too much

from surface.

@msaraiva Speaking to your point about feature causing confusion, I've had to pull up the docs to check how to do it multiple times because it doesn't feel natural to me. So I'm sympathetic to that concern.

I do like the ability to include a class with a boolean value (or function call) so I want the ability to remain, but the implementation and API are fine to change for me. I'm not using any CSS libraries that have issues with it.

from surface.

Another option would be to make this a config setting

@wrren I would avoid a config for that as much as possible since it doesn't solve the issue of confusion. I'm inclined to drop the feature unless we can make sure that improving the docs/examples will be enough.

I'll merge #51 in the meantime and wait for more feedback to make a final decision about dropping the feature.

Thank you all for your comments ❤️

from surface.

Personally I didn't used the auto-convert. I think the argument to support isn't sufficient. There are many ways to write css class names, Im using tailwindcss for example. So to support one way of writing class names that cause so many problems seems unnecessary. Hope my input helps :)
On related topic, can I do something like that?

some_classes = "class_1 class_2 .." 
<div class={{ ^some_classes => true }}>

from surface.

@mazz-seven thanks for the input.

Regarding the suggested code, it's currently not possible. The closest thing I can come up with, in case you'll alway use true, is:

some_classes = [:class_1, :class_2, ...] 
<div class={{ some_classes }}>

However, I'm not sure which other cases you want to cover, so this is probably not what you're looking for.

from surface.

I'd vote for no automatic conversion.

Absinthe has auto camelCase conversion for graphql queries and there have been many questions from people wondering what happened to their field names. Absinthe allows users to override it, and have good docs, but it has still surprised many people.

I understand why they did it, and appreciate it in their case.. but I would not enjoy it as much for css... I'd just prefer it to be what I think it is.

from surface.

I'm in favor of not automatically kebabing or to at least provide an escape hatch. I am using an existing style sheet that I'm writing components for and it mixes use of kebab and camel cases.

from surface.

Resolved in #62. Thanks @zamith!

from surface.