Using Catch All parameters with ui-sref

[Xiot]

I currently have a n-level deep route which can consist of a variable number of segments (ie directory browser). I have the following state set up:

.state("folders", {
    url: "system/*folderPath",
    controller: "FolderController",
    templateUrl: "folders.html"
})

The transition is then navigated through an ui-sref
<a ui-sref="folders({folderPath: "folder1/folder2"})" >Link</a>

The ui-sref works fine and the location is changed to system/folder1/folder2 however the link that shows up in the browser when you hover over it is system/folder1%2Ffolder2 because the value is passed through encodeURIComponent

What I am proposing is that for catch all route parameters, the value gets uri encoded, but should leave any forward slashes in, or at least have an option to make it work like that.

I can get around it by using ng-href to compose the uri, however then I lose the funtionality of ui-sref-active.

I did a quick and dirty hack of changing UrlMatcher.prototype.format to use

if (value != null) {
        if (this.sourcePath.indexOf("*" + params[i]) >= 0)
            result += value;
        else
            result += encodeURIComponent(value);
    }

but that only works for the shorthand *parameterName syntax. The better way would probably be to keep a record of the catch-all parameters when the url format is parsed and use that to determine how to encode the value.

Let me know your thoughts

[flauwekeul]

👍

Another solution to this could be to be able to pass an array as the parameter value in ui-sref, like so: <a ui-sref="folders({folderPath: ['folder1', 'folder2']})" >Link</a>. Maybe the array could be concatenated with /'s. But I don't know enough about the internal workings to know if this is any better than Xiot's approach.

[dmitry-dedukhin]

URL-encoded link causes two $locationChangeStart events.
First event fires when we navigate to encoded url and then url is changed to non-encoded (at the moment I did not found where this happens).

[foresttoney]

+1

[vlad-nica]

Encountered a similar problem like @dmitry-dedukhin. Navigating to a state that has an url like: '/someAction/{id}/*params', makes two calls to the server for the template associated with the state.

[AntJanus]

Just wanted to add that I have the same issue with the URLs. Does anyone have a hacky workaround until someone creates a core-modification to resolve this?

[lopsided]

I'm not quite sure if my issue was the same as described here, but changing url: "system/*folderPath", to url: "system/{folderPath:any}", stopped the encoding for me when using it in ui-sref

[lopsided]

Ignore that, spoke too soon. It works as far as clicking the links in the browser works, but inspecting/copying the generated href shows it is still encoded. I still need a workaround like @Xiot suggested, although in keeping with the any type I used this:

result += param.type.name == 'any' ? encoded : encodeURIComponent(encoded);

[Xiot]

I like the idea of basing it off of the type.
Maybe we would want a special 'path' type as well that would encode everything except for the slashes. That way we would get the benefits of both worlds

[lopsided]

@Xiot I think this should do it. I've set up a new type which, on encoding, splits it by / and then in the format function still uses the encodeURIComponent for each path component and then joins it by / again.

[xwipeoutx]

I've hit this same issue, the fix from @lopsided works a treat. Any chance of it getting merged in @nateabele? It really does make the URLs much more pleasant

[AntJanus]

Unfortunately, this problem got a whole lot worse with the new release. Not only do the slashes get encoded, but it looks like they get encoded mistakenly several times over rendering ui-router completely useless in this manner -.-

Urgh, can anyone think of a good fix other than using someone else's branch?

[eddiemonge]

I use commas instead of slashes for this very case.

[keatz55]

+1

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.