-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global state sharing should by default be off #621
Comments
+1 I had the same problem where a player component of mine was using an older version of mobx while the website that used that component had a newer version. |
Referencing SharePoint/sp-dev-docs#251 |
Seems reasonable, however instead of turning global sharing on, shouldn't MobX provide a way for some kind of state scoping? Something like |
@kmees pushed test build: @urugator: the globalstate will (would) be shared by default, but has an internal version number (to check whether the semantics / format of globalstate hasn't been changed), which can be compatible for the span of multiple actual mobx versions, but changes sometimes if the internal algorithm changes. If package deduplication / peer dependencies are set up properly, this feature should actually never be needed. |
Can now be installed as |
Closing this issue as [email protected] is now available, which addresses this issue. Changelog: https://github.com/mobxjs/mobx/blob/mobx3/CHANGELOG.md#300. The changes in more details: https://github.com/mobxjs/mobx/pull/725/files. Feel free to re-open if questions arise! |
We query the mobx global context in some internal test drivers. it's an easy way to supply assertions about the context of execution. for example, this assertion: function isInTransaction(){
const globalCtx = (typeof self === 'object' && self.self === self && self) ||
(typeof global === 'object' && global.global === global && global) ||
this;
return !!(globalCtx.__mobxGlobal && globalCtx.__mobxGlobal.inTransaction);
} helps us with a unit-test regression test that prevents over-eager renders. |
I think `extras.getGlobalState` is what you are looking for :)
Op ma 23 jan. 2017 om 10:44 schreef Amir Arad <[email protected]>:
… I query the mobx global context in some internal test drivers. it's an
easy way to supply assertions about the context of execution. for example,
this assertion:
function isInTransaction(){
const globalCtx = (typeof self === 'object' && self.self === self && self) ||
(typeof global === 'object' && global.global === global && global) ||
this;
return !!(globalCtx.__mobxGlobal && globalCtx.__mobxGlobal.inTransaction);
}
helps us with a regression test that prevents over-eager renders.
This is not a blocker for us, but it would be so much easier to have a way
of getting the module's internal state for quickly writing specialized
tools and drivers on top of mobx.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#621 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhMfDVhOA3EeEpmNBsZQ2S9bUhSVoks5rVHZ9gaJpZM4Kcc9h>
.
|
Oh, and use `inBatch` in MobX 3
Op di 24 jan. 2017 om 11:53 schreef Michel Weststrate <[email protected]
…:
I think `extras.getGlobalState` is what you are looking for :)
Op ma 23 jan. 2017 om 10:44 schreef Amir Arad ***@***.***>:
I query the mobx global context in some internal test drivers. it's an
easy way to supply assertions about the context of execution. for example,
this assertion:
function isInTransaction(){
const globalCtx = (typeof self === 'object' && self.self === self && self) ||
(typeof global === 'object' && global.global === global && global) ||
this;
return !!(globalCtx.__mobxGlobal && globalCtx.__mobxGlobal.inTransaction);
}
helps us with a regression test that prevents over-eager renders.
This is not a blocker for us, but it would be so much easier to have a way
of getting the module's internal state for quickly writing specialized
tools and drivers on top of mobx.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#621 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhMfDVhOA3EeEpmNBsZQ2S9bUhSVoks5rVHZ9gaJpZM4Kcc9h>
.
|
Just wanted to note that we had a very difficult to debug issue that was solved using We're using multiple npm modules on a project, and two of them both require 'mobx'. One includes the other. Webpack runs on the first and bundles them both together. Each contains its own stores, but the parent package needs to observe some things from the included package, and the included package also observes some things from stores injected from the parent (included package is a React Component). We'd started using mobx back at v2.6 and this setup worked fine, but we recently upgraded to v3 and suddenly neither module could react to any observable from the other. After a lot of searching we finally found this solution, but as you mention its deprecated. Webpack is already supposedly de-duplicating the packages so unless we're missing something in our build steps (entirely possible), we still need this functionality. |
@andrew-luminal also there's https://www.npmjs.com/package/ifndef |
By default, MobX tries to let observables / reactive functions, that are provided by different instances of the library, work together. That is convenient if you multiple packages that ship with their own mobx version, and want to use them together. But probably this functionality should be disabled by default, as it might lead to unexpected results. Running MobX by default in isolation is probably the better way to go.
See for example:
https://twitter.com/kevin_mees/status/789134362440761344
The text was updated successfully, but these errors were encountered: