2016-07-20 21 views
2

Ich verwende Redux, um meinen App-Status zu verwalten, und ich hatte eine asynchrone Aktion mit redux-thunk.Ausführen von Redux-Thunk-Aktion ohne Versand

export const login = credentials => dispatch => { 
    return doLogin(credentials).then(token => { 
     localStorage.setItem('token', token) 
     // this dispatch call was there before, but now it has gone, 
     // because it is not necessary anymore 
     // dispatch({ type: LOGIN_SUCCESS }) 
    }) 
} 

Die Sache ist jetzt, dass ich eine Aktion haben, die keine Aktionen in den Speicher nicht versenden, nur macht seinen Job über Login und Speichern von Token.

Ist es in Ordnung, eine solche Aktion zu haben? Ich bin nicht so überzeugt von diesem Code, aber ich weiß nicht, wie ich es verbessern kann.

+0

Funktioniert diese Funktion überhaupt nicht mit dem Zustand? –

Antwort

1

Sie fragen nach einer Meinung zu etwas, das keine harten Regeln hat, aber die Faustregel ist, dass Aktionen eine minimale Beschreibung von etwas sein sollten, das in der Anwendung passiert ist.

Thunked Aktionen im Allgemeinen sind eine Umgehungsmöglichkeit für dieses Verhalten, aber in diesem Fall ist es in Ordnung, diese Art von Aktion zu haben, weil, obwohl es keine Auswirkungen auf Redux-Status durch einen Reducer hat, verwenden Sie (Thunk Middleware, um Nebenwirkungen zu verursachen, und Middleware wurde entwickelt, um auf Aktionen zu reagieren.

Die Tatsache, dass Sie eine ‚Upstream‘ Aktion sind Triggern, die nicht stromabwärts durch ein Untersetzungsgetriebe verbraucht wird, ist nicht wirklich wichtig, obwohl es eine gute Praxis am Anfang noch am Ende dispatch({ type: 'LOGIN_REQUEST' }) sein könnte gerade und dispatch({ type: 'LOGIN_SUCCESS'}) Die nachgelagerte Anwendung hat also eine Möglichkeit zu wissen, was passiert, wenn sie später etwas dagegen tun will.

1

Es ist Geschmackssache, aber persönlich würde ich deinen Action Creator nicht eng mit seinen Effekten verbinden (Artikel im lokalen Speicher).

Stattdessen würde ich eine Aktion, z. LOGIN_SUCCESS mit Token, die als Daten übergeben wurden. Dann muss eine Middleware diesen Aktionstyp behandeln - d. H. Das Token im lokalen Speicher setzen.

Auf diese Weise erwerben Sie mehr Flexibilität, wenn es darum geht, die von doLogin zurückgegebenen Anmeldeinformationen zu verarbeiten. Sie sollten dieses Paradigma jeder Software verfolgen, die ihr eigenes Ding macht und es am besten macht. Sie haben also eine Funktion, um den Benutzer zu authentifizieren, der dann den Authentifizierungs-Token an ein anderes Teil weitergibt, das am besten damit umgehen kann.

+0

Sie haben wahrscheinlich Recht mit Middleware. Aber localStorage wird nur für dieses Feature verwendet, daher dachte ich, dass es Overhead wäre, nur für diesen Fall eine Middleware hinzuzufügen. –

+0

Ich denke schon, aber immer noch - getrennte Sorgen sind leichter zu begründen. Alles in allem - es ist eine Frage der Wahl. – WTK