How to structure mobx

I am trying to figure out how to structure my application, for example, I have a User model, common user content to track the loading of all users so far and some UI-related stores like FriendList, PendingFriendList, BlockedUserList, LikedUserList, etc. .:

class User { id; @observable name; @observable avatar; // others functions and fields } class UserStore { @observable users = []; function resolve(id) { /*return by id*/} function createOrUpdateUser(json) { /* add user to this.users */ } } class FriendStore { @observable users = []; hasNextPage = true; currentPage = null; function loadNextPage(page) { api.loadFriends(page >= 0 ? page : this.currentPage + 1).then( users => { users.forEach( user => { this.users.push( UserStore.createOrUpdateUser(user) ) }) }) } } class PendingFriendUsers { @observable users = []; @observable query = null; hasNextPage = true; currentPage = null; function loadNextPage(page) { // more or less like FriendStore } } class BlockedUserStore { // more or less like FriendStore } 

My question is: is this the way? Or is there a better way?

+8
javascript reactjs redux mobx
source share
2 answers

As you probably already noticed, MobX does not prescribe how to structure stores, so there are many possible approaches.

But personally, I would set it up like this (this is similar to the proposed store setup in docs ). It may be a little old-fashioned, but easy to follow, it is a scalable model with a clear separation of problems. Alternative approaches can be found in this repo example or in related projects like mobx-reactor

A quick tip: use transaction in the api callback so that all changes are applied immediately before notifying browsers.

+8
source share

I worked on some projects with Mobx and reacted, so I found this structure most suitable for me.

The shops

  • Domain shops
    • stores data that will be needed in your application.
      e.g. user data
  • Browse stores
    • stores data that will be needed to represent your application
      e.g. loading errors

Models

  • Here you can define data models.
    for user model

Services

  • Here you can make services, api calls

Components

  • Container or smart component
  • Mute or presentation component
+8
source share

All Articles