reactjs - example - redux saga vs redux thunk

redux-saga cuando usar tenedor?

Question

¿Cuál sería la diferencia entre los dos enfoques a continuación?

export function* watchLoginUser() {
  yield takeEvery(USER_LOGIN, loginUser)
}
export function* watchLogoutUser() {
  yield takeEvery(USER_LOGOUT, logoutUser)
}
export function* watchGetParties() {
  yield takeEvery(PARTIES_GET, getParties)
}
export default function* root() {
  yield [
    fork(watchLoginUser),
    fork(watchLogoutUser),
    fork(watchGetParties)
  ]
}

export default function* root() {
  yield [
    takeEvery(USER_LOGIN, loginUser),
    takeEvery(USER_LOGOUT, logoutUser),
    takeEvery(PARTIES_GET, getParties)
  ]
}

¿Cuándo necesito usar un tenedor y cuándo no?

Answer 1

En general, fork es útil cuando una saga necesita comenzar una tarea sin bloqueo. No bloqueo significa que la persona que llama inicia la tarea y continúa ejecutándose sin esperar a que se complete.

Hay una variedad de situaciones donde esto puede ser útil, pero las 2 principales son:

• agrupando sagas por dominio lógico
• manteniendo una referencia a una tarea para poder cancelarla / unirla

Tu saga de nivel superior puede ser un ejemplo del primer caso de uso. Es probable que tengas algo así como:

yield fork(authSaga);
yield fork(myDomainSpecificSaga);
// you could use here something like yield [];
// but it wouldn''t make any difference here

Donde authSaga probablemente incluirá cosas como:

yield takeEvery(USER_REQUESTED_LOGIN, authenticateUser);
yield takeEvery(USER_REQUESTED_LOGOUT, logoutUser);

Puede ver que este ejemplo es equivalente a lo que sugirió, llamando con fork a saga produciendo una llamada a takeEvery . Pero en la práctica, solo necesita hacer esto para fines de organización del código. takeEvery es en sí mismo una tarea bifurcada, por lo que en la mayoría de los casos, esto sería inútilmente redundante.

Un ejemplo del segundo caso de uso sería algo así como:

yield take(USER_WAS_AUTHENTICATED);
const task = yield fork(monitorUserProfileUpdates);
yield take(USER_SIGNED_OUT);
yield cancel(task);

En este ejemplo, puede ver que el monitorUserProfileUpdates se ejecutará mientras se reanuda la saga de la persona que llama, y ​​puede esperar a que se USER_SIGNED_OUT acción USER_SIGNED_OUT . Además, puede mantener una referencia para cancelarla cuando sea necesario.

En aras de la exhaustividad, hay otra manera de iniciar llamadas sin bloqueo: spawn . fork y el spawn difieren en cómo los errores y las cancelaciones burbujean de la saga de niño a padre.