redux-saga kiedy używać widelca?

Question

jaka byłaby różnica między tymi dwoma podejściami poniżej?

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) 
    ] 
} 

Kiedy muszę użyć widelca, a kiedy nie?

Answer 1

Ogólnie rzecz biorąc, fork jest przydatna, gdy saga musi rozpocząć zadanie nieblokujące. Brak blokady oznacza tutaj: wywołujący uruchamia zadanie i kontynuuje wykonywanie bez oczekiwania na zakończenie.

Jest wiele sytuacji, w których może to być przydatne, ale 2 główne z nich to:

• grupowania sagi według domeny logicznej
• utrzymując odniesienie do zadania, aby móc Aby anulować/dołączyć do niego:

Saga najwyższego poziomu może być przykładem pierwszego użycia. Będziesz prawdopodobnie mieć coś takiego:

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

Gdzie authSaga prawdopodobnie będzie obejmować takie rzeczy jak:

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

Widać, że ten przykład jest równoznaczne z tym, co sugeruje, dzwoniąc z fork saga dostarczając takeEvery połączenie. Ale w praktyce wystarczy to zrobić dla celów organizacji kodu. takeEvery samo w sobie jest zadaniem rozwidlonym, więc w większości przypadków byłoby to niepotrzebnie nadmiarowe.

Przykładem drugiego użytkowej przypadku byłoby coś jak:

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

można zobaczyć w tym przykładzie, że monitorUserProfileUpdates wykona natomiast saga rozmówca wznawia, i dostaje czekać na działanie do USER_SIGNED_OUT być wysłane. Może ponadto zachować odniesienie do niego, aby anulować je w razie potrzeby.

Ze względu na kompletność istnieje inny sposób uruchamiania połączeń bez blokowania: spawn. fork i spawn różnią się sposobem, w jaki błędy i anulowania stają się bańkami w sadze od dziecka do rodzica.