3.1-beta.5 changes to scheduling a task that causes a re-render

[alexlafroscia]

I have an Ember contextual component that does some work during the initial render to register itself with its parent. This registration process can cause a CP to be updated, and I want to render the the updated value of the CP on the first "paint".

The code can be found here for reference.

Before Ember 1.13 the CP would just be computed twice in a single render, which was fine. But Ember 2 breaks that behavior (for understandable reasons).

Right now, I schedule a callback in the actions queue during render which triggers the CP change, and the next run loop updates the DOM accordingly. This has been working fine until Ember 3.1, where that second "render" cycle doesn't happen during tests. An example test can be found here.

Using that as an example, what was happening before was that the render function resolved once the run queue was empty, so that when I go to validate that the first step is visible, the CP has already updated and made the step visible. However, now the CP has not been re-computed yet, meaning that the step is not yet visible. This causes a lot of these tests to fail.

My question then is two-fold:

1. Was this change intentional?
2. If it was, what would be the right way to approach a declarative API like this now?

With so much of Ember's power coming from the template, it seems like moving in the wrong direction to break some of the behavior that allowed for declarative APIs like the one in that addon.

[rondale-sc]

I've run into this myself. Very eager to hear the answers to these questions. Would be interested in helping figure out a solution to this problem eitherway.

[rwjblue]

@alexlafroscia - I picked this up to poke at it, but cannot replicate a failure (outside of #16311). I submitted alexlafroscia/ember-steps#98 (with the upgrade to 3.1.0-beta.5) to check ember-steps' CI too (you can see the passing CI run here).

[rondale-sc]

Was unable to reproduce this locally. But I am seeing a failure remarkably similar to this in my main codebase. I'm trying to see if I can get a reproduction for this issue.

[alexlafroscia]

Could the issue be related to a conversion of the addon to TypeScript (and thus, a move to ES6 classes)? It's actually my TypeScript re-write branch that's having this problem...

This build should show the issue correctly (although it's still running at the time of writing): https://travis-ci.org/alexlafroscia/ember-steps/jobs/362233312
Specifically, a bunch of tests fail because it cannot find the "first step", which would have been computed by the isActive CP in step-manager/step.

Is ES6 class usage at a place right now where if that is broken, it's not a concern?

[rwjblue]

@alexlafroscia - #16466 may be related (I paired with @rondale-sc on his issue and tracked it down to this...)

[rwjblue]

@alexlafroscia - I believe that the issue you are seeing is that you are attempting to add a computed property per-instance without Ember.defineProperty. As of Ember 3.1 adding a computed property to an instance (e.g. without Ember.Object.extend() usage) will not setup a native ES5 getter, and it will not be properly notified of changes. See #16427 for some additional background on that...

[alexlafroscia]

Hmm, interesting. Is there a different way that an ES6 class should set computed properties rather than what I'm doing there, which is essentially

class Foo extends Ember.Object {
  someComputed = computed('dependent', function() {
     ...
  });
}

Would the decorator version of computed from ember-decorators be the right way to approach this instead?

[alexlafroscia]

It looks like using computed from @ember-decorators/object will work instead. Thanks for helping me dig into this, @rwjblue! It was definitely the problem of trying to define a computed property without Ember.Object.extend