Mobx Array Handling is Unintuitive

[grithin]

I like mobx. I built a complex form handler with it in 2021. Coming back to it, I've noticed unexpected behavior that I imagine throws many people off and is probably one of the reasons mobx is not more popular. I understand this is a byproduct of the behavior of proxies, but if you look at something like vue, they manage the push well (https://codepen.io/cfjedimaster/pen/GObpZM) . I imagine very few people who initially put a shallow observe on an array intended it to only observe a full swap (reference change).

Shallow Array Unexpected Behavior

import { makeObservable, observable, action, autorun, toJS } from "mobx"
/*
The mobx observable array handling (ObservableArrayAdministration), is horrible.
*/
let observed;
// 1. The whole array is not observed unless swapped
observed = observable({ b: ['moo'] })

autorun(() => { // runs once for init
  console.log("Whole array observed", observed.b)
})
// `push` does not trigger
action(() => observed.b.push("bob"))()
// `delete` does not trigger
action(() => delete observed.b[0])()
// element assignment does not trigger
action(() => observed.b[1] = 'foo')()

// full array assignment does trigger
action(() => (observed.b = "foo"))()


// 2. all elements and `length respond to changes of any other elements or `length`
observed = observable({ b: ["moo", "bill"] })
autorun(() => {
  console.log("autorun 2", observed.b.length)
})

// `push` triggers (expected)
action(() => observed.b.push("bob"))()

// element assignment triggers (unexected)
action(() => observed.b[0] = 'smoo')()

// To impress the oddity of triggering when some other property changes:
autorun(() => {
  console.log("autorun 3", observed.b[1])
})

// assignment to different-than-observed-element triggers
action(() => observed.b[0] = '123')()

This last bit surprised me when I found a component observing x.length re running when x.length did not change.

Deep Array Unexpected Behavior

I wondered whether deep array observable would solve some of these problems. But, it results in more unexpected behavior.

let observableDeep = (x)=> observable(x, {}, {deep:true})
let observed

// 1. push does trigger, but other element changes don't
observed = observableDeep({ b: ['moo'] })

autorun(() => { // runs once for init
  console.log("Whole array observed", observed.b)
})
// `push` does trigger
action(() => observed.b.push("bob"))()
// element assignment does not trigger
action(() => observed.b[0] = 'foo')()

// `delete` does not trigger
action(() => delete observed.b[0])()
// new element assignment does not trigger
action(() => observed.b[1] = 'foo')()

// full array assignment does trigger
action(() => (observed.b = "foo"))()

// 2. all elements and `length` respond to changes of any other elements or `length`
observed = observableDeep({ b: ["moo", "bill"] })
autorun(() => {
  console.log("autorun 2", observed.b.length)
})
// `push` triggers (expected)
action(() => observed.b.push("bob"))()

// element assignment triggers (unexected)
action(() => observed.b[0] = 'smoo')()

observed = observableDeep({ b: ["moo", "bill"] })
autorun(() => {
  console.log("autorun 3", observed.b[0])
})

// separate element assignment triggers (unexpected)
action(() => observed.b[1] = 'smoo')()

Most annoying, observing x.length triggers on an element change regardless of whether x.length changes.

Popularity and Changes

Reactivity with proxies is somewhat complex and that limits audience. Vue deals with this by hiding some things. For instance, in the https://codepen.io/cfjedimaster/pen/GObpZM example, the methods.checkForm is a sort of mobx action, where the errors observable changes only cause a single re-render. The vue developer doesn't need to know that.

However, when you add on to the complexity unexpected behavior, like x.push handling, observing x.length, etc, you get even more of a fall off of audience.

Years ago when I started with mobx, I had a lot of frustration before I found toJS, which should be very apparent in the docs.

Any way, I've not considered how to solve these things until there is an acknowledgement that they are problems and should be solved.

[urugator]

You're just confused by console.log behavior. If everything is deeply observable (which is default, no need for explicit { deep: true }), whenever there is a change that would cause the "outcome" of an autorun to be different, the autorun will trigger.
The "outcome" of console.log("Whole array observed", observed.b) is something like Whole array observed Proxy(Object) {} regardless of the b's content. So there is no reason for autorun to re-run, when b's content changes.
Imagine it's not a console, but a DOM or React's virtual DOM or fetch. You don't want to cause updates if the DOM would look the same or trigger request for the same set of params.
The console in dev tools allows you to inspect the passed reference, but this is not visible for autorun, you would have to do this inspection in autorun itself. Also notice the thing you see in the console is not a snapshot taken at a time of running console.log, but a real time reference:

const o = {};
console.log(o);
o.a = 5;
// inspecting `o` in dev tools displays `{ o: 5 }`

So in some sense the autorun would have to see in the future, which would be quite cool, but we are not there yet.

The shallow array works exactly as you would expect.

Most annoying, observing x.length triggers on an element change regardless of whether x.length changes.

Could be the case, not sure atm. I think the reasoning could be that observing length alone is so rare, that extra length observable per array isn't worth it, but it's just my guess or something I vaguely remember.