Binding to a child component causes deprecation warning

1

When you bind to a value of a child component (using viewName) or when you observe that value in one of your properties you get the following deprecation warning:

`DEPRECATION: You modified childComponent.prop twice in a single render. This was unreliable in Ember 1.x and will be removed in Ember 3.0 [deprecation id: ember-views.render-double-modify]``

I was able to reduce my problem to this code. Although in my real application I have a computed property depending on childComponent.prop which causes the same warning. prop is not part of the model.

I guess I could have an action that fires every time the value changes. But I think this should work or why else does viewName exist? Is this a bug?

2

Although in my real application I have a computed property depending on childComponent.prop

Considering DDAU - Data Down, Actions Up approach, your computed property should not depend upon child component data, it should depend on data on same level, where you can then pass that data to child component. You should catch actions from child component and then mutate your data. If using actions is too burdensome you can try using mut helper, The Transition to Ember 2.0 in Detail.

1 Like
3

I’m aware that I could go the actions route. My real question was why this doesn’t work and for what use cases else viewName exists.

Also maybe I’ve oversimplified the example a bit. I’ve updated it to be a bit closer to our actual code. child-component could be any (possibly also third party) component that supports our interface. Also computedClasses observes and reads more than only one property.

4

I’ve thought up a workaround:

Instead of observing childComponent.someProperty I observe bufferedChildComponent.someProperty. Then I have an observer on childComponent that sets bufferedChildComponent in the afterRender queue. See this twiddle based on my previous example.

This is good enough for my use case. Any additional input concerning my original question would still be welcome!

5

I was more referring to this Ember Twiddle

6

Alright but this is a lot of overhead which I would need to have for every property affected. Also this wouldn’t work if the property in the child component would have an initial value. The initial state always needs to be passed in.