Redux Saga pattern per risposte server grandi e non specifici

Il nostro attuale albero di stato di Redux è questo:

{
    "dog": {
        "name": "Barkley",
        "age": 6,
        "hungry": false,
        "location": "Living Room",
        "height": "36 in."
    },
    "cat": {
        "name": "Sir Eatsalot",
        "age": 10,
        "hungry": false,
        "location": "Living Room",
        "height": "18 in."
    }
}

Riceviamo aggiornamenti da un server (tramite Saga) che ci invia tutti i dati rilevanti per l'app, indipendentemente dal fatto che sia stato aggiornato.

Riceviamo questo tipo di risposta ogni secondo in modo che lo stato della nostra app corrisponda allo stato del server. Risposta di esempio:

{
    "pets": {
        "dog": {
            "owner": "Jim", 
            "petName": "Barkley",
            "currentAge": 6,
            "hungry": false,
            "room": "Living Room",
            "height": "3 ft."
        },
        "cat": {
            "owner": "Jim",
            "petName": "Sir Eatsalot",
            "currentAge": 10,
            "hungry": true,
            "location": "Kitchen",
            "height": "1.5 ft."
        }
    }
}

Abbiamo bisogno di prendere il nuovo status e aggiornare il nostro negozio.

Note:

• Il server non è nostro, quindi dobbiamo gestire le risposte in questo formato
• Non facciamo richieste al server, ci invia solo POST con l'aggiornamento di stato del tipo "ecco cosa sta succedendo nella mia applicazione"
• Il formato di risposta del server non è lo stesso del nostro formato di negozio, memorizziamo solo i dati di cui abbiamo bisogno e nel formato che ci serve; cioè mutazioni

Quale implementazione di Redux è meglio gestire gli aggiornamenti:

Opzione 1

Fai in modo che la Saga confronti la risposta corrente con la risposta precedente e le azioni di dispatch (a volte multiple) in base alle modifiche.

In questo caso verificheremmo che cat.hungry e cat.location sono stati modificati, quindi avremmo inviato due azioni.

Pubblicazioni

• Saga è responsabile del monitoraggio dello stato di risposta per confrontare lo stato precedente con quello corrente
• Il sovraccarico del confronto tra lo stato precedente e lo stato corrente sarà elevato, l'oggetto status nel nostro progetto è molto più grande di questo esempio e si verifica 6 volte al secondo; Non sono sicuro che il sovraccarico qui sia valido perché costringe comunque l'elaborazione ridondante sui riduttori.
• Solo perché il nuovo stato da inviare ha alcuni dati che non sono aggiornati non significa che non dovremmo garantire che i dati siano come il server ci dice che dovrebbe essere - la saga non sa nulla dello stato e dovrebbe assumere che potrebbe essere diverso dall'ultimo aggiornamento di stato.

Opzione 2

Chiedi alla Saga di inviare una sola UPDATE_PET_STATUS di azione con l'intera risposta e lasciare che il singolo catReducer e dogReducer gestiscano lo stato completo in action.status , estraendo i relativi dati rilevanti e aggiornando lo stato in base alle esigenze.

Pubblicazioni

• Il dogReducer riceve informazioni destinate ad altri stati (stato gatto)
• Il dogReducer elabora l'azione e controlla (o aggiorna) il proprio stato sul carico utile dell'azione senza apportare modifiche - elaborazione ridondante.
• Ogni riduttore che gestisce questo deve setacciare i dati completi di risposta grezza

Opzione 3

Avere un petStatusReducer che riceve l'azione UPDATE_PET_STATUS singola, separa e muta il carico utile dell'azione e lo passa ai riduttori figli, dogReducer e catReducer .

Pubblicazioni

• Penso che ciò vada contro le regole sulla progettazione dei riduttori ; non muta argomenti, non eseguire effetti collaterali. In questo caso, attiviamo diverse azioni trasferendo un'azione diversa, o almeno diversi dati di azione, al riduttore figlio.

Pensieri?

Aggiornamenti: Aggiornamento dei dati normalizzati parla in qualche modo della gestione dei dati simile a questo ...