Unable to override serializeQueryParam within route

[joshfarrant]

It seems like any overrides applied to the serializeQueryParam method in a route aren't being applied.

For example I could set someQueryParam: 1 in the controller, then have something like this in the route (unrealistic but I'd have expected it to work):

serializeQueryParam: function(value, urlKey, defaultValueType) {
     return 20;
},

I'd expect the resulting param in the request to look something like this.

?someQueryParam=20

However it remains like this

?someQueryParam=1

Is this expected?

[exupero]

I'm seeing the same behavior using Ember 2.4. The method is called, but doesn't appear to have any effect.

I see several examples of using serializeQueryParam on GitHub, but all using Ember 1.

[denzo]

Any updates on this? @mmun @trek

[denzo]

I see that serializeQueryParam is marked as @private. Is that intentional and means that I should avoid overriding it?

https://github.com/emberjs/ember.js/blob/v2.10.0/packages/ember-routing/lib/system/route.js#L430

[ming-codes]

Any update on this? serializeQueryParam seems to work for me, but I'm also curious why it's marked as private.

[acorncom]

@denzo @ming-codes Was asking about this myself this morning. Per @rwjblue on Slack, this may not be public but it's at least "intimate API" (i.e. can't be broken). So probably safe to use (see #14979 for work on the router service that includes tests for it).

@joshfarrant @exupero If this is still a problem for you, it'd be quite helpful to get a reproduction on Twiddle so we can check this more carefully. Thanks!

[pixelhandler]

@acorncom @denzo @exupero @joshfarrant @ming-codes @mmun @pixelhandler @rwjblue @trek is this still an issue, perhaps we should close; what do you think?

[acorncom]

@pixelhandler given the fact that serializeQueryParam is listed in Ed's PR tracking public API here (https://github.com/emberjs/ember.js/pull/16910/files#diff-d6b0c0d618513a72b8aec4c128e8b345R471), I think it remains an open question whether we're supporting this or not. As such, I don't think we should close this just yet.