Reactivity in ObservableMaps

[RHeynsZa]

So I feel I understand MobX, or at least I did, until a while ago.

I have an Observable Map.

  filters: Map<string, Filter> = new Map();

   makeObservable(this, {
      filters: observable,
      activeFilters: computed,
....

Right. And Filter type has a few props, most important being

export type Filter = {
  .....
  is_active: boolean;
  state?: {
    min: number;
    max: number;
  }
}; 

Fairly simple right?

Now as for my computed value activeFilters. I understand that when I want activeFilters to update when I update the min and max, in the state, I would have to actually use/read the state, in the computed value. (Even if this isnt that intuitive)

But this doesn't work:

  get activeFilters(): Filter[] {
    logger.debug("activeFilters called");
    return [...this.filters.values()].filter((f) => f.is_active && f.state);
  }

However this does, since we're making a copy of the state, and this makes sense.

  get activeFilters(): Filter[] {
    logger.debug("activeFilters called");
    return [...this.filters.values()].filter((f) => {
      const filterCopy = { ...f };
      if (filterCopy.state) {
        filterCopy.state = { ...filterCopy.state };
      }
      return filterCopy.is_active && filterCopy.state;
    });
  }

So does MobX really not see state being checked with f.is_active && f.state

[RHeynsZa]

I very much feel like Qwertie in this reply, as this problem really touches on my issue
https://stackoverflow.com/questions/54560440/how-can-i-observe-any-change-property-added-removed-or-changed-in-a-mobx-obse#comment132874545_54560440

What is the proper way to observe changes in an ObservableMap?

[RHeynsZa]

+1

[mweststrate]

Can you create a small code sandbox reproduction? Superficially thinks look ok and should work, but hard to tell without having runnable what is going wrong here

[mweststrate]

Can you create a small code sandbox reproduction? Superficially thinks look ok and should work, but hard to tell without having runnable what is going wrong here. Keep in mind that when you use reaction like in the SO question, you'll have to actually access in the reaction function the things you want to respond to. In the example there the .filter reference is accessed, but none of it's fields, so it will only respond if an entirely different filter object is assigned. If that confuses, you, make sure to read the "understanding reactivity" section in the docs, or start with autorun function instead, which is a bit easier to set up in these cases.

[mweststrate]

Can you create a small code sandbox reproduction? Superficially thinks look ok and should work, but hard to tell without having runnable what is going wrong here. Keep in mind that when you use reaction like in the SO question, you'll have to actually access in the reaction function the things you want to respond to. In the example there the .filter reference is accessed, but none of it's fields, so it will only respond if an entirely different filter object is assigned. If that confuses, you, make sure to read the "understanding reactivity" section in the docs, or start with autorun function instead, which is a bit easier to set up in these cases.

Make sure to read the comments in the SO answer, it explains it very well; make sure you read the values you are interested in. If you just read the object itself, you are only tracking the object reference, which often never changes.

[RHeynsZa]

Yeah I can make a sandbox, but I think this does answer my question

If you just read the object itself, you are only tracking the object reference, which often never changes.

But how would I fire a reaction if any value changes in a object then? Is toJSON really the answer?

[urugator]

Firstly computeds are not eager, they should not contain side effects - logging a value is a side effect. You can think about them like normal getters with cached result, which is invalidated when some dependency changes. You don't have to create any copies in computed to extort subscription or something like that.

Is toJSON really the answer?

Sort of. The problem is the question. There is usually no point in observing state changes, unless you actually want to do something with the changed state. What you want to do is the crucial part here, because it defines what mobx will observe. Eg:

autorun(() => {
  log(object);
})

doesn't fire whenever object changes, it fires whenever the outcome of the log call could be different. So if log is implemented as arg => console.log(typeof arg), then there is no point in running autorun multiple times, because it would just keep printing the same string ("object") over and over.
If log is implemented like arg => console.log(arg), it prints every prop of the object, therefore it fires whenever any prop changes etc.
Usually you would use autorun/reaction to keep some other system (DOM/stdout/backend) in sync with your state. It's very much like React.useEffect, but dependencies are resolved automatically.
If you just want to "count" changes, you have to tell mobx what exact changes are you interested in by "artificially" accessing all the relevant observables - toJSON does that by traversing the whole object.

[urugator]

Traversing an object without creating a copy is as efficient as you can get with autorun/reaction. We don't have a function to do that.
You can also take a look at deepObserve from mobx-utils, but note it doesn't fire once at the end of action like autorun/reaction, but immediately on any change.

Neither you or Qwertie stated what the actual goal is - again, knowing that object changed definitely isn't the whole story. You could be appoaching the problem in the wrong way or maybe mobx isn't a good tool to solve it. If the question simply is "how to tell anything in object changed using mobx", regardless whether such question even makes sense in mobx context, then the above is the answer.

[RHeynsZa]

Ah I see. I'll try explaining my goal, but if it isnt clear, let me know and I'll make a code sandbox.

I have a list of different filters, and those are enabled/disabled ad hoc, with a few variables, which are stored in state, to filter a list of values.

You can very much think of it as one of these advanced filters you see on shopping sites

I create a computed value activeFilters to get the list of active filters, and do the actual filtering.

Based on my initial code, activeFilters updates fine when filters are activated or disabled. However, I also need activeFilters to update with the changes to the state, which it of course doesn't, not without something like toJSON

[urugator]

Hm, I think you're incorrectly asuming that activeFilters must "recompute" in order to notify any other derivation that depends on state of an active filter, but that's not the case:

@computed
get activeFilters(): Filter[] {   
  return this.filters.values().filter((f) => f.is_active);
}

// This will "react" to `min`/`max` changes even without `activeFilters` changes
@computed
get filteredData() {
   return this.data.filter(entry => this.activeFilters.every(filter => entry > filter.state.min && entry < filter.state.max));
}

Is this the case or not? If not, why activeFilters has to change when filter.state changes?

[RHeynsZa]

Yeah exactly. I come from rxjs, so observable streams are where my head is at. Will the code above work?

[urugator]

As @mweststrate pointed out a filter would actually look like this:

filter$ = new BehaviorSubject({
  is_active$: new BehaviorSubject(false),
  state$: new BehaviorSubject({
    min$: new BehaviorSubject(0),
    max$: new BehaviorSubject(0),
  })
})

So filteredData$ can subscribe not just to activeFiltes$, but also to individual nested subjects and combine them.
The tricky part in RxJS would probably be, how do you unsubscribe from these inner behavior subjects, if you replace the filter or state object as a whole. (EDIT: if there is a simple way please let me know I am actually curious)

[mweststrate]

yes. But in rxjs I'd combine multiple streams here as well, so in terms of RxJS the above would be an combineLatestAll of the filter stream. To understand MobX, basically think of each and every object property as being a separate stream, but with batching to avoid the diamond problem and skip irrelevant intermediate states, and a combineLatestAll on every stream that you actually read something from, rather than just naively all streams.

…

On Wed, Apr 12, 2023 at 1:40 PM Ruan Heyns ***@***.***> wrote: Yeah exactly. I come from rxjs, so observable streams are where my head is at. Will the code above work? — Reply to this email directly, view it on GitHub <#3659 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBFU2EUFI5O43SFJUZDXA2IBJANCNFSM6AAAAAAWCPIICQ> . You are receiving this because you commented.Message ID: ***@***.***>