Selected item not working

[DenimTornado]

Template:
{{#power-select selected='Choose category' verticalPosition='below' options=categories onchange=(action "onchangeCat") as |category|}} <span>{{category.name}}</span> {{input value=category type="hidden" name="category"}} {{/power-select}}

I don't see that 'selected' element.

[broerse]

Just tested with ember-data 3.4 but it seems all versions above 3.1.1 break ember-power-select. See also emberjs/data#5575

[runspired]

@broerse unsure what power-select is doing but I don't think the issue is with ember-data

[runspired]

I'd be skeptical of this: https://github.com/cibernox/ember-power-select/blob/master/addon/components/power-select.js#L542-L546

[broerse]

@runspired no above ember-data 3.1.1 https://github.com/cibernox/ember-power-select/blob/master/addon/templates/components/power-select/trigger.hbs#L1 does not detect change on the new proxy object.

[broerse]

@runspired see the test on https://ember-twiddle.com/8699e6c887c9eb2cb4344fb1d2551dbe?openFiles=templates.application.hbs%2C if you roleback to ember-data 3.1.1 it works fine.

[broerse]

@runspired you can also see this failing now on https://bloggr.exmer.com . Press Create and select an author.

[runspired]

@broerse so as I've said elsewhere, power-select should not rely on the proxy being swapped for a new instance.

It looks like from the twiddle that it works just fine in ember-data 3.4 for power-select, but the blockless version is broken. What's the implementation difference?

[jlami]

The problem actually lies here: https://github.com/cibernox/ember-power-select/blob/master/addon/components/power-select.js#L147

This is only called once if the blockless version is used due to the fact that an extra component level will prune the property change notification for the second component.
So the code does not triggers a second update to the internal state if the previous value is null.

@broerse so as I've said elsewhere, power-select should not rely on the proxy being swapped for a new instance.

@runspired But my feeling is that being able to listen to a belongsTo value should be possible. It has always been in the past. And not changing the Proxy only when it starts at null seems the breaking change here. Why not keep behaviour from the past, which I think is in line with normal ember behaviour?

[cibernox]

I just want to ACK on this. I'm not sure what changed in ember-data. There is certain parts of EPS that try to unwrap ED relations but not sure what might be going on.

If anyone can create a failing test that would be great of course, but I'll look into it either way.

[runspired]

Posting this comment here for visibility into what I suspect is going on: emberjs/data#5584 (comment)

[broerse]

@cibernox I am not sure it can be fixed here because it seems to me that the ember-data change needs change on all levels. See Twiddle https://ember-twiddle.com/8699e6c887c9eb2cb4344fb1d2551dbe?openFiles=controllers.application.js%2C . There was a test created that nailed the problem but it was changed to test for other problem. See emberjs/data@e01c74f

[broerse]

@cibernox @runspired Just until Ember is changed to work with the new ember-data above v3.1.1 we need the classic behavior to fix this issue. I released ember-data-classic v3.4.0 to work around this for now. You can see ember-power-select working again on https://bloggr.exmer.com/ Hope this will be resolved on all levels soon.

[Techn1x]

Is there a workable workaround for this until ember-data releases a fix? Already running ember-data 3.2.1... don't particularly want to downgrade..

[runspired]

@broerse @Techn1x ember power select is at fault here, it needs to be changed to something less brittle. It’s possible that the behavior of ember’s component lifecycle hooks might also be improved; however, it makes no sense to do a buggy thing in ember-data to support a bug in power select.

[broerse]

@Techn1x We switch all projects to ember-data-classic v3.4.0 and all components worked again. This is a temporary workaround for components that need to check for change 2 components deep. So it works for all components that need to do this not just ember-power-select.

[broerse]

@runspired The change in ember-data is not necessary wrong but it break all components that need to check for change 2 components deep. ember-power-select works that way so perhaps it is better to say " ember is at fault here" ;-)

[runspired]

@broerse power-select can easily change to use a hook that does trigger (willRender), installs a computed property that watches the dependent keys appropriately, or watches content of PromiseProxies to recompute.

This can also be fixed by end users by resolving async relationships before passing them into the component.

[cibernox]

I updated the version of ember-data used in the addon and all the related tests are passing. Is there an easy way to create a reproduction I can use to find a workaround?

[broerse]

@cibernox The failing test is here: martinic/ember-data-classic@d0cc97a

The temporary solution is here: martinic/ember-data-classic@c6b6fa4

And reproduction off the problem is here: https://ember-twiddle.com/8699e6c887c9eb2cb4344fb1d2551dbe?openFiles=controllers.application.js%2C

The problem is you can't see change 2 components deep. The ember-data guys say Ember must change to support this new behavior so if you can find a workaround until this is all resolved that would be great.

[runspired]

@broerse

• that test doesn't test what it thinks it does
• the temporary solution is not relevant here

The ember-data guys say Ember must change to support this new behavior

We don't say this. We say that Ember potentially could. However, this hook behavior has been well documented and known since 2.0.

The twiddle though is fairly good at showing the issue even if it is an overly complex replication (that attrs hooks only trigger for referential changes to attrs).

[broerse]

@cibernox I don't agree with @runspired on the points above so please decide for yourself what the issue is.

I only changed the ember-data version to ember-data-classic to show the temporary solution solves the problem for now. See https://ember-twiddle.com/13467f39629dd7ce0448ba4601db2732?openFiles=twiddle.json%2C

Also take a look at emberjs/data#5575 (comment) by @jlami for more info on the problem.

[runspired]

@broerse as I’ve mentioned privately, please stop directing folks to your buggy fork of ember-data. It is not a solution, nor is it even a correct behavior for ember-data, it happens to work for a few apps but it likely breaks many more.

Furthermore, discouraging the proper fix from taking place here is equally disturbing.

It’s nice that you disagree that the test you pointed out is incorrect, but I’m sorry, that test is broken and not testing at all the behavior that you believe you are fixing.

Lastly, it’s nice that you “don’t agree” on what the ember and ember-data folks think about ember’s lifecycle hooks, but that doesn’t change the fact that their behavior in this regard has been known and documented since 2.0.

That a bug in ember-data allowed an incomplete implementation in power-select to work when it shouldn’t have for ember-data is a neat quirk of history, but ultimately power-select has this issue with any proxy or wrapper object today, not just ember-data relationships, and it is time to fix it.

[jlami]

Lastly, it’s nice that you “don’t agree” on what the ember and ember-data folks think about ember’s lifecycle hooks, but that doesn’t change the fact that their behavior in this regard has been known and documented since 2.0.

Could you point me to the documentation regarding this specific behavior?

[runspired]

One of many previous issues pointing this out emberjs/ember.js#12696 (it has also been a common pitfall folks have stumbled into when helping them in Slack).

Here's what the guides say which could be more clear.

didReceiveAttrs runs after init, and it also runs on subsequent re-renders, which is useful for logic that is the same on all renders. It does not run when the re-render has been initiated internally.

Since the didReceiveAttrs hook is called every time a component's attributes are updated whether on render or re-render, you can use the hook to effectively act as an observer, ensuring code is executed every time an attribute changes.

There are two things to note here:

1. effectively, this is a re-render initiated internally (due to the bound property changing), although this is unclear and I wish the docs clearly stated that attribute changes are detected by reference.

2. Note the language here: ensuring code is executed every time an attribute changes. This language is precise, but also not what most folks will think, and so again I think likely we should clarify it. Internal mutations to an object or an array do not mutate the reference. This is where Rob's comment in the above issue about computed properties still having a place in the glimmer component world applies.

[jlami]

@runspired Thanks for the reply. I agree that this language might be precise, but still not clear enough. It would certainly be good to elaborate on the distinction between an internal re-render and a normal one, and the role reference play here.
I think the problem is compounded here because the one-level deep component works fine. But only due to the notifyPropertyChange, which does not work between component levels. The fact that many components will work because of this makes it easy to write code that does not work when wrapped in another component.

I still think Proxy objects are not inherently constant and you could still (easily) choose to let the belongsTo computed just return a new instance.
You can say that constant Proxy references are correct code and should be allowed. But if it is a known problem that multi-level components wont work without extra (overly complicated) code, wouldn't it be easier to fix the problem at the source and just not use them? (But I'm curious if this could be solved cleanly on the user/power-select side of things)

@cibernox Would you like me to write a test that covers this?

[cibernox]

Can you all check if 2.0.6 fixes your problems with newer versions of Ember Data?

[broerse]

@cibernox We tested it on some projects and we had to add checks for instanceof ObjectProxy but then all works again with ember-power-select v2.0.6 and the newest Ember Data. https://bloggr.exmer.com/ is also fixed with this version. Still think this check should not be necessary and goes against the Ember do what I want philosophy but that is no subject to discuss here. We are happy for now. Many thanks!

[Techn1x]

FYI, we upgraded EPS and this fixed the issue were were having