Move to <PascalCase /> components

[patrick-steele-idem]

Currently, Marko does not enforce any restrictions on naming a component. That is, a UI component can be all lower case, all upper case, have dashes, not have dashes, etc. React JSX utilizes <PascalCase> for component tag names. Glimmer.js is also moving to <PascalCase> component tag names and their reasons are clearly explained in the Glimmer.js Progress Report.

After some initial discussions, we believe there are very strong reasons for also moving to <PascalCase> tag names:

• Improved syntax highlighting in editors/IDEs
• The Custom Elements spec has adopted the convention of requiring a dash in the tag name and this makes it ambiguous if a custom tag in a .marko file is for a Marko UI component or a Custom Element.
• Familiarity: React JSX is considered the "industry standard" by many
• The rules for compile-time validation of custom tags can be improved as shown below:
  • <invalidtag> - ERROR! This tag name is all lower case and has no dashes, but is not part of the HTML spec.
  • <valid-custom-element> - No error. We will assume this is a Custom Element because it is all lowercase and there is at least one dash in the name
  • <InvalidMarkoComponent> - ERROR! It looks like this should be a custom tag for a Marko UI component but the Marko UI component cannot be found.

The following things will need to happen to move to the <PascalCase> naming convention:

• [ ] Show deprecation warnings when we find that a Marko UI component uses lowercase in the first character
• [ ] Show deprecation warnings when we find <my-component> (non-PascalCase) tag names in a .marko file
• [ ] UI components need to be registered with both cases:
  • components/my-component/index.marko will register both <my-component> and <MyComponent>
  • components/MyComponent/index.marko will register both <MyComponent> and <my-component>
• [ ] The Marko core team needs to provide a migration tool that will automatically rename all files/directories and update .marko files to use the new Pascal case
• [ ] Syntax highlighting grammar should be updated to highlight <PascalCase> tag names
• [ ] Update documentation
• [ ] Update all sample projects

Cons:

• More shift key 😔
• Deprecation warnings and annoyance for existing Marko users

[yomed]

Sounds like a lot of good reasons to move to PascalCase, and I agree it's probably the best way forward. I think the cons are mostly around the transition from existing conventions. For example, in some of the projects I work with there is a convention around using a single letter prefix, which will become very awkward with this new style. E.g. s-search-bar -> SSearchBar?

[jasonmacdonald]

I agree with the idea, but we too are using a hyphen approach for name-spacing, so we'll need to refactor a lot of components if this is "forced". But, that being said, it probably is the right direction. We'll deal with the limitation and refactor when/if it is implemented.

[maxmilton]

Rather than enforcing a particular coding standard at the library level it may be a better idea to create a eslint-marko plugin. This way you can set sexy defaults but still allow developers the freedom to choose if they so wish.

Something similar happened recently in the Vue community and we now have https://vuejs.org/v2/style-guide/ and https://github.com/vuejs/eslint-plugin-vue which both work remarkably well for the majority of devs I interact with.

In particular you may want to see https://vuejs.org/v2/style-guide/#Single-file-component-filename-casing-strongly-recommended and https://vuejs.org/v2/style-guide/#Component-name-casing-in-templates-strongly-recommended .

Renaming existing components is not really that big a deal, even with 1000s of components it's doable.