Dove dovrebbero "vivere" i processi a lungo termine in un'applicazione react + redux?Dove vivono i processi di lunga durata in un'applicazione React + Redux?
Per un semplice esempio, si consideri una classe che invia e riceve messaggi su una websocket:
class WebsocketStreamer {
sendMessage(message) {
this.socket.send(…);
}
onMessageReceive(event) {
this.dispatch({
type: "STREAMER_RECV",
message: event.data,
})
}
}
Come deve il ciclo di vita di questa classe da gestire?
Il mio primo istinto è quello di mantenere sul store:
var stores = {
streamer: function(state={}, action) {
if (action.type == "@@INIT")
return { streamer: new WebsocketStreamer() }
if (action.type == "STREAMER_SEND")
state.streamer.sendMessage(action.message)
return state;
}
}
Ma, oltre ad essere un po 'strano, c'è anche alcun modo per il WebsocketStreamer per ottenere l'accesso alla funzione dispatch(), e si rompe caldo ricaricare.
Un'altra possibile soluzione è quella di tenerlo in un qualche luogo globale:
const streamer = new WebsocketStreamer();
Ma che ha ovvie implicazioni testabilità, e rompe caldo ricaricare troppo.
Quindi, dove dovrebbe trascorrere un lungo processo in esecuzione in un'applicazione react + redux?
Nota: mi rendo conto che questo semplice esempio potrebbe essere creato con solo negozi + provider di azioni. Ma mi piacerebbe in particolare sapere dove i processi a lungo termine dovrebbero esistere nelle situazioni in cui esistono.
Chris, ho scoperto che l'archiviazione del client Pusher nel negozio di redux causa molti problemi con il ricaricamento a caldo. Hai vissuto/superato questo? –
Non posso parlarne, Steven. Non ho usato nulla di simile a questa passata fase di prova del concetto. –