Way of Creating multiple stores with mobx and injecting it into to a Component ? Way of Communication between the stores?

As suggested here in the Mobx documentation I have created multiple stores in the following manner:

class bankAccountStore {
  constructor(rootStore){
	this.rootStore = rootStore;
  }
...

class authStore {
  constructor(rootStore){
	this.rootStore = rootStore;
  }
...

And finally creating a root store in the following manner. As stated here I went on to construct an instance of “children” stores within “master” store constructor. Moreover, I found that sometimes my child store has to observe some data from parent store, so I pass this(of a parent) into child constructors

class RootStore {
  constructor() {
    this.bankAccountStore = new bankAccountStore(this);
    this.authStore = new authStore(this);
  }
}

Providing to the App in following manner:

<Provider rootStore={new RootStore()}>
  <App />
</Provider>

And injecting to the component in like this:

@inject('rootStore') 
@observer
class User extends React.Component{
  constructor(props) {
    super(props);
    //Accessing the individual store with the help of root store
    this.authStore = this.props.rootStore.authStore;
  }
}

Is it the correct and efficient way to inject the root store every time to the component even if it needs a part of the root store? If not how to inject auth Store or only required number of stores to the user component? How to share data between stores which can change in future?

I am sorry to ask it here as I didn’t get much response here on stack overflow. I would like to know better approach as it may have an opinionated answer

MOBX Version - 5.9.0 MOBX-REACT Version - 5.4.3

[urugator]

as @fi3ework suggests

export class AuthStore {    
    constructor(rootStore) {
      this.rootStore = rootStore        
    }
    
    @computed get dependentVariable() {
      return this.rootStore.userStore.changeableUserVariable;                                      
    }
}

scalable web apps in long run

• keep state simple and minimal (use computed/render for anything that can be derived from another value)
• keep state in form of tree (not graph)
• keep the tree as flat as possible (normalize)
• keep tree shape fixed (normalize)
• share IDs instead of object references (normalize)
• prefer coupling over indirection
• prefer transparent and easy to understand state over reusable encapsulated state
• prefer function composition over object composition
• avoid artificial abstractions (is there actual benefit of having storeX,storeY?)
• avoid reaction/autorun

[msreekm]

@urugator good points, let me also add one drawback with storing rootStore in each store is that when you have to deal with Json.serializer, store serializing will fail with circular reference error. This is critical in SSR .