[DX][Components] Twig components case sensitivity / HTML syntax

[smnandre]

TL;DR; ⏲️

• Should we adopt a naming convention for component names in UX packages and documentation? If so, which one?
• Should all component names be case-sensitive?

Context 🔠

While working on UX Map, @Kocal raised a question during the discussion:

Should it be <twig:ux:map /> or <twig:UX:Map />? (I noticed you used UX:Map in the twig.component tag). Or is it case-insensitive?

During the development and early stages of UX Icons, @kbond and I decided to switch from <twig:Ux:Icon /> to <twig:ux:icon /> both in the code and in the documentation.

This change felt more natural for typing and reading in the documentation. Additionally, since "<twig" is lowercase, "<twig:ux" seemed more consistent to me. As a result, we made it case-insensitive.

However, this is the only place where it works this way, as user-land component names are still case-sensitive.

Suggestions 🗳️

I’d like to gather feedback from the team and community on the following points:

Symfony UX Components

• A0: Symfony UX component names (e.g., Map, Icon, and future ones) should be case-insensitive (in HTML syntax).
• A1: Symfony UX components should adopt a consistent casing style in documentation, code blocks, and social media.
• A2: Symfony UX components should use lowercase casing style in documentation, code blocks, and social media.

App/User-Land/Bundle Components

• B0: Twig/Live Component names should be case-sensitive (as these names may be used in events, logs, etc.).
• B1: [NEW] Twig/Live Component names should be unique in a case-insensitive form (preventing Acme:Foo and acMe:foo from being registered simultaneously).
• B2: [NEW] We could (later) suggest the correct name when a user misspells it, or even automatically map it to the correct one.

.

I’m inclined to answer "yes" to all these points.

Let’s discuss them and hear from you if there are any concerns. :)

[smnandre]

cc @Kocal @kbond @WebMamba :)

[Kocal]

Hey Simon, thanks for opening the discussion! 🙏🏻

Symfony UX Components

Personally I prefer the form <twig:UX:Map> over <twig:ux:map>, I find it more visually distinctive between native HTML tags. I may be biased by Vue.js style guide for components naming, but I've always preferred to use PascalCase over kebab-case for components usage. For React, I didn't find anything but the AirBnb's styleguide for React, and they use PascalCase aswell.

For me:

• A0: yes
• A1: yes
• A2: small no, as I prefer PascaleCase, but if everyone here prefer kebab case, let's go for kebab-case! EDIT: go for kebab-case!

App/User-Land/Bundle Components

• B0: yeah, why not
• B1: yes!
• B2: yes aswell

Thanks!

[seb-jean]

I answer like @Kocal for the 6 points. And for my part, I prefer PascalCase to lower-case.

[Kocal]

Updated A2, let's keep using kebab-case

[smnandre]

After some though, i see no problem we use both, as user can use both. So as long we do not change again for icon ( 😅 ) if you want to change for Map, or add some Kebad case in the documentation, I agree and am ok to give a hand if you want

After all..... we are not that many to contribute here, I think we can have double vote 😅

[smnandre]

Primer use PascalCase too, but i'm sure you now understand why i'd like to avoid it (now)

[kbond]

So, is the consensus that we'll use kebab for "official" components, but promote PascalCase for user-land ones?

And if this is the consensus, should https://github.com/symfony/ux/pull/2481 be changed to kebab-case?

[smnandre]

As you want guys, as long we do not need to refactor doc / website twice a year haha

[carsonbot]

Thank you for this suggestion. There has not been a lot of activity here for a while. Would you still like to see this feature? Every feature is developed by the community. Perhaps someone would like to try? You can read how to contribute to get started.

[carsonbot]

Friendly ping? Should this still be open? I will close if I don't hear anything.

[carsonbot]

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!