Skip to content

Add option to preserve slashes when generating URLs in reverse routing #329

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sqs opened this issue Aug 17, 2013 · 7 comments
Closed

Add option to preserve slashes when generating URLs in reverse routing #329

sqs opened this issue Aug 17, 2013 · 7 comments

Comments

@sqs
Copy link

sqs commented Aug 17, 2013

Suppose I have a state with a URL route like /foo/{bar:.+}, where bar is expected to contain (unescaped) slashes. Then if I use reverse routing to generate a URL when bar contains slashes, I get a URL like /foo/bar%2Fbaz%2Fqux.

I can think of 2 solutions:

  1. Add an option to reverse routing that preserves route parameters in the generated URL (i.e., so that UriMatchers.prototype.format does not call encodeURIComponent on them).
  2. Automatically detect route param patterns such as .+ that can contain slashes, and don't escape slashes in those. (But what about other special characters?)

There is always the workaround of using an AngularJS filter to s/%2F/\//g, so this is not an especially urgent problem.

@nateabele
Copy link
Contributor

I would stick with the workaround for now. On the horizon, we have plans for configurable typed parameters where you have full control of forward and reverse conversion.

@sqs
Copy link
Author

sqs commented Aug 17, 2013

Got it. I actually spoke too soon about the workaround. Because ui-sref performs its own parsing (in parseStateRef), a simple filter does not work. Still, a quick patch is easy to make in our local copy and will suffice until a broader solution is ready.

@nateabele
Copy link
Contributor

I'm pretty sure parseStateRef is irrelevant here, since it's only looking for a state name, which should never have a slash anyway. Feel free to open a new issue with a link to a plunkr that demonstrates the ui-sref issue, otherwise keep an eye on #125 for typed parameter support.

@sqs
Copy link
Author

sqs commented Sep 10, 2013

OK got it. Re: parseStateRef, I mean you couldn't have a filter that takes the ui-sref expr as input.

@nateabele
Copy link
Contributor

Oh, gotcha. Yeah, in that case what I would do is something like this:

<a ui-sref="my.state(filter(params))">click</a>

Where params is the object hash of your parameters, and filter() is a method on $scope that does whatever pre-processing you need on your parameters.

Not sure if that solves your use case or if you need a post-processor hook, but it sounds like you've got an interim solution worked out anyway.

@sqs
Copy link
Author

sqs commented Sep 10, 2013

Yup, thanks! I actually just hackily patched it for now. I'll follow the other issue.

P.s. UI-router is awesome.

@mismith
Copy link

mismith commented Jun 18, 2014

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants