Redux: Was ist der richtige Ort zum speichern von cookie nach dem login anfordern?
Ich habe die folgende situation: Der Benutzer gibt seine Zugangsdaten ein und klickt auf einen Login - Taste. Ein API-Aufruf geschieht in der action-Schöpfer über redux-thunk
. Wenn der API-Aufruf erfolgreich war, wird eine andere Aktion ausgelöst wird, enthält die Antwort vom server. Nach der (erfolgreichen) Anmeldung ich möchte zum speichern der Benutzer-session-id in einem cookie (via react-cookie
).
Aktion creator
export function initiateLoginRequest(username, password) {
return function(dispatch) {
dispatch(loginRequestStarting())
return fetch('http://path.to/api/v1/login',
{
method: 'POST',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json'
},
body: JSON.stringify({
username: username,
password: password
})
})
.then(checkStatus)
.then(parseJSON)
.then(function(data) {
dispatch(loginRequestSuccess(data))
})
.catch(function(error) {
dispatch(loginRequestError(error))
})
}
}
export function loginRequestSuccess(user) {
return {
type: ActionTypes.LOGIN_REQUEST_SUCCESS,
user
}
}
Reducer
export default function user(state = initialState, action) {
switch (action.type) {
case ActionTypes.LOGIN_REQUEST_SUCCESS:
cookie.save('sessionId', action.user.sid, { path: '/' })
return merge({}, state, {
sessionId: action.user.sid,
id: action.user.id,
firstName: action.user.first_name,
lastName: action.user.last_name,
isAuthenticated: true
})
default:
return state
}
}
Jetzt die reducer verantwortlich für LOGIN_REQUEST_SUCCESS speichert das cookie. Ich weiß, der reducer hat eine Reine Funktion.
Ist ein cookie gespeichert, der in der reducer-gegen diesen Grundsatz verstoßen? Wäre es besser zum speichern der cookie-innen der Aktion creator?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Haben Sie einen Blick auf redux-persist.
Können Sie anhalten/speichern Sie Ihre Reduzierstücke (oder Teile davon) in
LocalStorage
.Konzept
Beispiel
Installieren
Beispiel Für Die Verwendung
Erstellen Sie eine Komponente, die umschließt die Persistenz - /rehydration der Logik.
AppProvider.js
Dann in Ihrer
index.js
oder Datei, in dem Sie denstore
, wickeln Sie die gerenderte Komponenten in Ihrem neuenAppProvider
.index.js
Diese wird serialisiert
user
reducer Zustand zuLocalStorage
auf jedem update der Shop - /- Zustand. Sie können öffnen Sie Ihre dev-tools (Chrome) und schauResources
=>Local Storage
.localstorage
.Ich bin mir nicht sicher, ob dies der "richtige" Weg, aber das ist, wie mein team ist die Persistenz des angemeldeten Benutzers in der Redux-app, die wir erstellt haben:
Wir haben ein sehr Standard-Architektur, die eine API bereit, um Anfragen auf einer Seite, und ein Reagieren/Redux/Single Page app verbraucht diese API-Endpunkte, auf der anderen Seite.
Wenn die Anmeldeinformationen gültig sind, wird die API-endpoint-verantwortlich für die Anmeldung beantworten Sie die app mit dem user-Objekt, einschließlich einer access-token. Das access token ist letztere bei jeder Anforderung durch die app, um den Benutzer zu überprüfen, die gegen das API.
Wenn die app erhält der Benutzer Informationen aus der API zwei Dinge passieren: 1) eine Aktion ausgelöst und der Benutzer reducer, so etwas wie
ADD_USER
, um diese Benutzer in der Benutzer speichern, und 2) das Zugriffstoken des Benutzers beibehalten wird in derlocalStorage
.Nach dieser, jede Komponente kann die Verbindung zu den Nutzern reducer und verwenden Sie die gespeicherte Zugriffstoken zu wissen, wer der angemeldeten user, und natürlich, wenn Sie haben keine access-token in Ihren
localStorage
es bedeutet, dass der Benutzer nicht eingeloggt ist.In der Spitze unserer Komponenten-Hierarchie, wir haben eine Komponente dafür verantwortlich, die Verbindung zum Benutzer reducer, Holen Sie sich die aktuellen Benutzer auf der Grundlage der access-token beibehalten, in der
localStorage
und übergeben Sie diese aktuellen Benutzers in der Reagieren Sie Kontext. So vermeiden wir jede Komponente, die abhängig vom aktuellen Benutzer zu schließen, um den Benutzer reducer und Lesen aus derlocalStorage
gehen wir davon aus, dass diese Komponenten erhalten immer die aktuellen Benutzer aus dem app-Kontext.Gibt es einige Herausforderungen, wie token-Ablaufdatum, die fügt hinzu, mehr Komplexität der Lösung, aber im Grunde ist dies, wie wir es tun, und es funktioniert ziemlich gut.
localstorage
über Cookie (für das speichern der access-token)?Ich würde wahrscheinlich die server-Seite das cookie, persönlich, und machen Sie es transparent für JavaScript. Aber wenn Sie wirklich wollen, es zu tun auf client-Seite wäre, würde ich es in einen action helper. So etwas wie dieses:
Oder sowas.
Action-Helfer nicht brauchen, um rein zu sein, aber Reduzierstücke werden sollte. Also, wenn ich das mache Nebenwirkungen, ich setzte Sie in die Tat Helfer.