You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
accessing the test getter inside the setter
calling makeObservable in the super-class
When the parent computedTest computed is created, the class getter returns the valid value.
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 = ...
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
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
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 thecheckmethod. As a result, an incorrect result is returned. There are two causes of the invalid getter:testgetter inside the settermakeObservablein the super-classWhen the parent
computedTestcomputed is created, the class getter returns the valid value.Playground: https://codesandbox.io/p/sandbox/4nzv99
Is that intended?
All reactions