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

[3.18] navigate() falls through to window.location on no matching route. #1874

Closed
wants to merge 5 commits into from

Conversation

ericsoco
Copy link

Per previous conversations with @ericf.
If this looks like an acceptable solution, I can add tests.

/cc @pdokas @jeremyruppel

@yahoocla
Copy link

Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! 😄

}
if (handleFallThrough) {
console.log("FALL THROUGH");
win.location = url;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably want to ensure we're staying on this domain before assigning to window.location.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pdokas that happens on the line above! Or...wait. Does Y.Error throw an error or just log it?

@yahoocla
Copy link

CLA is valid!

}
};

Y.PjaxBase = PjaxBase;
Y.PjaxBase = PjaxBase;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newline police! 🚓

@rgrove
Copy link
Contributor

rgrove commented Jun 17, 2014

Does this even need to be an option? It seems like sensible default behavior (in fact, if you had asked me, I would have sworn it was already the default).

If it does end up remaining an option, then handleFallThroughNavigation seems like an odd name for the attribute, especially since "handle" is a useless verb (all code "handles" things). I don't think the verbosity really communicates anything of value.

Possible alternate names:

  • allowFallThrough
  • fallThrough
  • navigateOnUnmatchedUrl (if you're not into the whole brevity thing)

@ericsoco
Copy link
Author

@rgrove as I mentioned in the inline comment I just left, I don't think it needs to be an option. (We thought it would be the default as well! Lo and behold it is not.)

The attribute name is *handle*FallThroughNavigation because it implies that the alternative is to not handle it -- let it fall through and silently do nothing (which screwed us and our users, so, agreed -- not a good default). allowFallThrough works for me, though.

@ericf
Copy link
Member

ericf commented Jun 17, 2014

Does this even need to be an option?

I agree, no need for an option. I think this change will, in the end, reduce the complexity overall.

@rgrove
Copy link
Contributor

rgrove commented Jun 17, 2014

To clarify: by "does this even need to be an option?" I mean that it doesn't seem like either the navigate() option or the attribute are necessary.

If navigate() gets called with a URL that doesn't match a registered route, it seems totally sensible to do a full page navigation to that URL. If that's not what the caller wanted, they shouldn't have called navigate(), right?

@ericsoco
Copy link
Author

@rgrove we expected that to be the default behavior and were surprised to find that it was not. That said, if there are any YUI consumers out there relying on the current behavior, an attribute would at least give them the option to disable this change in the default.

Just pushed an update based on the conversation so far.

@ericsoco
Copy link
Author

Any thoughts on the latest?

@rgrove
Copy link
Contributor

rgrove commented Jun 19, 2014

👍

@ericsoco
Copy link
Author

Sorry, been meaning to get back to this (write tests), but end of quarter happened. Still on my radar...somewhere....

@ericsoco
Copy link
Author

ericsoco commented Aug 6, 2014

Getting back to this after a long hiatus...

There's a failing test here that I'm not sure how to handle:
'navigate event should not fire for a hash URL that resolves to the current page'

This test relies on the false return from _navigate() to cause navigate() to fall through to its own return false. However, the discussion above led me to add a return true to the allowFallThrough condition; seems like this test is no longer useful as-is.

Specifically, a hash URL that resolves to the current page should cause _navigate() to return false, but navigate() should still return true. Do you agree?

@ericsoco
Copy link
Author

ericsoco commented Aug 6, 2014

Also, how do I specify the router config from pjax-test.js / the test environment in general? I can't figure out how to test a non-matching route (which is what this PR is all about). If it's relatively simple for the YUI team to run tests on this PR, that would be great -- I've burned 2 hours this morning getting this far and I'm still at a wall.

@triptych
Copy link
Contributor

triptych commented Aug 6, 2014

Adding @tripp @ericf and @jlecomte for /CC

@triptych triptych changed the title navigate() falls through to window.location on no matching route. [3.18] navigate() falls through to window.location on no matching route. Aug 6, 2014
@ericsoco
Copy link
Author

ericsoco commented Aug 8, 2014

Hello again, @triptych @tripp @ericf @jlecomte @rgrove.
Would love to close this out before 3.18; would love to close it out in general. Any word on help with these tests?
/cc @pdokas

@tripp
Copy link
Contributor

tripp commented Aug 8, 2014

@ericsoco
I'll be able to look into this on Monday.

@ericsoco
Copy link
Author

Hi @tripp, any news?

@tripp
Copy link
Contributor

tripp commented Aug 12, 2014

@ericsoco No. I only pulled in your branch this morning. My apologies. I'll post back later tonight.

@tripp
Copy link
Contributor

tripp commented Aug 13, 2014

Pull request #1937 updates the tests for your fix.
I'm thinking those test updates should work. I can merge these changes in tomorrow.

@tripp
Copy link
Contributor

tripp commented Aug 14, 2014

@ericsoco
I didn't get to this today. I'll be able to do it tomorrow. Thanks.

@tripp
Copy link
Contributor

tripp commented Aug 14, 2014

I've cherry-picked your commits into dev-master.

@tripp tripp closed this Aug 14, 2014
@ericsoco
Copy link
Author

w00t! We'll look for em in 3.18. Thanks for knocking this out, @tripp.

@pdokas
Copy link
Contributor

pdokas commented Aug 14, 2014

🎉

@okuryu
Copy link
Member

okuryu commented Aug 18, 2014

I updated the change log at e2cd21b just in case.

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

Successfully merging this pull request may close these issues.

9 participants