Would I benefit from implementing some kind of dependency injection?

[AdamGerthel]

So, I have a pretty large React Native codebase that's used in production and has been built over a number of years. The codebase follows the "root store" pattern and I have a number of classes and subclasses that make up the project's business logic.

I'm currently trying to make the individual classes re-usable in another project and have realized that I have a lot of internal dependencies that I probably could/should refactor in order to lessen som of this spaghetti:

The pattern I'm currently using is something like:

export default class Stores {
  purchase = new PurchaseStore(this)
  @observable game: GameStore | null = null
  content = new ContentStore()
  ui = new UiStore(this)
  saves = new SavesStore(this)
  achievements = new AchievementsStore(this)
  settings = new SettingsStore(this)
  statistics = new StatisticsStore(this)
  review = new ReviewStore(this)
  notifications = new NotificationsStore(this)
  system = new SystemStore(this)
}

So as you can see, I'm pretty much injecting all stores everywhere. Now, I could of course refactor this a bit so that I only pass the stores that I actually need:

export default class Stores {
  ui = new UiStore()
  review = new ReviewStore(this.ui)
  purchase = new PurchaseStore(this.ui)
  // ...etc

This, it seems to me, is a kind of very simple dependency injection pattern. What I'm trying to figure out is whether or not I would benefit from using a library to handle this, such as InjectionJS, TSyringe, InversifyJS or TypeDI. I guess I don't truly understand dependency injection well enough to be able to know what my needs are. When I look at the docs for the mentioned libraries, it's not obvious to me what benefit they add, but surely, since they exist, they solve some kind of problem in this space?

So - what are your thoughts given my structure? What should I do?

[kubk]

Hi, MobX is all about automatically reacting to observable changes. It doesn’t force any architectural choices, which is why you are free to use any approach - whether it’s using singleton stores directly or using some kind of dependency injection.

When it comes to DI there are 2 approaches:

• Manual DI. No DI container library is used. All the class dependencies are resolved manually. Example:

class RootStore {
  analyticsApi = new AnalyticsApi();
  analyticsStore = new AnalyticsStore(this.analyticsApi);
  userStore = new UserStore(this.analyticsStore);
}

It’s simple because no libraries are required, but it might be tedious to specify all the dependencies.

• DI container library. It helps to avoid tedious work, but it might come with the price of an additional abstraction and extra time needed for debugging in case something doesn’t work. There are libraries for Mobx that already include tsyringe as a DI container: https://github.com/Yoskutik/react-vvm

Over time, I have gradually shifted from manual dependency injection to singletons, primarily because I don't need my stores to be shared among different apps. Writing unit tests without DI is not as simple, but since migrating to vitest, I can easily mock any module. If I ever need my store to be executed in different contexts, I would definitely choose to pass dependencies through a constructor or a callback to minimize coupling:

userFormStore.submit(() => {
  userListStore.reload();
})

I believe there are no golden rules. If the modules are tightly coupled, it can make the system more complex and harder to manage. But in some cases, especially when the modules need to communicate closely, a bit of coupling can actually simplify the design and make code more readable. It's all about finding the right balance and avoid the cargo cult.

[AdamGerthel]

Nice, explanation, thanks!

I've decided to move from my current setup to only injecting the dependencies that are actually used rather than inject everything everywhere always. I'll probably also split up my useStores hook and use more specific hooks such as useGameStore. I'll add a DI library if I noticed that there's something missing or a new problem arises that it can solve for me.

There are libraries for Mobx that already include tsyringe as a DI container

Interesting to see! I'm pretty much using that exactly that pattern without realizing it had a name.

It's all about finding the right balance and avoid the cargo cult.

Agree!

[Joao-vi]

This might be off topic, but you seems to have good experience managemnt complexy of front-end.
I don't know how to tackle a usecase where a User model, for instance is used in differents Views, and each View require a different data shape or a different behaviour.
Supose a User model is used in CreateUserView, EditUserView, ListUsersView, BlockedUsersView, let's say each view has some behaviour and data shape in common, would you include all behaviour on the same UserModel ou create a UserModel for each View ?

[AdamGerthel]

I think it would depend on the size of the UserModel and how different the needs are in the different views. But generally, I would use the same model for all of them. The only downsides would be increased complexity in code (in case the model grows too big) and potentially memory - but that would only be an issue if we're talking huge amounts of data.

I would try to keep View-specific stuff as local state rather than have it managed by the store. So for example, if CreateUserView is a form where users are added, I wouldn't use the UserModel at all until the user has been created. Same goes for EditUserView. The user data would live in a form state until the edits are completed.

You can think of it a bit like a model–view–viewmodel pattern.

[Joao-vi]

Thanks for your reply, it was really helpfull