Un magasin d'actions pour des mises à jour optimistes est une bonne approche dans Redux / Flux?

J'ai travaillé avec des mises à jour optimistes dans une application React + Flux et j'ai vu deux choses:

1. Que se passe-t-il si un utilisateur tente de fermer la fenêtre lorsqu'il existe des actions inachevées. Par exemple, dans Facebook, un message apparaît dans le mur, même s'il n'a pas vraiment persisté (c'est ce que font les mises à jour optimistes, une application plus adaptée à l'utilisateur). Mais, si un utilisateur affiche dans le mur et ferme immédiatement l'application (après la fermeture de session ou la fermeture de la fenêtre), le message pourrait échouer et il ne serait pas alerté.
2. Je n'aime pas l'idée que les magasins gèrent leurs propres entités (par exemple, les messages) et la situation de l'action déclenchée pour persiste un message (chargement, réussite, échec?). Il mélange les choses.

Je travaille donc sur ceci et crée un ActionStore pour gérer l'état des actions déclenchées par les composants. Voici le code source et voici une démo en direct.

Cela fonctionne plus ou moins comme ceci:

1. La racine de la hiérarchie des composants (container in redux) récupère le prochainId d'une nouvelle action et la transmet à ses enfants comme des accessoires (c'est laid).
2. Un composant enfant déclenche une action: il conserve l'action pour le demander au magasin après et appelez le créateur d'actions.
3. Le créateur d'action crée une nouvelle Action et renvoie une fonction au middleware.
4. La fonction renvoyée à partir de l'Action crée une nouvelle promesse avec l'appel API et expédie une action du type XX_START.
5. ActionStore écoute l'action XX_START et l'enregistre.
6. Le composant enfant reçoit le nouvel état et trouve l'action avec l'identifiant sauvegardé et lui demande la situation actuelle: chargement, réussite ou échec.

Je l'ai fait principalement pour séparer l'état des «entités» de l'état des actions, mais permet également des actions de redéclenchement avec la même charge utile (cela pourrait être utile lorsque nous recevons un état de réponse 500 si le serveur est temporairement en panne ou si Le signal détaché de l'utilisateur).

• Comment gérer les entités en forme d'arbre dans les réducteurs Redux?
• La dépendance de données Flux / Alt, comment gérer élégamment et idiomaticement
• Pourquoi le magasin redux devrait-il être sérialisable?
• Un bon moyen d'initialiser les données
• Comment gérer les effets secondaires complexes dans Redux?

En outre, avoir un stock d'actions permet de demander facilement s'ils sont en attente d'actions avant que l'utilisateur ne se déconnecte ou ne ferme la fenêtre.

Remarque: Je travaille avec une application Web de la page d'application unique contre une API de repos, je ne pense pas l'utiliser sur le rendu côté serveur

C'est une option viable de créer un ActionStore ou je brise des fondations de Redux / Flux? Cela pourrait mettre fin à la possibilité d'utiliser Réagir de recharge à chaud et de temps de déplacement?

Vous devriez répondre sans pitié, j'ai probablement fait un tas de choses moche, mais j'apprends React / Redux.

• React-native: détecte dev ou production env
• Comment télécharger la réponse d'extraction en réagissant en tant que fichier
• Réactive-routeur: l'exécution n'est pas une fonction
• Flux: waitFor event spécifique
• Comment mettre des méthodes sur les objets dans l'état Redux?

function optimistic(reducer) { return function (state, action) { // do something? return reducer(state, action); } } 

 export default combineReducers({ something: optimistic(something) // wrap "something" reducer }) 

 function optimistic(reducer) { return function (state = { history: [] }, action) { // do something with history? return { history: [...state.history, action], present: reducer(state.history[state.history.length - 1], action) }; } }