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

[FEATURE ember-routing-linkto-target-attribute] #4718

Conversation

selvagsz
Copy link

Taking up the row of #3924 . Supports target attribute for the link-to anchor element

@@ -427,7 +427,14 @@ var LinkView = Ember.LinkView = EmberView.extend({
_invoke: function(event) {
if (!isSimpleClick(event)) { return true; }

if (this.preventDefault !== false) { event.preventDefault(); }
if (this.preventDefault !== false) {
if (Ember.FEATURES.isEnabled("ember-routing-linkto-target-attribute") && !this.get('target')) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the feature flags to be stripped by defeatureify you can not combine logic (it only looks for the single conditional).

Also, both sides of this are doing the same thing, is the conditional needed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops that was my bad!! those lines has to be

if (Ember.FEATURES.isEnabled("ember-routing-linkto-target-attribute")) {
  if(!this.get('target')) {
    event.preventDefault();
  }
} else {
  event.preventDefault();
}

The preventDefault should not happen when a target attribute is provided

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, that makes sense.

@selvagsz selvagsz changed the title [FEATURE] Support target attribute for link-to helper [FEATURE ember-routing-linkto-target-attribute] Apr 14, 2014
@jayphelps
Copy link
Contributor

💯 I'm currently injecting this ability into LinkView so I'm very excited for this.

@stefanpenner
Copy link
Member

can you add tests?

@selvagsz
Copy link
Author

@stefanpenner Added the test cases. I do have a query.
Do i need to preventDefault target='_self'? It's the default one if there is no target attribute specified.

@jayphelps
Copy link
Contributor

@selvagsz @stefanpenner IMO since I'm using similar functionality in my apps: I chose to have it behave just like as if you didn't include it. i.e. it does still preventDefault. The reason why was that you can use {{link-to "Go Here" "some.place" preventDefault=false}} and I think that's much more clear to accomplish that behavior. Also, as you said, _self is the default target if one isn't provided so in my mind, it shouldn't make any difference to ember either.

@selvagsz
Copy link
Author

@jayphelps Thanks for your suggestion. Updated my PR now

@tomdale
Copy link
Member

tomdale commented Apr 18, 2014

So, we're going to merge this. I was opposed at first because I was afraid that this was a slippery slope, due to:

  1. {{link-to}} can take a tagName attribute, allowing it to become an arbitrary element.
  2. At that point, developers would be right in asking for any arbitrary attribute to be supported by the {{link-to}} helper.

However, given some of the new capabilities coming in HTMLbars, there should no longer be any need to use {{link-to}} with a custom tagName. So long as we keep the attributes limited to those used by the a element, I'm happy with that.

@selvagsz
Copy link
Author

Does this need anything else to get into the beta train

stefanpenner added a commit that referenced this pull request Apr 19, 2014
…te_for_linkto

[FEATURE ember-routing-linkto-target-attribute]
@stefanpenner stefanpenner merged commit 1670833 into emberjs:master Apr 19, 2014
@stefanpenner
Copy link
Member

@rjackson please pull into beta

@selvagsz selvagsz deleted the feature_support_target_attribute_for_linkto branch April 19, 2014 12:44
@rwjblue
Copy link
Member

rwjblue commented Apr 23, 2014

@stefanpenner - Generally speaking we do not add new feature flagged items to the beta branch. We would normally enable by default on master/canary then let it roll to beta at the next cycle. Do you think we need to circumvent that in this case?

@stefanpenner
Copy link
Member

@rjackson i have no idea why i said that

@stefanpenner
Copy link
Member

please don't listen to me

@jayphelps
Copy link
Contributor

@stefanpenner

IM NOT LISTENING

@stefanpenner stefanpenner mentioned this pull request Apr 25, 2014
8 tasks
@leostera
Copy link

👍

@tomdale
Copy link
Member

tomdale commented Jul 11, 2014

This was go-ed at today's core team meeting.

@selvagsz
Copy link
Author

Thanks 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants