Why don't getters use cached value when accessed directly?

[dbstraight]

I have a vague understanding that this has something to do with how MobX reactivity works, but I would like a more thorough understanding and learn some potential options for dealing with it.

import { when } from "mobx";
import { types } from "mobx-state-tree";
import { expect, test } from "vitest";

let calls = 0;

const Model = types.model("Model", {
    a: 1,
    b: 2,
}).views(self => ({
    get sum(): number {
        calls += 1;
        return self.a + self.b;
    },
}));

// In this first test, we just access the getter a few times, and
// it runs the getter function each time
test("Only one call?", () => {
    calls = 0;
    const m = Model.create();
    expect(calls).toMatchInlineSnapshot(`0`);
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`1`);
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`2`);
});

// But in this test, we wrap everything in a `when` and
// now the getter only runs once
// See: https://github.com/mobxjs/mobx-state-tree/discussions/2102
test("When?", async () => {
    calls = 0;
    const m = Model.create();
    expect(calls).toMatchInlineSnapshot(`0`);
    when(() => true, () => {
        expect(calls).toMatchInlineSnapshot(`0`);
        expect(m.sum).toMatchInlineSnapshot(`3`);
        expect(calls).toMatchInlineSnapshot(`1`);
        expect(m.sum).toMatchInlineSnapshot(`3`);
        expect(calls).toMatchInlineSnapshot(`1`);
    })();
    expect(calls).toMatchInlineSnapshot(`1`);
});

What's going on here, and what are some ways I can ensure only-once getter execution when I'm basically treating the MST instance as a plain object?

[dbstraight]

This seems to be another option. Is it a good one? Is this a bad idea for some reason?

class Wrapper {
    private _sum: number | undefined = undefined;

    constructor(model: Instance<typeof Model>) {
        autorun(() => {
            this._sum = model.sum;
        });
    }

    get sum(): number | undefined {
        return this._sum;
    }
}

test("Wrapper", async () => {
    calls = 0;
    const m = new Wrapper(Model.create());
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`1`);
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`1`);
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`1`);
});

[coolsoftwaretyler]

There's nothing incorrect about this, but it might be confusing to read in the future since it's not clear why autorun is being called. What kind of project are you using MST with? If it's a frontend, I think you should try to use one of the frontend bindings and actually observe your model instance and its computed properties as per my longer answer.

If you're writing pure JS (maybe node? Or some module that other consumers are using) this should work fine. I don't do that too often so I can't recommend a specific pattern

[dbstraight]

This is on a model which is going be used both in frontend and on an API server. There's an expensive getter which on the frontend, we will be changing the underlying props and expect it to get rerun, but on the API server, we cache the whole model between requests (because fetching all the data to build the model is also expensive) and the underlying props won't ever change, so we want the getter to only get called once.

[coolsoftwaretyler]

Yeah I don't hate that as a solution. There are some tradeoffs here, like that expensive view will be calculated on instantiation of your Wrapper. And it's only going to get cached for as long as that Wrapper instance is alive, available, and the same instance. I'd probably leave a comment about it, but I still don't hate it.

If you're using MST server-side, you may benefit from the great work done over at mobx-quick-tree, which is MST without all the observable bindings. It's a drop-in replacement as far as I know, and very fast. Probably caches these things for you out of the box without any funky incantations.

[coolsoftwaretyler]

Hey @dbstraight - thanks for your question, and thanks for opening up a new thread. I had missed #2102 (comment) originally, and saw your comment there.

I don't know the exact code where this is happening, but I suspect it's because the cache has to happen inside whatever is observing the MobX instance.

I mostly write React Native with MobX-State-Tree. So when I access computed views like this, it's always cached. I would guess that caching behavior is actually a byproduct of a MobX observable + an observer. So for MST, something like MST store + observer HOC or MobX's when. The observable needs to be actually observed to cache its behavior.

The nice thing is, once it's observed at all, it caches for everyone. Check this out:

import "./styles.css";
import { observer } from "mobx-react-lite";
import { types } from "mobx-state-tree";

let calls = 0;

const Model = types
  .model("Model", {
    a: 1,
    b: 2,
  })
  .views((self) => ({
    get sum(): number {
      calls += 1;
      return self.a + self.b;
    },
  }));

const m1 = Model.create({ a: 3, b: 4 });
const m2 = Model.create({ a: 5, b: 6 });

function App() {
  return (
    <div className="App">
      <DoesNotCache />
      <Caches />
    </div>
  );
}

const DoesNotCache = observer(() => {
  return (
    <button
      onClick={() => {
        console.log(m1.sum);
        console.log(calls);
      }}
    >
      Not Cached
    </button>
  );
});

const Caches = observer(() => {
  const { sum } = m2;
  return (
    <button
      onClick={() => {
        console.log(sum);
        console.log(calls);
      }}
    >
      Cached
    </button>
  );
});

export default observer(App);

See here in CodeSandbox.

Notice I have two model instances. Because if you try this demo with just one instance and include the cached component, the computed value gets cached. The observer HOC is not smart enough (or unwilling, I imagine) to actually tell m1 that it's beign observed in the click handler.

Again, I don't know the actual code where this is specified, but the solution here is: observe your observable in at least one place and you'll get the caching behavior. If your observable is not observed (or if it doesn't know that it has been), I don't think the caching mechanisms will kick in.

[dbstraight]

test("Observe once", () => {
    calls = 0;
    const m = Model.create();
    expect(calls).toMatchInlineSnapshot(`0`);
    autorun(() => {
        // Do nothing with sum, but access it
        m.sum;
    });
    expect(calls).toMatchInlineSnapshot(`1`);
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`1`);
    expect(m.sum).toMatchInlineSnapshot(`3`);
    expect(calls).toMatchInlineSnapshot(`1`);
});

🤯 This is very surprising, but it definitely works. So there's something that happens when a getter is first observed that is persistant even outside of being observed?

[coolsoftwaretyler]

So here is where we set up the getters. It calls makeObservable from MobX with these options:

makeObservable(self, { [key]: computed } as any)

Which is also calling the MobX computed option here: https://mobx.js.org/computeds.html

Computed values can be used to derive information from other observables. They evaluate lazily, caching their output and only recomputing if one of the underlying observables has changed. If they are not observed by anything, they suspend entirely.

I don't know enough about the MobX codebase to actually say how this interaction happens. That's on them. But since MST is built on top of MobX, their runtime behavior becomes ours, haha.

[coolsoftwaretyler]

I don't know what "suspend entirely" means, I assume it means "they do not act as computed", but you can still call it since the resulting MST object now has that property attached (we call defineProperty on the object during the views builder function execution).

[dbstraight]

This definitely helps it all come together.

One more example, also vaguely feeling like a terrible idea, but it makes the tests work as expected. Just add this to the model:

.actions(self => ({
    afterCreate() {
        autorun(() => self.sum);
    },
}))

[coolsoftwaretyler]

I like it! Nice to keep this as part of the lifecycle of the instance itself, rather than forcing some wrapper class to know about how MST works.

Either way, I also strongly recommend a library like MobX-Quick-Tree for server side stuff if you don't need the observability but want fast, MST compatible modeling.