Skip to content
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

postSubmitRedirect compares paths gotten through two different iron-router APIs #13

Open
funkyeah opened this issue Feb 21, 2016 · 0 comments

Comments

@funkyeah
Copy link

In the postSubmitRedirect Router.current().route.path is used.

It's being compared against prevPath which is indrectly being set here using Router.current().url

Very undependable results happen with these two API calls when the current route has a parameterized path.

Often Router.current().url returns a full url and sometimes it returns a path.
Often Router.current().route.path() returns the path and sometimes is returns a null.

The latter two cases both cause the resetPwd/:token redirect route to break.

Why do these two return undependable results:

The function signature for path allows for passing params and options. If you call without params then these two lines of code in iron-router urls.js break when there is a named parameter.

Long story short, I will file a bug with iron-router but since that project is very inactive it might be best to use Iron.Location.get() instead of waiting for bugfix. Iron.Location.get() seems to more consistently return the right path. At the very least the API method used to get the current path in the two spots in useraccounts/iron-routing should probably be the same.

@funkyeah funkyeah changed the title postSubmitRedirect relies on deprecated iron-router call postSubmitRedirect compares paths gotten through two different iron-router APIs Feb 21, 2016
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

1 participant