eq evaluates always false

[blogcraft]

I have this demo in Ember 2.4:

{{#each clients as |clientChoice|}}
{{clientId}} - {{clientChoice.id}}
{{eq clientId clientChoice.id}}
<br>
{{/each}}

And I get this evaluation in screen: 4 - 1 false 4 - 3 false 4 - 4 false 4 - 5 false

Why is this happening?

The complete code (I'm working with components): component.hbs:

<select class="form-control" onchange={{action "selectClient" value="target.value"}} id="selcl">
  <option value="" disabled selected>{{title}}</option>
  {{#each clients as |clientChoice|}}
    <option value={{clientChoice.id}} selected={{eq clientId clientChoice.id}}>{{clientChoice.firstName}} {{clientChoice.lastName}}</option>
  {{/each}}
</select>
{{clientId}}
{{#each clients as |clientChoice|}}
<br>
{{clientId}} - {{clientChoice.id}}
{{eq clientId clientChoice.id}}
{{/each}}

component.js

import Ember from 'ember';

export default Ember.Component.extend({
  clientId: Ember.computed('clientId', function() {
    return this.get('clientId');
  }),
  client: null,
  clients: Ember.computed('clients', function() {
    return this.get('clients');
  }),
  actions: {
    selectClient(clientId) {
      this.set('clientId', clientId);
      console.log($("select").val());
    }
  }
});

[rwjblue]

My general guess is that they are of different types, but we would really need a runnable demo to be sure.

[MichielDeMey]

I'm having the same issue. I ultimately had to convert my integers to strings due to an API discrepancy.

Maybe we should introduce a non strict equality method? (==)

[jmurphyau]

I've just added a test case (I'll push it soon so you can see) that demonstrates this works as expected.. Is clientId an integer in the first example? And if so, and if you are using Ember Data, then the ID in your models are being converted to strings automatically..

The following code

[{{eq 3 3}}] [{{eq '3' 3}}] [{{eq 3 '3'}}] [{{eq '3' '3'}}]

Produces the following output

[true] [false] [false] [true]

[typeoneerror]

Seeing this in our app w/2.4 as well. I'm not positive it isn't a browser thing. I've got this in there:

  {{#each content as |item|}}
    <option value="{{get item optionValuePath}}" selected={{eq item selection}}>
      {{get item optionLabelPath}}
    </option>
  {{/each}}

And the <option> does indeed select the correct item, but odd thing is: there's no "selected" property when I inspect the element in Chrome and Safari.

With just <option value="{{get item optionValuePath}}">, the select doesn't select that item at all, so it's working, it just doesn't seem to be bound or something?

[typeoneerror]

{{#each content as |item|}}
  {{log (eq item selection)}}
{{/each}}

Logs false, true, false, false (true for the selected item). So it appears that eq is working, but the selected prop is not 100% working or something.

[typeoneerror]

Even hard-coding in selected={{eq item.id "2"}} selects the correct item but in the HTML, "selected=" attribute is not here. Will see if I can repro in a clean repo.

[rwjblue]

You have discovered the difference between attributes and properties. Welcome to my nightmare.

[typeoneerror]

@rwjblue so this isn't really a truth-helpers issue then from the sound of it?

[rwjblue]

@typeoneerror - Play around with http://jsbin.com/fidowu/edit?html,output. You will see that the selected attribute (what you see in the "Elements" pane in the Chrome DevTools) never updates even if you change which option is selected. This is (roughly) because the attribute is only used for initial render, and from then forward the property is used.

[krivaten]

As to what @MichielDeMey mentioned, how I've handled this in the past was by creating a custom clone of the eq helper called aeq (Poor naming, but it's short):

https://gist.github.com/krivaten/a7662fea8da50b42e5ff2311643103f3

[locks]

Having read the thread it seems like there is no bug in ember-truth-helpers. Let us forget about attributes v. properties 🧘‍♂️