Directive using short-hand syntax to generate hrefs

[timkindberg]

Add a directive that understands the same short-hand syntax as issue #15 and can be used to generate hrefs.

<a ui-state-ref="@edit">Edit</a>

[jeme]

We need to remember Parameters as part of this... Like in the state that i Bound to '/item/:itemId'...

[timkindberg]

This needs more explanation, what is going on in your code example?

[jeme]

Like the state defined in the example:

 .state('contacts.detail.item', {
      // parent: 'contacts.detail',
      url: '/item/:itemId',
      views: { ... },
      },
    })

We can't just go at <a ui-state-ref="@item">{{item.title}}</a> or <a ui-state-ref="contacts.detail.item">{{item.title}}</a> because what "item" is it we wan't to open?... So it needs some way of binding that item parameter so it becomes:

<a href="#/item/2" ui-state-ref="@item">One</a>
<a href="#/item/3" ui-state-ref="@item">Two</a>
<a href="#/item/4" ui-state-ref="@item">Three</a>

or

<a href="#/item/2" ui-state-ref="contacts.detail.item">One</a>
<a href="#/item/3" ui-state-ref="contacts.detail.item">Two</a>
<a href="#/item/4" ui-state-ref="contacts.detail.item">Three</a>

In any case, contacts.detail.item requires an input parameter which is itemId
Normally you would do something like:

<a href="#/item/{{ item.id }}">{{item.title}}</a>

That would go in line with what $IgorMinar said in #7 :

we also need to be able to generate these urls so that they don't have to be handcrafted in templates.

Or have I completely misunderstood where you where going with this feature?...

[timkindberg]

Oh ok, its like href but for states. In case you want to navigate to a state (without using urls) via a directive. So I think @ksperling was saying that if it started with a '@' it would be relative.

So this one would go to edit state relative to current state, just like a relative url. So if we were in contact.list.details, this would take you to contact.list.details.edit.

<a ui-state-ref="@edit">Edit</a>

<!-- I think I would prefer one of these more though -->
<a ui-state-ref=".edit">Edit</a>
<a ui-state-ref="/edit">Edit</a>

And this one would go to absolute state called "edit"

<a ui-state-ref="edit">Edit</a>

[jeme]

Still leaves the parameters though, edited the examples...

[timkindberg]

ah ok I get it now, the parameters...We could have the ui-state-ref string be interpolated so the state name could be dynamic. Then a seperate directive for parameters (kind of yuck). Would the parameters be interpolated too?

Would think we could just do something like this:

<a ui-state-ref="{{$scope.someStateName}}" ui-state-ref-params="{id: item.id, otherParam: item.otherValue}">Edit</a>

Or maybe combine them, separated by a bar.

<a ui-state-ref="{{$scope.someStateName}} | {id: item.id, otherParam: item.otherValue}">Edit</a>

The truth is that people are most likely going to use URLs 95% of the time, so I think its ok that this is more verbose than that.

Also, I'm not entirely sure what Igor is getting at.

[nateabele]

Keep in mind, if we're doing our own directive, we can do our own (simple) parser. We're not constrained by valid JavaScript. For example:

<a ui-state-ref="@edit(id: item.id, otherParam: item.otherValue)">Edit</a>

That should be pretty comprehensible and easy to parse.

[ksperling]

Yes, parameters definitely need to be supported. I was thinking these would be resolved based on the current state, i.e. any parameter that the target state has but that's not specified keeps it's value from the current state.

I'm hoping this directive will be as easy to use as hard-coding an href, and it will have the advantage of being more DRY. If the directive is used consistently, you should be able to completely change the URL pattern of a state, and all links will change to match.

A custom parser is an option, but would probably not be my first choice. I think it should work in a way that somebody familiar with Angular expressions can just use without having to think too much about.

[michaelwinser]

Can you provide some scenarios for the parameter "rollover" you just
described. It feels like a debugging nightmare in the making.

Michael
On Feb 16, 2013 4:01 PM, "Karsten Sperling" notifications@github.com
wrote:

Yes, parameters definitely need to be supported. I was thinking these
would be resolved based on the current state, i.e. any parameter that the
target state has but that's not specified keeps it's value from the current
state.

I'm hoping this directive will be as easy to use as hard-coding an href,
and it will have the advantage of being more DRY. If the directive is used
consistently, you should be able to completely change the URL pattern of a
state, and all links will change to match.

A custom parser is an option, but would probably not be my first choice. I
think it should work in a way that somebody familiar with Angular
expressions can just use without having to think too much about.

—
Reply to this email directly or view it on GitHubhttps://github.com/angular-ui/router/issues/16#issuecomment-13674818.

[ksperling]

Obviously parameter values need to be able to be computed via expressions. I think it's probably OK if the target state name is just taken literally.

[ksperling]

@michaelwinser the best example is probably linking between states that share a parent state. In that case the parameters that belong to those shared ancestors should not need to be specified.

In the current sample app for example, I'd like to be able to link from contact.details to contact.details.item without having to explicitly say ... contactId: $stateParams.contactId...

In fact it may be a good idea to restrict this 'rollover' to only parameters of shared ancestors of the current and targeted states.

[michaelwinser]

I think we're thinking along the same lines. I think parent parameters
should be available to all active child states.

Michael
On Feb 16, 2013 4:15 PM, "Karsten Sperling" notifications@github.com
wrote:

@michaelwinser https://github.com/michaelwinser the best example is
probably linking between states that share a parent state. In that case the
parameters that belong to those shared ancestors should not need to be
specified.

In the current sample app for example, I'd like to be able to link from
contact.details to contact.details.item without having to explicitly say ...
contactId: $stateParams.contactId...

In fact it may be a good idea to restrict this 'rollover' to only
parameters of shared ancestors of the current and targeted states.

—
Reply to this email directly or view it on GitHubhttps://github.com/angular-ui/router/issues/16#issuecomment-13675034.

[ludinov]

Could it be just like:

ui-href="@edit/{{itemId}}"
ui-href="admin.user.edit/{{itemId}}"
ui-action="@submit" // for forms to add fields values to params, but not in the url

[ksperling]

I think the directive should deal with the parameters as an object, rather then via string interpolation (which would then have to be parsed back into a structured representation).

Can you elaborate on how/why you'd want to do "form submission" into state parameters?