Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document why some attribute directive are dash-case and some are camelCase #3125

Open
thekalinga opened this issue Feb 16, 2017 · 6 comments
Labels
area: many Area label for issues related to many components docs This issue is related to documentation needs: discussion Further discussion with the team is needed before proceeding P4 A relatively minor issue that is not relevant to core functions

Comments

@thekalinga
Copy link

thekalinga commented Feb 16, 2017

Bug, feature request, or proposal:

Currently there is a confusion as to why mdInput is an attribute directive [which is the reason why it is written as mdInput instead of md-input] & md-button is a component

Since md-button(and other button variants) are used only as html attributes, it would be easy for the user's mental model if he can write

<button mdButton> instead of <button md-button> similar to <input mdInput>

What is the expected behavior?

Ability to use button variations using camelCase such as <button mdButton>

What is the current behavior?

All button variations needs to be used using kabab cased attribute <button md-button>

What is the use-case or motivation for changing an existing behavior?

Now the user needs to know how button is implemented (which is why it is kabab case instead of camel), instead end user should not care how it is implemented, instead just knows elements follow kabab case & directives follow camelCase.

This way, the implementation detail does not leak to end user

The mental model of "html element => component", "html attribute => directive" is easy to remember & intuitive for most angular developers.

Which versions of Angular, Material, OS, browsers are affected?

2.0.0-beta.2

@thekalinga thekalinga changed the title Make md-button & other buttons attribute directives (mdButton) instead of components Make md-button & other buttons look like mdButton along the lines of mdInput Feb 16, 2017
@thekalinga thekalinga changed the title Make md-button & other buttons look like mdButton along the lines of mdInput Make md-button & other button usage look like mdButton along the lines of mdInput Feb 16, 2017
@thekalinga thekalinga changed the title Make md-button & other button usage look like mdButton along the lines of mdInput Make md-button & other button usage look like mdButton along the lines of mdInput Feb 16, 2017
@thekalinga thekalinga changed the title Make md-button & other button usage look like mdButton along the lines of mdInput Make md-button & others usage look like mdButton along the lines of mdInput Feb 16, 2017
@PowerKiKi
Copy link
Contributor

As a new user of material (but familiar with Angular 1 and Material 1) this difference is hard to understand at first glance. And it looks like material naming is incoherent since both mdInput and md-button are used in the same way, as attributes, but are cased differently. So at first I'd like them to be renamed too.

However renaming them would go directly against the official style guide about custom prefix for components and attribute directives. Not sure what the best of course of action would be...

@michael-lang
Copy link

+1 to migrate to mdButton for consistency.

@bradyshutt
Copy link

Does the latest release (2.0.0-beta.10) fix this issue?
The first item under Deprecations says:

All dash-case @ Directive selectors are deprecated in favor of the camelCase equivalent. The
dash-case selectors will be removed in a subsequent release. Some examples include:

md-line ---------------> mdLine
md-tab-link ----------> mdTabLink
md-tab-label --------> mdTabLabel
md-card-avatar ----> mdCardAvatar

@jelbourn jelbourn added the docs This issue is related to documentation label May 9, 2018
@jelbourn jelbourn changed the title Make md-button & others usage look like mdButton along the lines of mdInput Document why some attribute directive are dash-case and some are camelCase May 9, 2018
@jelbourn
Copy link
Member

jelbourn commented May 9, 2018

The current behavior is that @Components are dash-case and @Directives are camelCase. The reasoning is that an element can only have one @Component, but multiple @Directive instances. So you can tell by looking at <button mat-button matTooltip="Hello"> that MatButton is the @Component, and all of the unprefixed attributes (disabled, color, disableRipple, etc.) apply to that, while MatTooltip is a directive and its properties would all be prefixed with matTooltip

@jelbourn jelbourn added the P5 The team acknowledges the request but does not plan to address it, it remains open for discussion label May 9, 2018
@mmalerba mmalerba added needs: discussion Further discussion with the team is needed before proceeding and removed discussion labels Mar 3, 2020
@thw0rted
Copy link

Just came from #18606. I think confusion arose there because the docs agree with @jelbourn, telling you to use camelCase directives, but the example for the same components shows the directives in dash-case (<mat-icon mat-list-icon>folder</mat-icon>).

Would it make sense to resolve this issue by reviewing the docs to ensure that both the Overview and Example tabs of each component consistently use these case conventions?

@jelbourn jelbourn added P4 A relatively minor issue that is not relevant to core functions and removed P5 The team acknowledges the request but does not plan to address it, it remains open for discussion labels May 28, 2020
@jelbourn
Copy link
Member

Yes, a docs review would be useful to make sure we're not using any deprecated selectors (we didn't have this rule totally internalized when we first started, and some of the old inconsistent APIs stuck around).

@andrewseguin andrewseguin added the area: many Area label for issues related to many components label Jun 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: many Area label for issues related to many components docs This issue is related to documentation needs: discussion Further discussion with the team is needed before proceeding P4 A relatively minor issue that is not relevant to core functions
Projects
None yet
Development

No branches or pull requests

8 participants