feat(uiState): add ui-state directive

[kasperlewau]

ui-sref with dynamic state/option/param pointers.

Usage:

<a ui-state="state" ui-state-params="params" ui-state-opts="opts">
  Link
</a>

$scope.state = 'myStateName';
$scope.params = { id: 5 };
$scope.opts = { reload: true };

The resulting href would be pointed to myStateName({ id: 5 }) and $state.go would be called with reload: true.

---

It's also possible to specify the params straight into the ui-state directive as such:

<a ui-state="stateWithParam"></a>

$scope.stateWithParam = 'myStateName({ id: 10 })';

---

I started off writing this as a completely standalone directive, but given that it is desirable for it to work much like ui-sref, I felt there was too much duplication going on. ui-state can therefore be seen as a wrapper around the behaviour of ui-sref, nothing more to it really.

Now, this thing is heavy on the $eval and slightly so on the $watch side of things, so if someone has any nifty ideas on how to make that performant (I have not tested the performance aspects of ui-state in depth), that'd be super sweet.

---

Do let me know if you think there's a test missing among the added ones - I can't say I'm 100% certain that I've tested every aspect of a 'dynamic ui-sref directive'.

Reference issues: #395 #900
Suggested implementation

[nateabele]

s/propertys/properties/

[kasperlewau]

I'll get on it asap, thanks for the catch :)

[nateabele]

Hey, thanks for pulling this together! I made a couple of comments, but barring those it looks good to me. @christopherthielen Any comments?

[christopherthielen]

I like the effort to reuse the existing ui-sref code for ui-sref-active, (hopefully that works). I'll have to play with this for a while before I can comment on the implementation.

[kasperlewau]

Hmph. No sauce. evaluating the full array will always return undefined.

I can think of a couple of ways to achieve the expected result and move away from concatenation:

  return [scope.$eval(attrs.uiState), scope.$eval(attrs.uiStateParams), scope.$eval(attrs.uiStateOpts)];

  return [scope[attrs.uiState], scope[attrs.uiStateParams], scope[attrs.uiStateOpts]];

  return [attrs.uiState, attrs.uiStateParams, attrs.uiStateOpts].map(function (prop) {
    return scope.$eval(prop);
  });  

thoughts?

[nateabele]

Hmph. No sauce. evaluating the full array will always return undefined.

Yeah, I just realized I was looking at it wrong... hmm...

I can think of a couple of ways to achieve the expected result and move away from concatenation:

I'm not so much worried about the syntax as I am about the performance. Trying to think of how we can get it down to one $watch() / $eval(). Those are going to add up really quickly. I wonder if attrs.$observe() would be any cheaper...

I'll test it out when I have time, unless you beat me to it.

[kasperlewau]

I'll see if I can come up with some way of cutting it down to a single $eval, not sure what that would look like though.

Regarding attrs.$observe vs scope.$watch - I do believe that the former is slightly faster, but I'm not 100% on that one. In any case I think the difference would be negligible, it's the amount of $eval's that are worrying.

[kasperlewau]

Reverted back to using 3x $eval, so as to get a passing build. Still haven't figured out a better way to evaluate the three values without three consecutive calls to $eval or $parse (albeit I haven't worked on this full time...).

[kasperlewau]

Unfortunately I have still not been able to figure out a way to run a single $eval call for three separate expressions - without parsing possible objects into JSON and then concatenating the strings.

I did clean up the code ever so slightly in the $watch fn expression from:

return [
  scope.$eval(attrs.uiState),
  scope.$eval(attrs.uiStateParams),
  scope.$eval(attrs.uiStateOpts)
];

Into:

return [
  attrs.uiState,
  attrs.uiStateParams,
  attrs.uiStateOpts
].map(scope.$eval.bind(scope));

---

Opted for angular.bind so as to get a passing spec on TravisCI (all passing locally with fn.proto.bind running karma integrate).

One could argue that it "helps" with ES5+IE8, but that is sort of moot seeing as how .map is being utilised.

[kasperlewau]

@nateabele @christopherthielen - What are your thoughts on the current state of things in this PR? Have you gotten a chance to play around with it?

---

Personally, I will probably never use ui-state (it was always just about building it for me), so I'm not in a rush. Though I have been receiving some questions as to the status of the PR and when a possible merge would occur - I'm sort of at a loss on what to respond with (barring the ah, just +1 it friend).

I do share your concern in regards to multiple calls to $eval, and I have yet (read to test out the $attrs.observe approach. Even so I'm not crystal clear on how one would measure the possible difference in performance, any and all help in figuring that one out would be very appreciated.

[nateabele]

Refactored this into #2187.

[kasperlewau]

Closing this in favour of #2187.