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
I was playing around with the strict mode behavior and came across the following example.
import{observable,computed,action,useStrict}from'mobx';// v3.1.0useStrict(true);constvalue=observable(100);constdouble=computed(()=>{action(()=>value.set(0))();// should not be doing this!returnvalue.get()*2;});console.log(double.valueOf());
What is currently happening is that evaluating double causes its dependency value to be reset to zero right within the evaluation. Strict mode doesn't seem to take offense at this.
IMO in order to guarantee statelessness, computed expressions should be totally side effect-free with respect to the entire mobx state space, and so invoking actions within such expressions should never be allowed.
In case I'm missing something here and the current behavior is in fact intended, it would be good to understand the reasoning behind it. Otherwise it would be great to see an extra safeguard against this (anti-?)pattern, which in some cases can be very hard to spot if the invoked action buries the computed expression deep, deep in the oblivion of the stack trace.
The text was updated successfully, but these errors were encountered:
It was changed quite recently. The side effects are still forbidden, but only if the modified observable is being observed. The reason is basically to allow initializing observable values after they have been defined. For example you call init() action in some constructor (which was required in strict mode because constructor itself can't be an action) and the constructor is called from within some computed.
See #798 for more details.
I was playing around with the strict mode behavior and came across the following example.
What is currently happening is that evaluating
double
causes its dependencyvalue
to be reset to zero right within the evaluation. Strict mode doesn't seem to take offense at this.IMO in order to guarantee statelessness, computed expressions should be totally side effect-free with respect to the entire mobx state space, and so invoking actions within such expressions should never be allowed.
In case I'm missing something here and the current behavior is in fact intended, it would be good to understand the reasoning behind it. Otherwise it would be great to see an extra safeguard against this (anti-?)pattern, which in some cases can be very hard to spot if the invoked action buries the computed expression deep, deep in the oblivion of the stack trace.
The text was updated successfully, but these errors were encountered: