is all state obervable state

[rufus2021]

in the case where something is directly doing updates and it isn't a reaction to a state update, is that still considered observable state to mobx? in this case outsideRenderFunction has a backing store. so it is kind of like state management in two places. should arguments in this case be observable?

class F {
  arguments = [1, 2, 3];
  
  saveAndRender(arguments) {
    this.arguments = arguments;
    outsideRenderFunction(this.arguments); 
  }
}

[urugator]

I think you will have to be a bit more specific.
If the goal is to synchronize non-mobx (non-observable) store, with your observable class, you can do it like this, but the non-observable store should either have it's own subscription mechanism (observer/autorun/etc won't work with it) or you can make an observable adapter. See https://mobx.js.org/custom-observables.html#atoms

[rufus2021]

the store wraps and uses mobx. so in this case i use arguments in my app but it's also tracked/stored in this third party library. in this case since i need arguments to cause a render when they change then i have to make them observable. i think maybe what i struggle with is coming up with a general rule for maintaining something as "state" vs just a class variable. is it fair to say "i need something to happen in my app when variable x changes, so track it with mobx"?

[urugator]

Anything that can change over time is a "state" and therefore should be observable. You shouldn't need to know upfront if/what/how/when will need to observe these changes. If you would have to know that, then you could just directly call something like renderApp()/renderSpecificComponent()/someOtherEffect() in your actions (eg in saveAndRender) and you wouldn't need observables.
However you should think about who owns that state. You can't have a state that is owned (and managed) by both - your class and some third party library.
If that state is owned and managed by the library (eg. it holds and mutates that arguments array), then the library should provide some means to "observe" it's own state changes and you probably shouldn't store arguments to your class at all. To connect your component to the library you would use means exposed by the library instead of observer.
Or as I mentioned you could make some sort of adapter/wrapper, that converts the library changes into observable changes. The actual solution would largely depend on the library, it's API and how it's being used in your application.

Maybe your logic goes like this?:
I need to call some lib, that lib mutates it's own internal state as a result of this call. Since the lib's state isn't observable by observer, I will mutate some own observable (this.arguments) everytime I call this library.
This will work only if the lib is completely synchronous (since you assume it's state changes immediately during function call) and anytime you access the library by an observer, you would also have to access that observable (arguments). Basically you synchronize reads/writes of the library with reads/writes of some arbitrary observable, so that observable represents a change of the lib's state.

[rufus2021]

Thank you! I think that makes sense for my scenario. I'm still getting used to mobx so this is very helpful.