reactjs - medium - Redux: ¿Opiniones/ejemplos de cómo hacer la persistencia del backend?

redux react

Question

Me pregunto cómo las personas que usan Redux se están acercando a su persistencia en el back-end. En particular, ¿está almacenando las "acciones" en una base de datos o solo está almacenando el último estado conocido de la aplicación?

Si está almacenando las acciones, ¿las está simplemente solicitando desde el servidor, y luego las reproduce todas cuando se carga una página determinada? ¿No podría esto conducir a algunos problemas de rendimiento con una aplicación a gran escala donde hay muchas acciones?

Si está almacenando solo el "estado actual", ¿cómo está realmente persistiendo este estado en un momento dado a medida que ocurren las acciones en un cliente?

¿Alguien tiene algunos ejemplos de código de cómo están conectando los reductores redux a aplicaciones de almacenamiento de fondo?

Sé que esta es una pregunta tipo "depende de tu aplicación", pero solo estoy reflexionando sobre algunas ideas aquí y tratando de tener una idea de cómo este tipo de arquitectura "sin estado" podría funcionar en un sentido de pila completa.

Gracias a todos.

Answer 1

¡Definitivamente persiste el estado de tus reductores!

Si persiste una secuencia de acciones en su lugar, nunca podrá modificar sus acciones en su frontend sin manipular dentro de su base de datos prod.

Ejemplo: persistir el estado de un reductor en un servidor

Comenzaremos con tres tipos de acciones adicionales:

// actions: ''SAVE'', ''SAVE_SUCCESS'', ''SAVE_ERROR''

Uso redux-thunk para hacer llamadas a servidores asíncronos: significa que una función de creador de acciones puede dispatch acciones adicionales e inspeccionar el estado actual.

El creador de acciones de save distribuye una acción de forma inmediata (para que pueda mostrar una rueda giratoria o desactivar un botón "guardar" en su UI). A continuación, envía SAVE_SUCCESS o una acción SAVE_ERROR una vez que finaliza la solicitud POST.

var actionCreators = {
save: () => {
return (dispatch, getState) => {
var currentState = getState();
var interestingBits = extractInterestingBitsFromState(currentState);
dispatch({type: ''SAVE''});
window.fetch(someUrl, {
method: ''POST'',
body: JSON.stringify(interestingBits)
})
.then(checkStatus) // from https://github.com/github/fetch#handling-http-error-statuses
.then((response) => response.json())
.then((json) => dispatch actionCreators.saveSuccess(json.someResponseValue))
.catch((error) =>
console.error(error)
dispatch actionCreators.saveError(error)
);
}
},
saveSuccess: (someResponseValue) => return {type: ''SAVE_SUCCESS'', someResponseValue},
saveError: (error) => return {type: ''SAVE_ERROR'', error},
// other real actions here
};

(NB $.ajax funcionaría totalmente en lugar de window.fetch , ¡simplemente prefiero no cargar todo el jQuery para una función!)

El reductor simplemente realiza un seguimiento de cualquier solicitud de servidor pendiente.

function reducer(state, action) {
switch (action.type) {
case ''SAVE'':
return Object.assign {}, state, {savePending: true, saveSucceeded: null, saveError: null}
break;
case ''SAVE_SUCCESS'':
return Object.assign {}, state, {savePending: false, saveSucceeded: true, saveError: false}
break;
case ''SAVE_ERROR'':
return Object.assign {}, state, {savePending: false, saveSucceeded: false, saveError: true}
break;
// real actions handled here
}
}

Probablemente quieras hacer algo con el someResponseValue que regresó del servidor; tal vez sea una identificación de una entidad recién creada, etc.

Espero que esto ayude, ¡hasta ahora ha funcionado bien!