Boolean controller properties set to null parse as truthy strings

[allthesignals]

When a queryParam on a controller is defaulted to null (such that it won't be serialized in a request to the API unless changed), and when that property is toggled (via this.toggleProperty), it produces this sequence of values: true -> false -> false -> true. I think this is because at some point it's parsed as a string, which is truthy.

Twiddle: https://ember-twiddle.com/3afa1091106a91ce2c1734ae2998bc3f?openFiles=controllers.application.js%2C&route=%2F%3Fredevelopment%3Dfalse

Conditions:
Controller property is set to null.
Controller property is a queryParam.
Controller property is toggled to true or false.

Behavior:
Toggling the property produces this sequence of values: true -> false -> false -> true.

While setting the default value to false solves the issue, null queryParams aren't serialized in API requests to the server, which is helpful.

Controller:

App.IndexController = Ember.Controller.extend({
  queryParams: ["redevelopment"],
  redevelopment: null,
  actions: {
    toggleIt: function() {
      this.toggleProperty("redevelopment");
    }
  }
});

Sorry if this is already covered, it is mentioned here: #4570. I'm just trying to understand if this is intentional or not.

[Serabe]

I can confirm this is happening in canary too. Thank you for your report!

[allthesignals]

Thanks. I think the query parameter is overwriting the value as a string, "false", which toggles to false. !!"false" == true.

It would be nice to have something like this in the API:

export default Ember.Controller.extend({
  queryParams: {
    category: {
      type: "boolean"
    }
  },
  category: null
});

EDIT:
It does! This seems to fix the issue:

export default Ember.Controller.extend({
  queryParams: [{ 
     redevelopment: { 
         type: 'boolean' 
     } 
  }],
  redevelopment: null
});

Maybe an enhancement would be more intelligent coercion of values, but that might not be possible, since it would be based on the future lifetime of the value.

[mixonic]

@allthesignals is this perhaps ready to be closed? The coercion cannot even be perfect (as you identified we cannot know all future values) and I think you should be strongly encouraged to use a default type matching your eventual value and/or to use the explicit type syntax.

[knownasilya]

It needs to be documented before we close.

[ghost]

this ambiguity cost our team numerous hours of debugging. I started some documentation. This could use some further exposition in the guides as well; could throw together a more verbose description of the behavior as well.

[locks]

Documentation merged!