Binding selection to queryParameters produces weird effects

[seven7seven]

This is my set-up:

{{select-picker content=propertyTypes
                  selection=selectedPropertyTypes
                  multiple=true
                  optionLabelPath="content.name"
                  optionValuePath="content.id"}}

selectedPropertyTypes is set as a query parameter (QP) on the controller, and also set on the route (to allow optional model reloads on QP changes). It appears to be working fine before binding it to select-picker.

The source, propertyTypes, is:

propertyTypes: [
    {
      id: '1',
      name: 'Apartamente'
    },
    {
      id: '3',
      name: 'Case / Vile'
    },
    {
      id: '6',
      name: 'Terenuri'
    },
  ],

The issue that occurs is:

When selecting an item, the QPs in the URL change to selectedPropertyTypes=%5B%7B%22id%22%3A%221%22%2C%22name%22%3A%22Apartamente%22%7D%5D, this is correct so far.

When clicking the selected item again, the QP is added again (!): selectedPropertyTypes=%5B%7B"id"%3A"1"%2C"name"%3A"Apartamente"%7D%2C%7B"id"%3A"1"%2C"name"%3A"Apartamente"%7D%5D, and does not get unselected (probably because the initial QP that bound to the component doesn't get reset correctly).

The issue persists even when selecting other items, and the QP string just keeps growing. It adds up to something like this: selectedPropertyTypes=%5B%7B"id"%3A"1"%2C"name"%3A"Apartamente"%7D%2C%7B"id"%3A"1"%2C"name"%3A"Apartamente"%7D%2C%7B"id"%3A"3"%2C"name"%3A"Case%20%2F%20Vile"%7D%2C%7B"id"%3A"6"%2C"name"%3A"Terenuri"%7D%2C%7B"id"%3A"3"%2C"name"%3A"Case%20%2F%20Vile"%7D%2C%7B"id"%3A"6"%2C"name"%3A"Terenuri"%7D%5D. Pretty messed up.

Is there a way to fix this, is it a known issue? Am I doing something wrong?

Also, I think there should be a way to just use a 'optionQPPath' or some sort of way to alter the resulting QP to selectedPropertyTypes=1,6 or something similar. What is an easy way to do this?

I'm available for any futher investigation and help. Thanks!

[sukima]

I think with the murky waters between ember 1.13 design patterns and ember 2.0 design patterns. your specific case could be helped using a data down, actions up (DDAU) design:

{{select-picker content=propertyTypes
                  selection=selectedPropertyTypes
                  action=(action "updateQueryParams")
                  multiple=true
                  optionLabelPath="content.name"
                  optionValuePath="content.id"}}

Version 2.2.x of the ember-cli-select-picker illustrates this.

This way you've separated the queryParams management from the select picker. It also provides a road towards breaking the two-way binding that will happens in Ember 2.0.

It is unfortunate that things are in this murky two-way bindings vs DDAU state. We also have the same situation in our projects that use this addon. The above is how I manage things. I do, however, have a sinking feeling that this addon is not well defined in this regard. Meaning it is a little schizophrenic about supporting both two-way bindings and DDAU. I would truly appreciate any insight, guidance, and/or suggestions on this matter.

[seven7seven]

Interesting insight -- I figured out myself afterwards that it could be because of the binding design. Currently postponing this feature due to complexity, but I'll revisit it soon, will let you know if I find something worthwile. Perhaps using a pair of observers could work as intended.