Proposal: Replace ui-router-specific implementation w/ generic implementation

[jeme]

Proposal:

Currently Angularjs Material has code that is tightly coupled to UI-Router, while the code in it self isn't really harmful, it provides the question, what about the next router, what about the next custom link directive etc...

This simply isn't generic...

Instead, provide a way to override the behavior, e.g. by a service service/provider where users of Angularjs Material can change how Angularjs material figures out when a button should be a link etc...

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

Making the framework more generic and loosen up the tight coupling to e.g. UI-Router. Allowing for integration to other custom made directives etc. which are suppose to indicate links and so on.

Which versions of AngularJS, Material, OS, and browsers are affected?

v1.1.8

Is there anything else we should know? Stack Traces, Screenshots, etc.

I wanted to submit this as a proposal PR instead of just an issue, but I ran into some ambiguities which requires me to understand the meaning behind before I proceed.

Button definition of isAnchor:

• https://github.com/angular/material/blob/master/src/components/button/button.js#L128

Button use of isAnchor:

• https://github.com/angular/material/blob/master/src/components/button/button.js#L133
• https://github.com/angular/material/blob/master/src/components/button/button.js#L151

List Item use of detection:

• https://github.com/angular/material/blob/master/src/components/list/list.js#L245

List Item attr copy:

• https://github.com/angular/material/blob/master/src/components/list/list.js#L408

Menu Service Provider:

• https://github.com/angular/material/blob/master/src/components/menu/js/menuServiceProvider.js#L352

NavBar insertion if attributes:

• https://github.com/angular/material/blob/master/src/components/navBar/navBar.js#L410
• https://github.com/angular/material/blob/master/src/components/navBar/navBar.js#L428
• https://github.com/angular/material/blob/master/src/components/navBar/navBar.js#L432
• https://github.com/angular/material/blob/master/src/components/navBar/navBar.js#L458

---

The last one is probably the most challenging one as it adds bindings etc... But it shouldn't be impossible to make a more flexible design.

But what i don't get is the different ways that "links" are detected:

//button:
angular.isDefined(attr.href) || angular.isDefined(attr.ngHref) || angular.isDefined(attr.ngLink) || angular.isDefined(attr.uiSref);

//list item:
tAttrs.ngClick || tAttrs.ngDblclick ||  tAttrs.ngHref || tAttrs.href || tAttrs.uiSref || tAttrs.ngAttrUiSref

//menu service provider
(hasAnyAttribute(target, ['ng-click', 'ng-href', 'ui-sref'])

etc...

It would be much appreciated if anyone was able to explain that... Then perhasp I could start on a PR

[Splaktar]

Thank you for submitting an issue before doing a lot of work on a PR. We're certainly going to have to be careful when considering any change of this magnitude. We need to evaluate if these changes would require breaking changes to the API, CSS, etc. If so, then they would need to be pushed to 1.2.0, which currently has an unknown date.

As you have indicated, it looks like link detection is inconsistent across the different components. This is unfortunately true of quite a few things.

It may be wise to first submit a PR to make link detection consistent across components and ensure that there are sufficient unit tests in place to verify this functionality. That would make it easier to consider adding more generic support due to the reduction in some of the risk.