[WIP] Preserve queryParams

[cibernox]

So far I've proven that this is doable by using the -routing service and observing changes in the state of that service.

Questions to be answered:

1. That service is not yet public. Ask the oracle (@rwjblue) wether or not this is a terrible practice
2. Measure performance penalty. If this brings this addon in the like of performance with a regular {{link-to}} that would defeat the purpose of using it.

[cibernox]

@GavinJoyce May I take some advice on how to measure the perf of this change? I imagine that setting an observer won't affect performance that much (although all helpers will recompute when qps change while now it doesn't, but that is a bug to me)

[GavinJoyce]

@cibernox I just manually copy some code into a custom benchmark in a throwaway ember-performance branch and compare the results. I'm happy to do this later this evening if you want?

Thanks for doing this, this is a nasty bug and it's great that it'll be fixed

[cibernox]

@GavinJoyce That would be great. That said, don't merge it yet. I need to test more edge cases.

• Transition from /foo/bar?one=1&two=2 with {{href-to 'foo.qux'}}, where one is a qp that belongs to foo and two is a qp that belongs to bar but not to qux. Expected: one=1 is preserved, two=2 dissapears.
• Transition from /foo/bar?one=1&two=2 with {{href-to 'foo.qux'}}, where one is a qp that belongs to foo and two is a qp that belongs to bar and qux. Expected: Both remain.
• Transition from /foo/bar?one=1&two=2 with {{href-to 'foo.qux'}}, where one and two are qps that belongs to foo. Expected: Both remain.
• Transition from /foo/bar?one=1&two=2 with {{href-to 'foo.qux'}}, where one and two are qps that belongs to bar and qux. Expected: Unsure.
• Transition from /foo/bar?one=1&two=2 with {{href-to 'another'}}, where one and two are qps that belongs to foo and another. Expected: None is preserved (I think).

[GavinJoyce]

@cibernox I didn't manage to get benchmark data, I was planning to modify GavinJoyce/ember-performance#1 but ember-performance has changed significantly since then.

onQpsChange: Em.observer('_routing.currentState', function() {
  this.recompute();
}),

This seems like it will be expensive on any route transition, every href-to will recompute. I wonder can we only recompute if a query param has changed? Or, perhaps we could skip the recompute if there are no query params?

[cibernox]

I've been able to create a couple more complex scenarios that still fail. Over the weekend I'll try to figure out how to better do this.

I've also seen on the core notes that they agreed to proceed with your url-for RFC, so I might ping someone to give some guidance on this.

[ilucin]

I was experimenting with this because I need it on my own project. Few observations:

• observer on _routing.currentState fires even though routerJsState.fullQueryParams did not change. I've fixed it with my proxy routing service that abstracts currentQueryParams away.
• fullQueryParams sometimes contained old value so I'm using routerJsState.queryParams instead. Not sure what's the difference between those two.
• It only makes sense to preserve query params that belong to parent route handlers of the route being passed to href-to.
• I'd maybe rather opt-in into this feature on every {{href-to}} than have it on by default because of performance penalty on route switching. On my (highly specific) use case this performance penalty is significant.

[scalvert]

Is it worth investigating this with the new public router service?

[cibernox]

@scalvert I believe it's not. I mean, its probably worth pursuing, but the approach would be totally different from different. Tests seem valuable tho