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
In my experience there's a bug when you have more than one copy of Mobx in your module system.
The getAtom function checks for atoms using instanceof javascript operator, which uses nominal typings (equiv. to thing.__proto__.constructor === BaseAtom) instead of using structural / duck typing (typeof thing.reportObserved === 'function' && typeof thing.reportChanged === 'function').
so an atom created by mobx A is not recognised by mobx B.
The rationale here is, when you have multiple instances of the Mobx module, you have multiple instances of the module's functions, with no pointer equality between the two otherwise matching functions. Effectively makes the constructors themselves part of a module's state (something we wish to avoid, judging by the global singleton GlobalState).
This can explain the error message in #570 when using npm 2 or some other modules setup that did not go through aggressive tree-shaking.
The text was updated successfully, but these errors were encountered:
amir-arad
changed the title
don't use instanceof operator in modules
don't use instanceof operator
Sep 22, 2016
In my experience there's a bug when you have more than one copy of Mobx in your module system.
The
getAtom
function checks for atoms usinginstanceof
javascript operator, which uses nominal typings (equiv. tothing.__proto__.constructor === BaseAtom
) instead of using structural / duck typing (typeof thing.reportObserved === 'function' && typeof thing.reportChanged === 'function'
).so an atom created by mobx A is not recognised by mobx B.
The rationale here is, when you have multiple instances of the Mobx module, you have multiple instances of the module's functions, with no pointer equality between the two otherwise matching functions. Effectively makes the constructors themselves part of a module's state (something we wish to avoid, judging by the global singleton GlobalState).
This can explain the error message in #570 when using npm 2 or some other modules setup that did not go through aggressive tree-shaking.
The text was updated successfully, but these errors were encountered: