Property get and set in component init breaks computed property

[brettburley]

I don't think this is too common of a pattern of initializing properties in an init method of a component, but caught me by surprise today.

If a computed property is get'd before its dependency is set in the init method of a component (or anytime before the component is fully initialized), the value from the get is cached and not invalidated.

See this twiddle for three examples in my-component:
https://ember-twiddle.com/63798c90dba1839c1631ce6991ac74df?openFiles=components.my-component.js%2Ctemplates.components.my-component.hbs

I would have expected all three isTrue computed properties to be true, however the one that is get and set within the init block doesn't seem to be properly recomputed.

This might be related, but I am not certain: #1789. This also seems to describe the issue: #3399, however because of #5120, this doesn't affect computed.alias anymore, but "normal" computed properties are still impacted.

[Serabe]

I think this is a duplicate of #13823. I moved the setProperties call to didRender (quick check to see if it is related) and it works as expected.

In the mentioned issue this is the comment with the explanation about how init works.

If you are OK with this, I'll close the issue.

[brettburley]

Thanks @Serabe! It looks like it probably has the same/similar root cause, but I think this is a more regular use case in that even local properties (i.e. not trying to propagate back up to the parent view) are also affected.

I think it more broadly means that you can't reliably do property initialization in the init method if you have other local computed properties that may depend on these values.

However, I'd be glad to follow-up on that other issue and close this one if you think they're sufficiently similar.

[Serabe]

Let's see what @krisselden thinks about this one. It is a bit strange because the get change the behaviour heavily, but he knows better how things should be working.

Thank you!

[krisselden]

On the init method ordering matters, no change events fire and you cannot rely on events to sort out dependencies between props. It is supposed to be initializing the object to its initial state, you have to be aware of the order and shouldn't leak out the partially initialized object to code that expects a fully initialized object

[krisselden]

The init event fires when initialize is done and all events are enabled at that point

[Serabe]

Thank you, @krisselden. I will close this then.