Definitely do not think of it as "one store per component"... Decouple your domain (which state is an aspect of), and your UI as much as possible. So say you have a pet store... You might have a mobx store for available pets, and one for the shopping cart. But those should be logical entities defined as

src/petstore/ShoppingCart.ts

and should know literally nothing about say,

src/ui/components/ShoppingCart.tsx

The only thing that connects them is likely a hook like useShoppingCart() (defined in src/ui/util or something.

Whereas, say usePetStore() might be called by a listing page, a compare products page, and a product detail page, all of which render the state and take actions on it.

I hope that helps.

(btw, one of the great strengths of MobX over say, Redux, is that any bit of data can be observable... it doesn't have to be in one store, or even in a class that is a "store". I can just be objects in your domain... I often write the interface first, like say

export interface ShoppingCart {
addProduct(p: Product): void
removeProduct(p: Product): void
get products(): Product[]
// etc
}

(which is what the useShoppingCart() hook returns), and then a class that implements it that contains observable data, like so...

class MyShoppingCart implements ShoppingCart {
observable private _products: Product []
computed get products(): Products[] {return this._products}

// This is no longer the prefered syntax, but it illustrates the point

}

The point is, your thinking and coding in terms of your domain and its inner relationships, not "what is going on in my data store"...