Come strutturare mobx

Question

Sto cercando di capire come strutturare la mia app, ad esempio, ho un utente modello, un generico UserStore per tenere traccia di tutti gli utenti caricati finora e alcuni negozi relativi all'interfaccia utente come FriendList, PendingFriendList, BlockedUserList, LikedUserList, ecc così:

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 
} 

la mia domanda è: che la strada da percorrere? O c'è un modo migliore ??

Answer 1

Come probabilmente già notato, MobX non prescrive come strutturare i negozi, quindi ci sono molti approcci possibili.

Ma personalmente avrei impostato in questo modo all'incirca in questo modo (è simile alla configurazione del negozio proposta nel docs). Forse è un po 'vecchio stile, ma è facile da seguire imho, è un modello scalabile con chiara separazione delle preoccupazioni. Approcci alternativi si possono trovare in questo example repo o in progetti correlati come mobx-reactor

Un piccolo suggerimento: nella vostra callback api utilizzare transaction in modo che tutte le modifiche vengono applicate in una sola volta prima di eventuali osservatori sono notificati.

Answer 2

Ho lavorato su alcuni progetti con Mobx &, quindi ho trovato questa struttura più adatta a me.

Negozi

• Negozi di dominio
  • memorizza i dati which'll essere necessari nella vostra app.
    per es. dati utente
• Visualizzare negozi
  • negozi which'll essere necessari i dati per presentare la vostra applicazione
    ad es. di carico, variabili di errore

modelle

• Qui si possono definire i modelli di dati
  per il modello utente ex-

Servizi

• Qui è possibile fare servizi, chiamate api

Componenti

• container o Smart Component
• componente Dumb o di presentazione