double render

[jlami]

It looks like the current solution to detect double renders does not work in newer ember versions. A lot of your travis builds are failing. I'm hoping this has something todo with the double render assertions I'm getting a lot of in my applications.
I've currently disabled them with ember features (EMBER_GLIMMER_DETECT_BACKTRACKING_RERENDER set to false), but I think Ember 3 might have stricter behaviour on this. So I was hoping there would be a solution to this problem.

I think meta.readableLastRendered is not used anymore by ember? (https://github.com/kellyselden/ember-macro-helpers/blob/master/addon/create-class-computed.js#L71)

The best I could find was https://github.com/emberjs/ember.js/blob/master/packages/ember-metal/lib/transaction.js where the assertion is raised and some other meta variable could be used instead of readableLastRendered. But I feel like detecting double renders is kind of iffy. Shouldn't this be handled in a better way by ember in general?

[edit]
I think the double render is causing troubles even without doing the click in the current test. https://github.com/kellyselden/ember-macro-helpers/blob/master/addon/create-class-computed.js#L153 seems to trigger an invalidation of the 'parent' property when setting up the computed property.

[jlami]

I believe the problem is that setting the properties in a computed property triggers the double render.
I've tried to fix this by using observers for the nonStrings contents here: master...jlami:create-class-computed-double-render

Don't really want to make this a PR yet, because I don't really like the current solution. I especially don't like the necessity of the runloop part. Without it nested create-class-computed calls don't get updated correctly. This is because the ordering of observers is not well defined.

I also think it might be possible to remove some observers if we only 'cache' non string values. But this might be difficult if composing the resulting string might give some high level array lookup.

[DuBistKomisch]

Seems like this is probably highly related to my issue #159. I have a reproduction linked there if that helps your investigation.

[jlami]

Thanks, I'll certainly look into your test case.

[mriska]

@jlami That would be highly appreciated, I have also run into this issue and took a stab at fixing it, but couldn't get anywhere.

[kellyselden]

Should be fixed by #188, please confirm.