{"id":22539,"date":"2018-08-31T12:15:13","date_gmt":"2018-08-31T09:15:13","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=22539"},"modified":"2018-08-31T11:11:02","modified_gmt":"2018-08-31T08:11:02","slug":"javascript-mobx","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/javascript\/javascript-mobx\/","title":{"rendered":"JavaScript: Upgrading from MobX 2.7.0 to 3.0.2"},"content":{"rendered":"

As usual, you should check out the CHANGELOG<\/a>. However, let me point out a few things specifically:<\/p>\n

Don’t use the @action decorator on a singleton object that you pass to observable()<\/code>. If you have code that looks like observable({ @action f: () => {})<\/code>, you should change it to observable({ f: action(() => {})<\/code>. Apparently, using decorators on singleton objects is a little sketchy. I assume the same thing applies to extendObservable. If you’re using classes, it’s a non-issue.<\/p>\n

If you have a resolution field in package.json that lists mobx, make sure you keep it in sync with the version of mobx you’re trying to install. Otherwise, you’ll end up with multiple versions of mobx, each with their own state, and that led to ultra-weird behavior for me.<\/p>\n

When passing an object to observable()<\/code>, remember that it now makes a copy of that object. That was already the case for arrays and maps, but now it’s also the case for normal objects. Hence, when you pass an object into a store, stop using the reference to the old, non-observable object, and instead get a reference to the observable version of that object from the store.<\/p>\n

I saw some tests that would create some test object, do something that adds it to the store, and then assume that the original object reference was still valid. For instance:<\/p>\n