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

Fix query param stickiness between models in ember-engines #14794

Merged
merged 2 commits into from
Jan 13, 2017

Conversation

rajaalauddin
Copy link

See #14788

Summary:

In ember-engines, query param is sticky between different models (see generated link-to). This is not the behavior outside engine and as specified https://guides.emberjs.com/v2.10.0/routing/query-params/#toc_sticky-query-param-values

This is happening because they share the same cacheKey when controller is used as the prefix.

Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

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

One small thing, but overall this seems good to me. I think using the route name also is in the direction of moving away from controllers. @rwjblue can you review when you have a chance?


return this.visit('/blog/category/1?type=news').then(() => {
let href = this.element.querySelector('a').href;
assert.equal(href.match(/type=news/), null);
Copy link
Member

Choose a reason for hiding this comment

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

Can we change this to just be assert.equal(href, '/blog/category/1337');? It's easier to follow and will give clearer feedback (IMO) if it breaks.

Copy link
Member

Choose a reason for hiding this comment

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

agreed, I'd much prefer to assert against the value we actually expect...

Copy link
Author

Choose a reason for hiding this comment

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

I've updated this to use .endsWith since full href include port number. Let me know if you need further change.

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 able to use something like:

let { pathname } = this.element.querySelector('a');
assert.equal(pathname, '/blog/category/1337');

Copy link
Author

Choose a reason for hiding this comment

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

endsWith solution didn't work because of not being implemented in phantomjs. pathname solution also didn't work because of ie9 different implementation. I changed this to indexOf to simulate endsWith. Let me know if you guys have better preference.

@rwjblue
Copy link
Member

rwjblue commented Jan 11, 2017

This is looking good! A few specific issues that we should chat through are:

  • It is odd to have most of the QP system based on controllerName and another part based on route.fullRouteName.
  • How do we handle scenarios where folks have customized controllerName to specify a controller other than the route's controller is handling their QP's? With this change, I think that use case might break?

@rajaalauddin rajaalauddin force-pushed the fix-query-param-stickiness branch 4 times, most recently from b4328dd to f88f247 Compare January 13, 2017 05:20
});
}

['@test query params in customized controllerName have stickiness by default between model'](assert) {
Copy link
Author

Choose a reason for hiding this comment

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

How do we handle scenarios where folks have customized controllerName to specify a controller other than the route's controller is handling their QP's? With this change, I think that use case might break?

@rwjblue I added a test on this and you are correct this change will break queryParam in customized controllerName.

Copy link
Author

Choose a reason for hiding this comment

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

I stand corrected - this change doesn't break custom controllerName case. There was an error in the way i register the route causing the test to fail. I've updated the setup and now it's passing.

@rajaalauddin
Copy link
Author

How do we handle scenarios where folks have customized controllerName to specify a controller other than the route's controller is handling their QP's? With this change, I think that use case might break?

@rwjblue I added test to cover this scenario and it's passing. Please verify if that is what you have in mind. thanks

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.

3 participants