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

[BUGFIX] normalize query params when merging in from active transition #13682

Closed
wants to merge 2 commits into from

Conversation

fivetanley
Copy link
Member

rebased version of #13273, plus added test from @igorT.

From the original PR/commit message (i lazily squashed them into one, @raytiley may want to help edit):

Normalize query params when merging in from active transition

This merges in queryParams from an active transition in such a way that
prepareQueryParams won't duplicate them. It also won't merge in the
qp if it is already int he qp changed list, for example if it's already
been set during route setup by a call to controller.set('qpProp', 'someValue'). Fixing these things with my current test jsbin also
recreated another issue that has been biting people and that is that a
call to transitionTo creates an aborted transition that calls
didTransition with an empty set of handlerInfos. This would cause the
updatePaths method to fail since it couldn't calculate the paths
without the handler infos. We now bail early from updatePaths it is
called with an empty array of handlerInfos. I think this is fine
because the aborted transition is followed by a successful transition
that will update the paths appropriatly.

This gets the active queryParams and the provided using the same key
controller:prop so that the calls to assign override as expected.
This fixes issues where the QP doesn't update properly on refresh
because the merged value conflicts with the provided value.

@@ -2490,6 +2491,43 @@ if (isEnabled('ember-routing-route-configured-query-params')) {
bootApplication();
});

QUnit.test('queryParams are updated when a controller property is set and the route is refreshed. Issue #13263 ', function() {
Ember.TEMPLATES.application = compile(
Copy link
Member

Choose a reason for hiding this comment

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

Should be using setTemplate here.

@homu
Copy link
Contributor

homu commented Jun 15, 2016

☔ The latest upstream changes (presumably #13658) made this pull request unmergeable. Please resolve the merge conflicts.

@fivetanley fivetanley force-pushed the moar-qp-fixes branch 2 times, most recently from c6b8865 to 5f21c25 Compare June 15, 2016 20:23
This merges in queryParams from an active transition in such a way that
`prepareQueryParams` won't duplicate them.  It also won't merge in the
qp if it is already int he qp changed list, for example if it's already
been set during route setup by a call to `controller.set('qpProp',
'someValue')`.  Fixing these things with my current test jsbin also
recreated another issue that has been biting people and that is that a
call to `transitionTo` creates an aborted transition that calls
`didTransition` with an empty set of handlerInfos. This would cause the
`updatePaths` method to fail since it couldn't calculate the paths
without the handler infos. We now bail early from `updatePaths` it is
called with an empty array of handlerInfos.  I think this is fine
because the aborted transition is followed by a successful transition
that will update the paths appropriatly.

This gets the active queryParams and the provided using the same key
`controller:prop` so that the calls to `assign` override as expected.
This fixes issues where the QP doesn't update properly on refresh
because the merged value conflicts with the provided value.
@fivetanley
Copy link
Member Author

@rwjblue @raytiley Rebased and fixed tests. I have a clean build locally, I think Travis will say the same.

@@ -999,6 +1044,8 @@ function calculatePostTransitionState(emberRouter, leafRouteName, contexts) {

function updatePaths(router) {
let infos = router.router.currentHandlerInfos;
if (infos.length === 0) { return; }
Copy link
Contributor

@raytiley raytiley Jun 19, 2016

Choose a reason for hiding this comment

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

I added this in to try and fix the same issue that this was trying to resolve:
#13426

Looks like that PR got abandoned, and I've lost my mental model of what was going on, but I was blocked on trying to create a test that could reproduce it. I'm wondering if all the tests pass without this line, if maybe we should just pull it?

@raytiley
Copy link
Contributor

I commented on the one line that I'm not sure should be there any longer since I was never able to create a test for it. Other than that this looks like what I intended. Thanks everyone for picking up where I left off.

@rwjblue
Copy link
Member

rwjblue commented Jun 21, 2016

@fivetanley - Failing with optional tests enabled. You can test locally via: http://localhost:4200/tests/index.html?hidepassed&hideskipped&enableoptionalfeatures...

@raytiley
Copy link
Contributor

@fivetanley thanks for pushing to finally fix this. I took your rebase and fixed the tests: in #13273

@rwjblue rwjblue closed this Jun 27, 2016
@rwjblue rwjblue deleted the moar-qp-fixes branch June 27, 2016 14:05
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.

4 participants