Ember-power-select: groupName being used a little too eagerly

[SirZach]

I just so happen to have a model with a groupName attribute on it but I do not want ember-power-select to group on. If I could say something like "isGroup=false" that would be great. Thanks!

[SirZach]

Just saw that in https://github.com/cibernox/ember-power-select/blob/master/addon/utils/group-utils.js#L5 it's also checking to make sure the entry has an options field but that doesn't seem to matter. My options are undefined yet ember-power-select still treats it as a group.

[cibernox]

Your models doesn't have a property named options? If so, I wouldn't expect EPS to recognise it as a group. If so, it is a bug.

If your object has a property names option (even if it's undefined) then I'm not sure how it should behave.

Can you confirm how your object looks like?

[SirZach]

It does not have a property named options. the !!(get, entry, 'options') evaluates to false.

[cibernox]

Interesting. Can you create a failing test case for this? Sounds like a bug.

[SirZach]

I can't currently run ember server with beta.30

[SirZach]

https://github.com/cibernox/ember-power-select/blob/master/addon/templates/components/power-select/options.hbs#L7 yeah, seems like the groupName check in the template is done regardless of whether or not the entry was deemed to be a group entry. I think we need something like
{{#if (and opt.groupName opt.options.length)}}

[corrspt]

Just want to pitch in and say that I had to workaround this situation (thought it was a limitation thought), ever since the beginnings of ember-power-select.

I've changed my models at the time to not have a groupName property

[SirZach]

That's not exactly an option for me. Luckily I was able to override https://github.com/cibernox/ember-power-select/blob/master/addon/templates/components/power-select/options.hbs#L7 to include the check for opt.options.length

[corrspt]

Sorry, I wasn't suggesting it as an option for you, just saying that I was affected by the same issue.

[cibernox]

If you could PR that or a helper that uses this internal util: https://github.com/cibernox/ember-power-select/blob/master/addon/utils/group-utils.js#L4 with a test I'd release a fix soon.

I am preparing a workshop for this thursday so I'm very short of time this week.

[SirZach]

It would be API breaking. There's potential, although doubtful, that some users rely on entries with groupName with no options defined to show up as groups.

I think the real solution would be for an opt-out strategy in the component declaration to say that you do or do not want groupings (default true to maintain existing behavior) as well as an ability to change what the groupName key is.

[cibernox]

I think that is unlikely, because class groups are not selectable. I think that is safe to assume that no one is relying on that.

And technically EPS is still beta.

[SirZach]

Agreed that it's a rare situation, however I would still suggest an opt-out of groups is preferred instead of hoping that they don't accidentally have groupName and options on their model.

[cibernox]

I don't think it's a real concern, since if that is the case is as simple as doing:

safeOptions: Ember.computed.map('options', function(option) {
  return { record: option };
})

{{#power-select options=safeOptions as |option|}}
  {{option.record.groupName}}
{{/power-select}}

[SirZach]

This requires that the developer knows what's happening behind the scenes.

[20v100]

I have the same issue. My model as an attr groupName that was conflicting with https://github.com/cibernox/ember-power-select/blob/master/addon/templates/components/power-select/options.hbs#L7. As a temporary workaround, I modified the "groupName" name to a different name directly on my version of ember-power-select. The error I was getting was: Uncaught TypeError: Cannot read property 'offsetTop' of null

[cibernox]

@SirZach @20v100 I think that beta.31 fixes this problem.
Having a property classGroup is not enough to be a group, it also has to have an options property to be considered a group.

[20v100]

I confirm that beta.31 did fix my problem. Thanks!