Dans l'architecture Flux, comment gérez-vous le cycle de vie du Store?

Je lis sur Flux mais le exemple d'application Todo est trop simpliste pour que je puisse comprendre certains points clés.

Imaginez une application d'une seule page comme Facebook avec des pages de profil utilisateur . Sur chaque page de profil utilisateur, nous voulons afficher certaines informations utilisateur et leurs derniers messages, avec un défilement infini. Nous pouvons naviguer d'un profil utilisateur à un autre.

Dans l'architecture Flux, comment cela correspondrait-il aux Stores et Dispatchers?

En utiliserions-nous un PostStorepar utilisateur ou aurions-nous une sorte de magasin mondial? Qu'en est-il des répartiteurs, créerions-nous un nouveau répartiteur pour chaque «page utilisateur» ou utiliserions-nous un singleton? Enfin, quelle partie de l'architecture est responsable de la gestion du cycle de vie des magasins «spécifiques à la page» en réponse au changement d'itinéraire?

De plus, une même pseudo-page peut avoir plusieurs listes de données du même type. Par exemple, sur une page de profil, je souhaite afficher à la fois les abonnés et les suivis . Comment un singleton peut-il UserStorefonctionner dans ce cas? Serait UserPageStoregérer followedBy: UserStoreet follows: UserStore?

Dans une application Flux, il ne devrait y avoir qu'un seul Dispatcher. Toutes les données transitent par ce hub central. Avoir un répartiteur singleton lui permet de gérer tous les magasins. Cela devient important lorsque vous avez besoin de la mise à jour du magasin n ° 1 proprement dit, puis que le magasin n ° 2 se met à jour lui-même en fonction de l'action et de l'état du magasin n ° 1. Flux suppose que cette situation est une éventualité dans une grande application. Idéalement, cette situation n'aurait pas besoin de se produire et les développeurs devraient s'efforcer d'éviter cette complexité, si possible. Mais le répartiteur singleton est prêt à le gérer le moment venu.

Les magasins sont également des singletons. Ils doivent rester aussi indépendants et découplés que possible - un univers autonome que l'on peut interroger à partir d'une Controller-View. La seule route vers le magasin passe par le rappel qu'il enregistre auprès du répartiteur. La seule issue est les fonctions getter. Les magasins publient également un événement lorsque leur état a changé, de sorte que Controller-Views puisse savoir quand demander le nouvel état, à l'aide des getters.

Dans votre exemple d'application, il y en aurait un seul PostStore. Ce même magasin pourrait gérer les messages sur une "page" (pseudo-page) qui ressemble plus au fil d'actualité de FB, où les messages apparaissent de différents utilisateurs. Son domaine logique est la liste des messages et il peut gérer n'importe quelle liste de messages. Lorsque nous passons d'une pseudo-page à une pseudo-page, nous souhaitons réinitialiser l'état du magasin pour refléter le nouvel état. Nous pourrions également vouloir mettre en cache l'état précédent dans localStorage pour optimiser les allers-retours entre les pseudo-pages, mais mon inclination serait de configurer un PageStorequi attend tous les autres magasins, gère la relation avec localStorage pour tous les magasins sur la pseudo-page, puis met à jour son propre état. Notez que ceciPageStore ne stockera rien sur les messages - c'est le domaine duPostStore. Il saurait simplement si une pseudo-page particulière a été mise en cache ou non, car les pseudo-pages sont son domaine.

Le PostStoreaurait une initialize()méthode. Cette méthode effacerait toujours l'ancien état, même s'il s'agit de la première initialisation, puis créerait l'état en fonction des données reçues via l'action, via le Dispatcher. Passer d'une pseudo-page à une autre impliquerait probablement une PAGE_UPDATEaction, qui déclencherait l'invocation de initialize(). Il y a des détails à résoudre autour de la récupération des données du cache local, de la récupération des données du serveur, du rendu optimiste et des états d'erreur XHR, mais c'est l'idée générale.

Si une pseudo-page particulière n'a pas besoin de tous les Stores de l'application, je ne suis pas tout à fait sûr qu'il y ait une raison de détruire les non utilisées, autre que des contraintes de mémoire. Mais les magasins ne consomment généralement pas beaucoup de mémoire. Vous devez simplement vous assurer de supprimer les écouteurs d'événements dans les vues de contrôleur que vous êtes en train de détruire. Ceci est fait dans la componentWillUnmount()méthode de React .

(Remarque: j'ai utilisé la syntaxe ES6 en utilisant l'option JSX Harmony.)

En guise d'exercice, j'ai écrit un exemple d'application Flux qui permet de parcourir Github userset de déposer.
Il est basé sur la réponse de fisherwebdev mais reflète également une approche que j'utilise pour normaliser les réponses API.

Je l'ai fait pour documenter quelques approches que j'ai essayées en apprenant Flux.
J'ai essayé de le garder proche du monde réel (pagination, pas de fausses API localesStorage).

Il y a quelques éléments qui m'intéressaient particulièrement:

• Il utilise l' architecture Flux et le react-router ;
• Il peut afficher la page utilisateur avec des informations partielles connues et charger les détails lors de vos déplacements;
• Il prend en charge la pagination à la fois pour les utilisateurs et les dépôts;
• Il analyse les réponses JSON imbriquées de Github avec normalizr ;
• Les Content Stores n'ont pas besoin de contenir un géant switchavec des actions ;
• «Back» est immédiat (car toutes les données sont dans les Stores).

Comment je classe les magasins

J'ai essayé d'éviter une partie de la duplication que j'ai vue dans d'autres exemples de Flux, en particulier dans les magasins. J'ai trouvé utile de diviser logiquement les magasins en trois catégories:

Les magasins de contenu contiennent toutes les entités d'application. Tout ce qui a un identifiant a besoin de son propre Content Store. Les composants qui rendent des éléments individuels demandent aux Content Stores les nouvelles données.

Les magasins de contenu récupèrent leurs objets de toutes les actions du serveur. Par exemple, UserStore regardeaction.response.entities.users s'il existe quelle que soit l'action déclenchée. Il n'y a pas besoin d'un switch. Normalizr facilite l'aplatissement des réponses d'API à ce format.

// Content Stores keep their data like this
{
  7: {
    id: 7,
    name: 'Dan'
  },
  ...
}

Les magasins de listes gardent une trace des identifiants des entités qui apparaissent dans une liste globale (par exemple «flux», «vos notifications»). Dans ce projet, je n'ai pas de tels magasins, mais je pensais les mentionner quand même. Ils gèrent la pagination.

Ils répondent normalement à quelques actions (par exemple REQUEST_FEED, REQUEST_FEED_SUCCESS, REQUEST_FEED_ERROR).

// Paginated Stores keep their data like this
[7, 10, 5, ...]

Les magasins de listes indexées sont comme les magasins de listes, mais ils définissent une relation un-à-plusieurs. Par exemple, «abonnés de l'utilisateur», «astronomes du référentiel», «référentiels de l'utilisateur». Ils gèrent également la pagination.

Ils répondent aussi normalement que quelques actions (par exemple REQUEST_USER_REPOS, REQUEST_USER_REPOS_SUCCESS, REQUEST_USER_REPOS_ERROR).

Dans la plupart des applications sociales, vous en aurez beaucoup et vous voulez pouvoir en créer rapidement une de plus.

// Indexed Paginated Stores keep their data like this
{
  2: [7, 10, 5, ...],
  6: [7, 1, 2, ...],
  ...
}

Remarque: ce ne sont pas des classes réelles ou quelque chose du genre; c'est comme ça que j'aime penser aux magasins. J'ai cependant fait quelques aides.

StoreUtils

createStore

Cette méthode vous donne le magasin le plus basique:

createStore(spec) {
  var store = merge(EventEmitter.prototype, merge(spec, {
    emitChange() {
      this.emit(CHANGE_EVENT);
    },

    addChangeListener(callback) {
      this.on(CHANGE_EVENT, callback);
    },

    removeChangeListener(callback) {
      this.removeListener(CHANGE_EVENT, callback);
    }
  }));

  _.each(store, function (val, key) {
    if (_.isFunction(val)) {
      store[key] = store[key].bind(store);
    }
  });

  store.setMaxListeners(0);
  return store;
}

Je l'utilise pour créer tous les magasins.

isInBag, mergeIntoBag

Petits assistants utiles pour les magasins de contenu.

isInBag(bag, id, fields) {
  var item = bag[id];
  if (!bag[id]) {
    return false;
  }

  if (fields) {
    return fields.every(field => item.hasOwnProperty(field));
  } else {
    return true;
  }
},

mergeIntoBag(bag, entities, transform) {
  if (!transform) {
    transform = (x) => x;
  }

  for (var key in entities) {
    if (!entities.hasOwnProperty(key)) {
      continue;
    }

    if (!bag.hasOwnProperty(key)) {
      bag[key] = transform(entities[key]);
    } else if (!shallowEqual(bag[key], entities[key])) {
      bag[key] = transform(merge(bag[key], entities[key]));
    }
  }
}

PaginatedList

Stocke l'état de pagination et applique certaines assertions (impossible de récupérer la page lors de la récupération, etc.).

class PaginatedList {
  constructor(ids) {
    this._ids = ids || [];
    this._pageCount = 0;
    this._nextPageUrl = null;
    this._isExpectingPage = false;
  }

  getIds() {
    return this._ids;
  }

  getPageCount() {
    return this._pageCount;
  }

  isExpectingPage() {
    return this._isExpectingPage;
  }

  getNextPageUrl() {
    return this._nextPageUrl;
  }

  isLastPage() {
    return this.getNextPageUrl() === null && this.getPageCount() > 0;
  }

  prepend(id) {
    this._ids = _.union([id], this._ids);
  }

  remove(id) {
    this._ids = _.without(this._ids, id);
  }

  expectPage() {
    invariant(!this._isExpectingPage, 'Cannot call expectPage twice without prior cancelPage or receivePage call.');
    this._isExpectingPage = true;
  }

  cancelPage() {
    invariant(this._isExpectingPage, 'Cannot call cancelPage without prior expectPage call.');
    this._isExpectingPage = false;
  }

  receivePage(newIds, nextPageUrl) {
    invariant(this._isExpectingPage, 'Cannot call receivePage without prior expectPage call.');

    if (newIds.length) {
      this._ids = _.union(this._ids, newIds);
    }

    this._isExpectingPage = false;
    this._nextPageUrl = nextPageUrl || null;
    this._pageCount++;
  }
}

PaginatedStoreUtils

createListStore, createIndexedListStore,createListActionHandler

Rend la création de magasins de listes indexées aussi simple que possible en fournissant des méthodes standard et la gestion des actions:

var PROXIED_PAGINATED_LIST_METHODS = [
  'getIds', 'getPageCount', 'getNextPageUrl',
  'isExpectingPage', 'isLastPage'
];

function createListStoreSpec({ getList, callListMethod }) {
  var spec = {
    getList: getList
  };

  PROXIED_PAGINATED_LIST_METHODS.forEach(method => {
    spec[method] = function (...args) {
      return callListMethod(method, args);
    };
  });

  return spec;
}

/**
 * Creates a simple paginated store that represents a global list (e.g. feed).
 */
function createListStore(spec) {
  var list = new PaginatedList();

  function getList() {
    return list;
  }

  function callListMethod(method, args) {
    return list[method].call(list, args);
  }

  return createStore(
    merge(spec, createListStoreSpec({
      getList: getList,
      callListMethod: callListMethod
    }))
  );
}

/**
 * Creates an indexed paginated store that represents a one-many relationship
 * (e.g. user's posts). Expects foreign key ID to be passed as first parameter
 * to store methods.
 */
function createIndexedListStore(spec) {
  var lists = {};

  function getList(id) {
    if (!lists[id]) {
      lists[id] = new PaginatedList();
    }

    return lists[id];
  }

  function callListMethod(method, args) {
    var id = args.shift();
    if (typeof id ===  'undefined') {
      throw new Error('Indexed pagination store methods expect ID as first parameter.');
    }

    var list = getList(id);
    return list[method].call(list, args);
  }

  return createStore(
    merge(spec, createListStoreSpec({
      getList: getList,
      callListMethod: callListMethod
    }))
  );
}

/**
 * Creates a handler that responds to list store pagination actions.
 */
function createListActionHandler(actions) {
  var {
    request: requestAction,
    error: errorAction,
    success: successAction,
    preload: preloadAction
  } = actions;

  invariant(requestAction, 'Pass a valid request action.');
  invariant(errorAction, 'Pass a valid error action.');
  invariant(successAction, 'Pass a valid success action.');

  return function (action, list, emitChange) {
    switch (action.type) {
    case requestAction:
      list.expectPage();
      emitChange();
      break;

    case errorAction:
      list.cancelPage();
      emitChange();
      break;

    case successAction:
      list.receivePage(
        action.response.result,
        action.response.nextPageUrl
      );
      emitChange();
      break;
    }
  };
}

var PaginatedStoreUtils = {
  createListStore: createListStore,
  createIndexedListStore: createIndexedListStore,
  createListActionHandler: createListActionHandler
};

createStoreMixin

Un mixin qui permet aux composants de se connecter aux magasins qui les intéressent, par exemple mixins: [createStoreMixin(UserStore)].

function createStoreMixin(...stores) {
  var StoreMixin = {
    getInitialState() {
      return this.getStateFromStores(this.props);
    },

    componentDidMount() {
      stores.forEach(store =>
        store.addChangeListener(this.handleStoresChanged)
      );

      this.setState(this.getStateFromStores(this.props));
    },

    componentWillUnmount() {
      stores.forEach(store =>
        store.removeChangeListener(this.handleStoresChanged)
      );
    },

    handleStoresChanged() {
      if (this.isMounted()) {
        this.setState(this.getStateFromStores(this.props));
      }
    }
  };

  return StoreMixin;
}

Ainsi, dans Reflux, le concept de Dispatcher est supprimé et vous n'avez qu'à penser en termes de flux de données à travers les actions et les magasins. C'est à dire

Actions <-- Store { <-- Another Store } <-- Components

Chaque flèche ici modélise la façon dont le flux de données est écouté, ce qui signifie à son tour que les données circulent dans la direction opposée. Le chiffre réel du flux de données est le suivant:

Actions --> Stores --> Components
   ^          |            |
   +----------+------------+

Dans votre cas d'utilisation, si j'ai bien compris, nous avons besoin d'une openUserProfileaction qui initie le chargement et le changement de page du profil utilisateur, ainsi que des actions de chargement de publications qui chargeront les publications lorsque la page de profil utilisateur est ouverte et pendant l'événement de défilement infini. J'imagine donc que nous avons les magasins de données suivants dans l'application:

• Un magasin de données de page qui gère le changement de page
• Un magasin de données de profil utilisateur qui charge le profil utilisateur lorsque la page est ouverte
• Un magasin de données de liste de publications qui charge et gère les publications visibles

Dans Reflux, vous le configurez comme ceci:

Les actions

// Set up the two actions we need for this use case.
var Actions = Reflux.createActions(['openUserProfile', 'loadUserProfile', 'loadInitialPosts', 'loadMorePosts']);

Le magasin de pages

var currentPageStore = Reflux.createStore({
    init: function() {
        this.listenTo(openUserProfile, this.openUserProfileCallback);
    },
    // We are assuming that the action is invoked with a profileid
    openUserProfileCallback: function(userProfileId) {
        // Trigger to the page handling component to open the user profile
        this.trigger('user profile');

        // Invoke the following action with the loaded the user profile
        Actions.loadUserProfile(userProfileId);
    }
});

Le magasin de profils utilisateur

var currentUserProfileStore = Reflux.createStore({
    init: function() {
        this.listenTo(Actions.loadUserProfile, this.switchToUser);
    },
    switchToUser: function(userProfileId) {
        // Do some ajaxy stuff then with the loaded user profile
        // trigger the stores internal change event with it
        this.trigger(userProfile);
    }
});

Le magasin d'articles

var currentPostsStore = Reflux.createStore({
    init: function() {
        // for initial posts loading by listening to when the 
        // user profile store changes
        this.listenTo(currentUserProfileStore, this.loadInitialPostsFor);
        // for infinite posts loading
        this.listenTo(Actions.loadMorePosts, this.loadMorePosts);
    },
    loadInitialPostsFor: function(userProfile) {
        this.currentUserProfile = userProfile;

        // Do some ajax stuff here to fetch the initial posts then send
        // them through the change event
        this.trigger(postData, 'initial');
    },
    loadMorePosts: function() {
        // Do some ajaxy stuff to fetch more posts then send them through
        // the change event
        this.trigger(postData, 'more');
    }
});

Les composants

Je suppose que vous avez un composant pour la vue de la page entière, la page de profil utilisateur et la liste des publications. Les éléments suivants doivent être câblés:

• Les boutons qui ouvrent le profil utilisateur doivent appeler le Action.openUserProfileavec l'ID correct pendant son événement de clic.
• Le composant de page doit écouter le currentPageStoreafin de savoir à quelle page basculer.
• Le composant de page de profil utilisateur doit écouter le currentUserProfileStoreafin de savoir quelles données de profil utilisateur afficher
• La liste des messages doit écouter le currentPostsStorepour recevoir les messages chargés
• L'événement de défilement infini doit appeler le Action.loadMorePosts.

Et cela devrait être à peu près tout.