RFC: Nested state support for ui-sref-active

[MrOrz]

It is mentioned in #635 and #19 that ui-sref-active will support nested state in the future, but I could not find the details discussed anywhere. As I browse the current source code, I found that it is actually not hard to achieve, and that it would seem redundant if I create another directive just for supporting nested states.

Since I need this feature right away, I've implemented a quick and dirty way to meet my need: when an extra html attribute ui-nested is present, ui-sref-active would use $state.includes instead of strict equality on the states.

Demo: http://plnkr.co/edit/CWUy3T0M7dTap75hASkk?p=preview

This can be achieved by merely changing 1 line (yeah I'm only capable of making a modification <= 4 lines... :P)
https://github.com/MrOrz/ui-router/compare/ui-nested

Hope that through this little dirty hack, we can initiate a discussion on how this function should be properly implemented.

[timkindberg]

Nice I've at least triaged it and added to Milestone 0.4.0. Thanks.

[hazeledmands]

What about a separate directive called ui-sref-nested that adds relevant classes if the referenced state includes the current state? Seems like it would be useful to have the ability to set different CSS in either case.

[MrOrz]

@demands Wow I haven't thought of that. It surely may be useful to apply different classes to separate the cases that a state directly active from activation of descendant states.

For example, with a separate directive ui-sref-nested we can achieve something like this:

<div ui-sref-nested="is-child-selected" ui-sref-active="is-selected"></div>

[timkindberg]

I kind of like this functionality but not necessarily the solution. It feels a tad odd for an official solution. Talking about @demands idea.

[hazeledmands]

What would be better?

[timkindberg]

Perhaps its the naming that I don't like, I see the need for the two solutions. ui-sref-nested feels a bit ambiguous, like is it talking about nested srefs or sref-active's? Obviously I know what its doing I'm just thinking of a typical user. There's so much to take in already in ui-router I'm just trying to play the friendly-api police and devils advocate.

Like maybe another good idea is to have only the ui-sref-active directive but it behaves differently in different circumstances, using the example ui-sref-active="selected":

• If the ui-sref on the same element or a child is active it adds the class "selected"
• if the ui-sref that is active is nested then it adds the classes "selected selected-nested" or maybe "selected selected-child", not sure which would be a better name.
• Maybe in all cases we also add the class "sref-active"?

[MrOrz]

@timkindberg the *-nested solution sounds great!
sref-active class sounds cool too. However I am not sure about its use case.

The only scenario I came up with is to apply additional styles if there is an element with ui-sref attribute.

For example:

<li ui-sref-active="...">
  <a ui-sref="..." ng-if="!disabled">Step 3</a>
  <span ng-if="disabled">Step 3</span>
</li>

And <li> would have sref-active if and only if scope.disabled is false.

[timkindberg]

@MrOrz cool thanks. Yeah the idea for adding 'sref-active' in all cases was so you'd always have a common class among all active srefs regardless of what class name you specified, but I think its probably not so useful. If @nateabele is ok with the idea of appending the extra *-nested class in those special cases, I'd say you are good to go on submitting a PR.

[besnik81]

A very quick hack i've used for recursively activating the parents. I m almost sure that it is not a correct implementation, but it should give an idea:

https://github.com/besnik81/ui-router/compare/patch-1

It works in very well in my case, which is similar to the following snippet.

  <ul>
    <li ui-sref-active="active">
         <a href="#">Parent</a>
         <ul>
            <li ui-sref-active="active">
               <a href="#" ui-sref="my.state">Child</a>
            </li>
         </ul>
    </li>
  </ul>

[MrOrz]

@besnik81 The idea that one ui-sref can toggle the activation state of two nested ui-sref-active is really interesting! In my current implementation of ui-sref-active it requires an ui-sref to tell it what state to look at.

If the ui-sref-active cannot be recursively (in terms of HTML structure) activated, the only way to achieve something similar is to add something dirty to our HTML:

  <ul>
    <li ui-sref-active="active">
         <a ui-sref="my" style="display: none;"></a> Parent
         <ul>
            <li ui-sref-active="active">
               <a href="#" ui-sref="my.state">Child</a>
            </li>
         </ul>
    </li>
  </ul>

Not to mention that the solution I provided above cannot deal with the case where inner <ul> contains different parent states:

  <ul>
    <li ui-sref-active="active">
         <a ui-sref="??? Dunno which to choose ???" style="display: none;"></a> Parent
         <ul>
            <li ui-sref-active="active">
               <a href="#" ui-sref="my.state">Child</a>
            </li>
            <li ui-sref-active="active">
               <a href="#" ui-sref="your.state">Child</a>
            </li>
         </ul>
    </li>
  </ul>

So there are 2 "nested ui-sref-active" patterns we currently have in this thread:

1. The "states" are nested, as in http://plnkr.co/edit/CWUy3T0M7dTap75hASkk?p=preview .
2. The HTML strucutre are nested. as in the snippet provided by @besnik81 .

And these two patterns are not necessarily independent! Thing's getting complicated now...... :/

[timkindberg]

I don't fully understand how the ideas differ

[besnik81]

@timkindberg The essential difference is that the state hierarchy does not necessarily correspond to the HTML hierarchy. The code I've provided focuses on activating parent nodes in the HTML, whenever a link inside that node is activated, regardless of the active state. My idea is that we need these additional classes to support CSS styling -- which in turn is using only the HTML structure. The primary use will be for styling menus. I think we can have multiple not-related states included under the same menu and still wanting to activate that menu item.

The solution given by @MrOrz focuses on activating links that correspond to parent states (hope I am right here).

Definitely, there are two patterns here.

[besnik81]

To clear the ideas (or just thinking loud):

First, ui-sref will transition into a state (say app.users.list that lists the users). Clicking on a user, ui-sref="app.users.view(34)", will transition into a new child state.

• Should the link to app.users.list be activated? I think that the choice should be left to the user. In this case, we need an attribute (say ui-sref-active) with a pattern of states to activate the item. This attribute should not be linked to that particular ui-sref but rather listen to state change events. The good thing is that it will be completely decoupled from ui-sref. The bad thing can be in terms of performance.
• How to specify the classes? Maybe a new attribute like ui-sref-active-class that will only add/toggle classes. This attribute will be linked with all children ui-sref-active attributes -- same as the actual relationship between ui-sref and ui-sref-active?!
• How to propagate activation up the DOM tree? We can link a ui-sref-active to all ui-sref-active-class attrs above. But, how to order the deactivation from a child with the activation from another child. Need to see if there are different events for 'before state change' and 'after state change'.

[timkindberg]

The solution given by @MrOrz focuses on activating links that correspond to parent states (hope I am right here).

@besnik81 ah I don't think I ever picked up on the fact that is was based off of the actual state nesting, I always was thinking in terms of how the ui-sref-active directive would interact with ui-srefs nested in the html, regardless of which states the ui-srefs pointed. I do understand now, at least how there are more things to consider, but I'm a bit lost as to how to approach it. Sounds like it's getting overly complex to me at this point. Its fine to get complex while hashing things out and discussion but we'll need to steer this way back to super simple at the end; I mean it is just a directive for highlighting something, so it needs to be dead easy. Also I'd prefer dead easy and hit 80% of use cases, rather than complex and hit 100%.

[ericclemmons]

I have a multi-level navigation that uses nested states extensively, and this PR would solve several of the UI issues I'm having.

I'll have to catch up on this thread & grok the "2 patterns" so hopefully we can reach a conclusion :)