Dependencies upgrading broke my app :(

[antoshkow]

I have a frontend app written on next.js + mst (I use getInitialProps as SSR method)

So, all of a sudden after updating the yarn.lock file, store on the ssr side stopped to update :(

This dependency cause the problem:

mobx@^6.3.2:
version "6.10.1"
resolved "https://registry.yarnpkg.com/mobx/-/mobx-6.10.1.tgz#4bf9a838d7a99dc7f9d6cdf35e2ea1bd62f5561a"
integrity sha512-oKibSy1GDJI+KfCKbqgFbxYt7DcpZ6jkq9byTzr9AYDGWOg4snI9Ux21U3hpFqhK4Ouw78CJQomRDbfXo1R6pg==

This works fine:

mobx@^6.3.2:
version "6.9.0"
resolved "https://registry.yarnpkg.com/mobx/-/mobx-6.9.0.tgz#8a894c26417c05bed2cf7499322e589ee9787397"
integrity sha512-HdKewQEREEJgsWnErClfbFoVebze6rGazxFLU/XUyrII8dORfVszN1V0BMRnQSzcgsNNtkX8DHj3nC6cdWE9YQ==

Is it a bug or something that break backward compatibility? Thnx you in advance for a help 😊

[urugator]

Which mobx-react / mobx-react-lite version ?
What do you mean on SSR side? Don't you use enableStaticRendering(true) ? Can you elaborate a bit? Provide snippet/reproduction?

[antoshkow]

mobx-react version

"mobx": "^6.3.2",
"mobx-devtools-mst": "^0.9.30",
"mobx-react": "^7.2.0",
"mobx-state-tree": "^5.0.2",

Here is an example of my _app.tsx next.js page where I initialize the store.

const NextApp: FC<NextAppProps> = ({
  Component,
  pageProps,
  initialState,
  lang,
}) => {
  const store = useCreateStore(initialState, lang) // there is the logic of creating mst models
  // ... other logic, works fine
}

//  wrapper for ts types, we don't have legal possibility to make it like func component
class AppWrapper extends App {
  render(): any {
    return <NextApp {...(this.props as NextAppProps)} />
  }

  static async getInitialProps(appContext): Promise<{
    initialState: any
    pageProps: any
    lang: string
  }> {
    const appProps = await App.getInitialProps(appContext)

    const store = initializeStore({
      isServer: !canUseDOM(),
      snapshot: null,
      lang: appContext.ctx.locale,
    }) // there is the logic of creating mst models

    // ... here is asynchronous logic and function calls that have to update store

    return {
      ...appProps,
      initialState: getSnapshot(store),
      lang: appContext.ctx.locale,
    }
  }
}

export default AppWrapper

This worked correctly until I updated this dependency, but now after the async logic in getInitialProps I get the store with the initial state on client

[cmdcolin]

i was experiencing some weird things i think related to getSnapshot (MST) maybe also...haven't pinned it down to a small repro yet but seemed related to the 6.10.0->6.10.1 upgrade

[urugator]

What we changed in 6.10.1: If you create an observable inside a batch (all action/derivation/computed runs in a batch) and you modify that observable inside that same batch, the observable won't notify any observers (because the only observer it could notify is the one that is already running).
Now it occurs to me it could actually break computeds, will have to investigate, but I won't to be able to get to it this week. If that's the case I think a possible fix would be to change the following:

mobx/packages/mobx/src/core/atom.ts

Lines 70 to 87 in 4ffc001

	public reportChanged() {
	if (globalState.inBatch && this.batchId_ === globalState.batchId) {
	// Called from the same batch this atom was created in.
	return
	}
	// Avoids the possibility of hitting the same globalState.batchId when it cycled through all integers (necessary?)
	this.batchId_ = NaN
	startBatch()
	propagateChanged(this)
	// We could update state version only at the end of batch,
	// but we would still have to switch some global flag here to signal a change.
	globalState.stateVersion =
	globalState.stateVersion < Number.MAX_SAFE_INTEGER
	? globalState.stateVersion + 1
	: Number.MIN_SAFE_INTEGER
	endBatch()
	}

to

    public reportChanged() {
        if (!globalState.inBatch || this.batchId_ !== globalState.batchId)) {
            // We could update state version only at the end of batch,
            // but we would still have to switch some global flag here to signal a change.
            globalState.stateVersion =
               globalState.stateVersion < Number.MAX_SAFE_INTEGER
                  ? globalState.stateVersion + 1
                  : Number.MIN_SAFE_INTEGER
             // Avoids the possibility of hitting the same globalState.batchId when it cycled through all integers (necessary?)
             this.batchId_ = NaN
        }

        startBatch()
        propagateChanged(this)               
        endBatch()
    }

The point is to prevent version update without preventing the notification.

[urugator]

A test for broken computed would look like this

runInAction(() => {
  const o = observable.box(0);
  const c = computed(() => o.get());
  expect(c.get()).toBe(0);
  o.set(1);
  expect(c.get()).toBe(1); // would fail
})

[mweststrate]

Above test indeed fails, the fix above fixes it, but seems to break autorun's scheduling themselves, see: #3748