Disable parameter inheritance in ui-sref directive

[tobigit]

Is there a way to disable parameter inheritance in ui-sref directive?
I would like to have a second parameter, like this:

<a ui-sref="contacts.detail({ id: contact.id }, {inherit: false})">{{ contact.name }}</a>

With the second parameter i could set the options for the method $state.go().

[nateabele]

Can you just pass null to the parameters you don't want?

[tobigit]

Our Application has about 38 states. Every State has its own parameters. One state can have up to 12 parameters. When i pass null to every parameter of every state in every link (ui-sref), there would be very long ui-sref calls.

I would be happy if a optional second paramter of type boolean would disable inheritance like this:

<a ui-sref="contacts.detail({ id: contact.id }, false)">{{ contact.name }}</a>

[laurelnaiad]

If you define query parmeters (the things after the question mark) then would they be optional in ui-sref?

[tobigit]

Example

My current URI: /contacts/teams&sortBy=Name&filterBy=test
My State: contacts.teams

Now I click on this link:

<a ui-sref="attachments.list({ type: 'private' })">list attachments</a>

Now my URI: /attachments/list&sortBy=Name&filterBy=test&type=private
My State: attachments.list

The query parameters sortBy and filterBy stay in URI until i overwrite it or until i switch to a state which has not defined these parameters in $stateProvider.

[laurelnaiad]

Nothing's simple, is it? :)

2 cents:

I'd hope that if parameters that are valid for a state are not specified and they are currently in scope when the ui-sref is invoked, that they retain their values -- and thus, if they are URL parameters, that they stay in the URL.

If they are not currently in scope, then they would result in being undefined; that they do not appear in the resulting URL; and that it is the application's responsibility to know what to do about undefined parameters.

[tobigit]

Ok, when you have one controller and the states attachments.list and contacts.teams shares one scope, where the parameters values are stored, your explanation is comprehensible.
The issue is that the new state (example above: "attachments.list") has its own controller with an own scope with own default-values for parameters like sortBy and filterBy.
So our application throws an error because sorting by "name" (example above: &sortBy=name) is impossbile when column "name" doesnt exists in attachements list.

Inheritance of query parameters is great if parameters were inherited from parent to child state. But inheritance between "master-states" (example above: "contacts.", "attachments.") is confusing.

[laurelnaiad]

Inheritance of query parameters is great if parameters were inherited from parent to child state. But inheritance between "master-states" (example above: "contacts.", "attachments.") is confusing.

I think I agree. I wouldn't consider those to be the same parameters since there isn't an ancestral relationship -- thus they wouldn't be "in scope" when you go from one to the other -- the parameters just happen to have the same names.

[tobigit]

So is there a chance for parameter implementation to disable url-parameter inheritance (between sibling states)?

[nateabele]

@tobigit Could you maybe break down your state tree a little bit, so we can understand better how to craft a solution that's a little bit more optimal for you? I have an idea that I think is a little bit better and more extensible than just adding another parameter (to something that isn't a function anyway), but I want to make sure it'll work for you.

[tobigit]

Sure, here is a snippet of our state configuration:

$stateProvider.state('users', {
    url: '/:workspaceId/users/?id&sortyBy&filterBy',
    controller: 'userController',
    templateUrl: '/views/users/index.html'
});

$stateProvider.state('teams', {
    url: '/:workspaceId/teams/?id&sortyBy&filterBy',
    controller: 'teamController',
    templateUrl: '/views/teams/index.html'  
});

My currently quick fix is to add some lines in angular-ui-router.js at line 1193.
So the click-handler for the link looks like this:

element.bind("click", function(e) {
        if ((e.which == 1) && !e.ctrlKey && !e.metaKey && !e.shiftKey) {

        // fixes parameter inheritance between sibling states
        var fromBase = $state.$current.name.split('.')[0];
        var toBase = ref.state.split('.')[0];

        var options = {};

        if (fromBase != toBase) {
            options['inherit'] = false;
        }
        $state.go(ref.state, params, options);
        // ***

        scope.$apply();
        e.preventDefault();
    }
});

[knalli]

Okay, should we (@tobigit or me) send a solution as a PR?

I do not like the code above because the condition fromBase != toBase does not solve the original problem correctly. I would support inherit as an additional parameter for ui-sref, the open question is only interface aware: Should this be <a ui-sref="contact.detail({id: 1}, {inherit: false})"> (abstract) or <a ui-sref="contact.detail({id: 1}, false)"> (explicitly, precisely)?

Alternatively (or additionally), we could introduce a new "smart" behavior which recognize state changes and will not apply the current state params?

So, the code in question would be something like this:

      element.bind("click", function(e) {
        if ((e.which == 1) && !e.ctrlKey && !e.metaKey && !e.shiftKey) {
          var options = {};
          // Unless the state in question is a child state of the current one, the params will be not included.
          if (!$state.ref.contains($state.$current.name)) {
            options['inherit'] = false;
          }
          $state.go(ref.state, params, options);
          scope.$apply();
          e.preventDefault();
        }
      });

[tobigit]

I added a pull request. Tests of the new regexp: https://www.debuggex.com/r/TuuflzAR_vZ2mWph/1

[timkindberg]

I think we need both:

• @tobigit's PR is a great feature, but not optimal for this particular issue, because adding the ability to specify options to sref, while cool, gives benefits beyond the scope of this issue by allowing modification of the other options (aka location, relative (probably not useful), notify, and reload (v0.3)). And of course you can also set inherit to false, but that could be useful in other ways, again beyond this issue.
• @knalli's approach, however, is a good solution to this particular issue, showing how we could handle things in a smarter way for the user.

But I'm not sure @knalli's approach is actually everything we need, because you don't want to check for just if the to state is a child of the from state, I think inheritance is a bit more complicated than that.

So @nateabele I'm not entirely sure how inheritance currently works but I'm thinking it's supposed to work like this... say I have some states:

• A - with param a
• A.B - with param b
• A.B.C - with param c
• A.X - with param x
• A.X.Y - with param y
• A.X.Z - with param z
• K - with param a
• K.B - with param b

Assuming inheritance is true in all cases... if I go from:

• A to A.B, then inherit a.
• A.B to A.B.C then inherit a and b.
• A.B.C to A.X then inherit a.
• A.B.C to A.X.Y still only inherit a.
• A.X.Y to A.X.Z then inherit a and x.
• A to K then inherit nothing, even though they share same param name.
• A.B to K.B, inherit neither a or b because they aren't the same param instance, even though name is the same.

God I know that's a lot to take in... hope you could understand it. So I'm in favor of @tobigit cleaning up his PR (squash and add tests). Then additionally implementing something that auto-inherits in the way I've laid out.