Retrieving the getter value in the setter in parent computed caches the value incorrectly

[BEGEMOT9I]

Hey, I wanted to clarify whether this behaviour is expected.
Case: an instance of a class is created in the computed, and then we try to receive the result of the computed value (test) in this class, in the check method. As a result, an incorrect result is returned. There are two causes of the invalid getter:

1. accessing the test getter inside the setter
2. calling makeObservable in the super-class

When the parent computedTest computed is created, the class getter returns the valid value.

Playground: https://codesandbox.io/p/sandbox/4nzv99

Is that intended?

[BEGEMOT9I]

@mweststrate May I poke u here?)

[mweststrate]

Seems you are calling makeObservable after assignment in Test constructor, so I suspect _test never gets marked as dirty or some other internal adminstration acts up here. I suspect your problem will go away if you go super();makeObservable(); this.test = ...

[BEGEMOT9I]

Thanks for explaining how to fix this behavior. But I'm more interested in whether this behavior is expected, because the lack of makeObservable call in the parent class (in theory) shouldn't affect the child class.

It is also not obvious why the behavior breaks in the case of synchronous reading and writing before makeObservable call, if the application of decorators by code should occur when makeObservable is called, that is, at the time of reading and writing, the getter and _test property should not yet be proxied

[mweststrate]

There is a lot of complexity and internal administration involved in how super chains are resolved, as it depends on runtime, class translation and decorator proposal version. They all influence what is visible to which makeObservable when.

For example, your subclass property is probably already visible as own property on the instance in the superclass makeObservable call (and thus turned into observable), however that super makeObservable can happen before or after that initial value in the field definition is assigned to the property, depending on environment setup. So in general just make sure to makeObservable first, so that we have visibility in future assignments. To dive deeper I recommend to just attach a debugger to it to be able to determine what is exposed to MobX about the instance during the different makeObservable calls.