Mobx: Global state sharing should by default be off

[mweststrate]

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

[nightwolfz]

+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.

[kmees]

Referencing https://github.com/SharePoint/sp-dev-docs/issues/251

[urugator]

Seems reasonable, however instead of turning global sharing on, shouldn't MobX provide a way for some kind of state scoping? Something like require("mobx")("stateScopeId")
EDIT: Btw, do I understand right that the state will still be shared globaly (between packages), but not between the different MobX versions...?

[mweststrate]

@kmees pushed test build: [email protected]. Would you mind checking whether that solves the issue?

@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.

[kmees]

@mweststrate it does 👍 https://github.com/kmees/spfx-react-mobx-webpart-starter

[mweststrate]

Can now be installed as [email protected] as well

[mweststrate]

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!

[amir-arad]

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.
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.

[mweststrate]

I think extras.getGlobalState is what you are looking for :)

Op ma 23 jan. 2017 om 10:44 schreef Amir Arad [e-mail]:

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
https://github.com/mobxjs/mobx/issues/621#issuecomment-274441420, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhMfDVhOA3EeEpmNBsZQ2S9bUhSVoks5rVHZ9gaJpZM4Kcc9h
.

[mweststrate]

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 [e-mail]:

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
https://github.com/mobxjs/mobx/issues/621#issuecomment-274441420, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhMfDVhOA3EeEpmNBsZQ2S9bUhSVoks5rVHZ9gaJpZM4Kcc9h
.

[andrew-luminal]

Just wanted to note that we had a very difficult to debug issue that was solved using mobx.extras.shareGlobalState().

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.

[amir-arad]

@andrew-luminal also there's https://www.npmjs.com/package/ifndef