Używając Redux-saga

Jak powiedział Dan Abramov, jeśli chcesz bardziej zaawansowanej kontroli nad kodem asynchronicznym, możesz spojrzeć naredux-saga .

Ta odpowiedź jest prostym przykładem, jeśli chcesz lepiej wyjaśnić, dlaczego redux-saga może być przydatny dla Twojej aplikacji, Sprawdź ta druga odpowiedź .

Ogólna idea jest taka, że Redux-saga oferuje interpreter generatorów ES6, który pozwala na łatwe pisanie kodu asynchronicznego, który wygląda jak synchroniczny kod (dlatego w Redux-saga często znajdziesz pętle infinite while). W jakiś sposób Redux-saga buduje swój własny język bezpośrednio wewnątrz Javascript. Redux-saga może wydawać się trochę trudne do nauczenia się na początku, ponieważ potrzebujesz podstawowego zrozumienia generatorów, ale także zrozumieć język oferowany przez Redux-saga.

Postaram się tutaj opisać system powiadomień, który zbudowałem na bazie redux-saga. Ten przykład jest obecnie produkowany.

Zaawansowany system powiadomień Specyfikacja

• możesz poprosić o wyświetlenie powiadomienia
• możesz poprosić o powiadomienie, aby ukryć
• powiadomienie nie powinno być wyświetlane dłużej niż 4 sekundy
• wiele powiadomień może być wyświetlanych w tym samym czasie
• nie więcej niż 3 powiadomienia mogą być wyświetlane w tym samym czasie
• Jeśli wymagane jest powiadomienie, gdy są już 3 wyświetlane powiadomienia, Kolejka / przesuń to.

Wynik

Zrzut ekranu mojej aplikacji produkcyjnej Stample.co

Kod

Tutaj nazwałem powiadomienie toast ale to jest Szczegóły nazewnictwa.

function* toastSaga() {

    // Some config constants
    const MaxToasts = 3;
    const ToastDisplayTime = 4000;


    // Local generator state: you can put this state in Redux store
    // if it's really important to you, in my case it's not really
    let pendingToasts = []; // A queue of toasts waiting to be displayed
    let activeToasts = []; // Toasts currently displayed


    // Trigger the display of a toast for 4 seconds
    function* displayToast(toast) {
        if ( activeToasts.length >= MaxToasts ) {
            throw new Error("can't display more than " + MaxToasts + " at the same time");
        }
        activeToasts = [...activeToasts,toast]; // Add to active toasts
        yield put(events.toastDisplayed(toast)); // Display the toast (put means dispatch)
        yield call(delay,ToastDisplayTime); // Wait 4 seconds
        yield put(events.toastHidden(toast)); // Hide the toast
        activeToasts = _.without(activeToasts,toast); // Remove from active toasts
    }

    // Everytime we receive a toast display request, we put that request in the queue
    function* toastRequestsWatcher() {
        while ( true ) {
            // Take means the saga will block until TOAST_DISPLAY_REQUESTED action is dispatched
            const event = yield take(Names.TOAST_DISPLAY_REQUESTED);
            const newToast = event.data.toastData;
            pendingToasts = [...pendingToasts,newToast];
        }
    }


    // We try to read the queued toasts periodically and display a toast if it's a good time to do so...
    function* toastScheduler() {
        while ( true ) {
            const canDisplayToast = activeToasts.length < MaxToasts && pendingToasts.length > 0;
            if ( canDisplayToast ) {
                // We display the first pending toast of the queue
                const [firstToast,...remainingToasts] = pendingToasts;
                pendingToasts = remainingToasts;
                // Fork means we are creating a subprocess that will handle the display of a single toast
                yield fork(displayToast,firstToast);
                // Add little delay so that 2 concurrent toast requests aren't display at the same time
                yield call(delay,300);
            }
            else {
                yield call(delay,50);
            }
        }
    }

    // This toast saga is a composition of 2 smaller "sub-sagas" (we could also have used fork/spawn effects here, the difference is quite subtile: it depends if you want toastSaga to block)
    yield [
        call(toastRequestsWatcher),
        call(toastScheduler)
    ]
}

I reduktor:

const reducer = (state = [],event) => {
    switch (event.name) {
        case Names.TOAST_DISPLAYED:
            return [...state,event.data.toastData];
        case Names.TOAST_HIDDEN:
            return _.without(state,event.data.toastData);
        default:
            return state;
    }
};

Użycie

Możesz po prostu wysłać TOAST_DISPLAY_REQUESTED zdarzenia. Jeśli wyślesz 4 żądania, wyświetlone zostaną tylko 3 powiadomienia, a czwarty pojawi się nieco później, gdy zniknie pierwsze powiadomienie.

Zauważ, że Nie polecam wysyłania TOAST_DISPLAY_REQUESTED z JSX. Wolisz dodać kolejną sagę, która nasłuchuje już istniejących zdarzeń aplikacji, a następnie wysłać TOAST_DISPLAY_REQUESTED: twój komponent, który uruchamia powiadomienie, nie musi być ściśle powiązany z systemem powiadomień.

Podsumowanie

Mój kod nie jest idealny, ale działa w produkcji z 0 błędami przez miesiące. Redux - Saga i generatory są początkowo trochę trudne, ale gdy je zrozumiesz, ten rodzaj systemu jest dość łatwy do budowy.

• gdy zbyt wiele powiadomień jest "w kolejce", daj mniej czasu wyświetlania dla każdego powiadomienia, aby rozmiar kolejki mógł się szybciej zmniejszać.
• wykrywa zmiany rozmiaru okna i odpowiednio zmienia maksymalną liczbę wyświetlanych powiadomień (na przykład pulpit=3, portret telefonu = 2, krajobraz telefonu = 1)

Honnestly, powodzenia w realizacji tego typu rzeczy prawidłowo z thunks.

Uwaga możesz zrobić dokładnie to samo z redux-observable , który jest bardzo podobny do redux-saga. To prawie to samo i to kwestia gustu między generatorami a RxJS.

Polecam również przyjrzeć się wzorcowi SAM .

Wzorzec SAM zaleca włączenie "Next-action-predicate", w którym (automatyczne) akcje, takie jak "powiadomienia znikają automatycznie po 5 sekundach"są wyzwalane po zaktualizowaniu modelu (model sam ~ stan reduktora + sklep).

Wzorzec opowiada się za sekwencjonowaniem akcji i mutacją modelu pojedynczo, ponieważ "stan sterowania" modelu "kontroluje", które akcje są włączone i / lub automatycznie wykonywane przez predykat następnej akcji. Po prostu nie można przewidzieć (ogólnie), jaki stan będzie system przed przetworzeniem akcji, a tym samym, czy następna oczekiwana akcja będzie dozwolona / możliwa.

Więc na przykład kod,

export function showNotificationWithTimeout(dispatch, text) {
  const id = nextNotificationId++
  dispatch(showNotification(id, text))

  setTimeout(() => {
    dispatch(hideNotification(id))
  }, 5000)
}

Nie byłoby dozwolone z SAM, ponieważ fakt, że może być wywołana akcja hideNotification jest zależny od modelu pomyślnie przyjmującego wartość "showNotication: true". Mogą być inne części model, który uniemożliwia jej akceptację i w związku z tym nie byłoby powodu do uruchomienia akcji hidenotify.

Gorąco polecam wdrożenie odpowiedniego predykatu następnej akcji po aktualizacji sklepu i poznaniu nowego stanu kontroli modelu. To najbezpieczniejszy sposób na wdrożenie zachowania, którego szukasz.

Możesz to zrobić za pomocą redux-thunk . W dokumencie redux znajduje się instrukcja dla akcji asynchronicznych, takich jak setTimeout.

Repozytorium z przykładowymi projektami

Obecnie istnieją cztery przykładowe projekty:

1. Zapis Kodu Asynchronicznego Inline
2. Extracting Async Action Creator
3. Użyj Redux Thunk
4. Użyj Redux Saga

Przyjęta odpowiedź jest niesamowita.

Ale czegoś brakuje:

1. żadnych przykładowych projektów, tylko fragmenty kodu.
2. brak przykładowego kodu dla innych alternatywy, takie jak:
   1. Redux Saga

Więc utworzyłem Hello Async repozytorium, aby dodać brakujące rzeczy:

1. prowadzenie projektów. Można je pobierać i uruchamiać bez modyfikacji.
2. podaj przykładowy kod, aby uzyskać więcej alternatyw:
   • Redux Saga
   • Redux Loop
   • ...

Redux Saga

Zaakceptowana odpowiedź zawiera już przykładowy kod urywki dla kodu Async Inline, Async Action Generator i Redux Thunk. Dla kompletności podaję fragmenty kodu do Redux Saga:

// actions.js

export const showNotification = (id, text) => {
  return { type: 'SHOW_NOTIFICATION', id, text }
}

export const hideNotification = (id) => {
  return { type: 'HIDE_NOTIFICATION', id }
}

export const showNotificationWithTimeout = (text) => {
  return { type: 'SHOW_NOTIFICATION_WITH_TIMEOUT', text }
}

Działania są proste i czyste.

// component.js

import { connect } from 'react-redux'

// ...

this.props.showNotificationWithTimeout('You just logged in.')

// ...

export default connect(
  mapStateToProps,
  { showNotificationWithTimeout }
)(MyComponent)

Nic nie jest wyjątkowe z komponentem.

// sagas.js

import { takeEvery, delay } from 'redux-saga'
import { put } from 'redux-saga/effects'
import { showNotification, hideNotification } from './actions'

// Worker saga
let nextNotificationId = 0
function* showNotificationWithTimeout (action) {
  const id = nextNotificationId++
  yield put(showNotification(id, action.text))
  yield delay(5000)
  yield put(hideNotification(id))
}

// Watcher saga, will invoke worker saga above upon action 'SHOW_NOTIFICATION_WITH_TIMEOUT'
function* notificationSaga () {
  yield takeEvery('SHOW_NOTIFICATION_WITH_TIMEOUT', showNotificationWithTimeout)
}

export default notificationSaga

Sagaform bazuje na generatorach ES6

// index.js

import createSagaMiddleware from 'redux-saga'
import saga from './sagas'

const sagaMiddleware = createSagaMiddleware()

const store = createStore(
  reducer,
  applyMiddleware(sagaMiddleware)
)

sagaMiddleware.run(saga)

W porównaniu do Redux Thunk

Plusy

Nie skończysz w piekle oddzwaniania.
• możesz łatwo przetestować swoje asynchroniczne przepływy.
• Twój działania pozostają czyste.

Cons

• zależy od generatorów ES6, które są stosunkowo nowe.

Proszę zapoznać się z runnable project jeśli powyższy fragment kodu nie odpowiada na wszystkie Twoje pytania.

Po wypróbowaniu różnych popularnych podejść (twórcy akcji, thunksy, sagi, epiki, efekty, custom middleware), nadal czułem, że może jest miejsce na poprawę, więc udokumentowałem moją podróż w tym artykule na blogu, Gdzie umieścić moją logikę biznesową w aplikacji React/Redux?

Podobnie jak w dyskusjach tutaj, starałem się kontrastować i porównywać różne podejścia. Ostatecznie doprowadziło mnie to do wprowadzenia nowej biblioteki redux-logic , która czerpie inspirację z epiki, sagi, custom middleware.

Umożliwia przechwytywanie działań w celu walidacji, weryfikacji, autoryzacji, a także zapewnia sposób wykonywania asynchronicznych IO.

Niektóre popularne funkcje można po prostu zadeklarować, jak debouncing, Dławienie, anulowanie, i tylko za pomocą odpowiedzi z ostatniego żądania (takeLatest). redux-logic owija kod dostarczając tę funkcjonalność dla Ciebie.

To uwalnia cię do wdrożenia podstawowej logiki biznesowej, jak chcesz. Nie musisz. używaj obserwabli lub generatorów, chyba że chcesz. Użyj funkcji i wywołań zwrotnych, obietnic, funkcji asynchronicznych (async / wait), itp.

Kod do robienia prostego powiadomienia 5s to coś w stylu:

const notificationHide = createLogic({
  // the action type that will trigger this logic
  type: 'NOTIFICATION_DISPLAY',
  
  // your business logic can be applied in several
  // execution hooks: validate, transform, process
  // We are defining our code in the process hook below
  // so it runs after the action hit reducers, hide 5s later
  process({ getState, action }, dispatch) {
    setTimeout(() => {
      dispatch({ type: 'NOTIFICATION_CLEAR' });
    }, 5000);
  }
});
    

Mam bardziej zaawansowany przykład powiadomień w moim repo, który działa podobnie do tego, co opisał Sebastian Lorber, gdzie można ograniczyć wyświetlanie do n elementów i obracać dowolne, które ustawiono w kolejce. redux-przykład powiadomienia logicznego

I posiada wiele przykładów redux-logic jsfiddle na żywo, jak również pełne przykłady . Kontynuuję pracę nad dokumentami i przykładami.

Rozumiem, że to pytanie jest trochę stare, ale zamierzam wprowadzić inne rozwiązanie używając redux-observable aka. Epickie.

Cytując oficjalną dokumentację:

Co to jest redux-obserwowalny?

Rxjs 5-oparte oprogramowanie pośredniczące dla Redux. Komponuj i anuluj akcje asynchroniczne do tworzenie efektów ubocznych i nie tylko.

Jest to funkcja, która przyjmuje strumień akcji i zwraca strumień działań. Działania w, działania na zewnątrz.

W mniej więcej słowach można utworzyć funkcję, która odbiera akcje za pośrednictwem strumienia, a następnie zwrócić nowy strumień akcji (używając typowych efektów ubocznych, takich jak ograniczenia czasowe, opóźnienia, interwały i żądania).

Pozwól mi opublikować kod, a następnie wyjaśnić trochę więcej na ten temat

Sklep.js

import {createStore, applyMiddleware} from 'redux'
import {createEpicMiddleware} from 'redux-observable'
import {Observable} from 'rxjs'
const NEW_NOTIFICATION = 'NEW_NOTIFICATION'
const QUIT_NOTIFICATION = 'QUIT_NOTIFICATION'
const NOTIFICATION_TIMEOUT = 2000

const initialState = ''
const rootReducer = (state = initialState, action) => {
  const {type, message} = action
  console.log(type)
  switch(type) {
    case NEW_NOTIFICATION:
      return message
    break
    case QUIT_NOTIFICATION:
      return initialState
    break
  }

  return state
}

const rootEpic = (action$) => {
  const incoming = action$.ofType(NEW_NOTIFICATION)
  const outgoing = incoming.switchMap((action) => {
    return Observable.of(quitNotification())
      .delay(NOTIFICATION_TIMEOUT)
      //.takeUntil(action$.ofType(NEW_NOTIFICATION))
  });

  return outgoing;
}

export function newNotification(message) {
  return ({type: NEW_NOTIFICATION, message})
}
export function quitNotification(message) {
  return ({type: QUIT_NOTIFICATION, message});
}

export const configureStore = () => createStore(
  rootReducer,
  applyMiddleware(createEpicMiddleware(rootEpic))
)

Indeks.js

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import {configureStore} from './store.js'
import {Provider} from 'react-redux'

const store = configureStore()

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

App.js

import React, { Component } from 'react';
import {connect} from 'react-redux'
import {newNotification} from './store.js'

class App extends Component {

  render() {
    return (
      <div className="App">
        {this.props.notificationExistance ? (<p>{this.props.notificationMessage}</p>) : ''}
        <button onClick={this.props.onNotificationRequest}>Click!</button>
      </div>
    );
  }
}

const mapStateToProps = (state) => {
  return {
    notificationExistance : state.length > 0,
    notificationMessage : state
  }
}

const mapDispatchToProps = (dispatch) => {
  return {
    onNotificationRequest: () => dispatch(newNotification(new Date().toDateString()))
  }
}

export default connect(mapStateToProps, mapDispatchToProps)(App)

Kluczowy kod do rozwiązania tego problemu jest tak prosty, jak widać, jedyną rzeczą, która wydaje się inna od innych odpowiedzi, jest funkcja rootEpic.

Punkt 1. Podobnie jak w przypadku sagi, musisz połączyć epiki, aby uzyskać funkcję najwyższego poziomu, która odbiera strumień akcji i zwraca strumień akcji, więc możesz jej używać z fabryką middleware createEpicMiddleware {36]}. W naszym przypadku potrzebujemy tylko jednego, więc mamy tylko nasz rootEpic , więc nie musimy niczego łączyć, ale dobrze jest wiedzieć fakt.

Punkt 2. Nasze rootEpic który dba o skutki uboczne logika zajmuje tylko około 5 linijek kodu, co jest niesamowite! W tym fakt, że jest dość deklaratywny!

Punkt 3. Linia po linii Wyjaśnienie rootEpic (w komentarzach)

const rootEpic = (action$) => {
  // sets the incoming constant as a stream 
  // of actions with  type NEW_NOTIFICATION
  const incoming = action$.ofType(NEW_NOTIFICATION)
  // Merges the "incoming" stream with the stream resulting for each call
  // This functionality is similar to flatMap (or Promise.all in some way)
  // It creates a new stream with the values of incoming and 
  // the resulting values of the stream generated by the function passed
  // but it stops the merge when incoming gets a new value SO!,
  // in result: no quitNotification action is set in the resulting stream
  // in case there is a new alert
  const outgoing = incoming.switchMap((action) => {
    // creates of observable with the value passed 
    // (a stream with only one node)
    return Observable.of(quitNotification())
      // it waits before sending the nodes 
      // from the Observable.of(...) statement
      .delay(NOTIFICATION_TIMEOUT)
  });
  // we return the resulting stream
  return outgoing;
}

Jeśli chcesz obsłużyć timeout przy selektywnych akcjach, możesz wypróbować podejściemiddleware . Miałem podobny problem z selektywną obsługą działań opartych na obietnicach, a to rozwiązanie było bardziej elastyczne.

Powiedzmy, że Twój twórca akcji wygląda tak:

//action creator
buildAction = (actionData) => ({
    ...actionData,
    timeout: 500
})

Timeout może zawierać wiele wartości w powyższej akcji

• liczba w ms - dla określonego czasu trwania
• true-dla stałego limitu czasu. (obsługiwane w middleware)
• undefined-do natychmiastowej wysyłki

Twoja implementacja middleware wyglądałaby tak:

//timeoutMiddleware.js
const timeoutMiddleware = store => next => action => {

  //If your action doesn't have any timeout attribute, fallback to the default handler
  if(!action.timeout) {
    return next (action)
  }

  const defaultTimeoutDuration = 1000;
  const timeoutDuration = Number.isInteger(action.timeout) ? action.timeout || defaultTimeoutDuration;

//timeout here is called based on the duration defined in the action.
  setTimeout(() => {
    next (action)
  }, timeoutDuration)
}

Możesz teraz przekierować wszystkie swoje działania przez tę warstwę oprogramowania pośredniego za pomocą redux.

createStore(reducer, applyMiddleware(timeoutMiddleware))

Możesz znaleźć kilka podobnych przykładów tutaj

Dlaczego to ma być takie trudne? To tylko logika interfejsu użytkownika. Użyj dedykowanej akcji, aby ustawić dane powiadomień:

dispatch({ notificationData: { message: 'message', expire: +new Date() + 5*1000 } })

I dedykowany komponent do wyświetlania go:

const Notifications = ({ notificationData }) => {
    if(notificationData.expire > this.state.currentTime) {
      return <div>{notificationData.message}</div>
    } else return null;
}

W tym przypadku pytania powinny być "jak oczyścić stary stan?", "jak powiadomić komponent, że czas się zmienił"

Możesz zaimplementować pewną akcję TIMEOUT, która jest wysyłana na setTimeout z komponentu.

Może wystarczy go wyczyścić, gdy nowe powiadomienie jest pokazane.

W każdym razie, gdzieś powinny być jakieś setTimeout, prawda? Dlaczego nie zrobić tego w komponencie

setTimeout(() => this.setState({ currentTime: +new Date()}), 
           this.props.notificationData.expire-(+new Date()) )

Motywacją jest to, że funkcja "powiadomienia zanikają" jest naprawdę problemem interfejsu użytkownika. Upraszcza to więc testowanie logiki biznesowej.

Nie ma sensu testować, jak to jest zaimplementowane. Sensowne jest tylko sprawdzenie, kiedy powiadomienie powinno się zakończyć. W ten sposób mniej kodu do stub, szybsze testy, czystszy kod.

Odpowiednim sposobem jest użycie Redux Thunk , który jest w tym samym czasie Redux stał się częścią Redux Thunk documentation.]}

"Redux Thunk middleware pozwala pisać twórców akcji, które zwraca funkcję zamiast akcji. Thunk może być użyty do opóźnienia wysłania czynności, lub do wysłania tylko wtedy, gdy określony warunek jest spełnione. Wewnętrzna funkcja odbiera metody przechowywania i getState jako parametry".

Więc zasadniczo zwraca funkcję i można opóźnić wysyłkę lub umieścić ją w stanie warunkowym.

Więc coś takiego zrobi za ciebie robotę:

import ReduxThunk from 'redux-thunk';

const INCREMENT_COUNTER = 'INCREMENT_COUNTER';

function increment() {
  return {
    type: INCREMENT_COUNTER
  };
}

function incrementAsync() {
  return dispatch => {
    setTimeout(() => {
      // Yay! Can invoke sync or async actions with `dispatch`
      dispatch(increment());
    }, 5000);
  };
}

Sam Redux jest dość gadatliwą biblioteką, A do takich rzeczy trzeba by użyć czegoś w rodzaju Redux-thunk , który da funkcję dispatch, dzięki czemu będziesz mógł wysłać zamknięcie powiadomienia po kilku sekundach.

Stworzyłem bibliotekę , aby rozwiązać problemy takie jak zwięzłość i kompozytowość, a twój przykład będzie wyglądał następująco:

import { createTile, createSyncTile } from 'redux-tiles';
import { sleep } from 'delounce';

const notifications = createSyncTile({
  type: ['ui', 'notifications'],
  fn: ({ params }) => params.data,
  // to have only one tile for all notifications
  nesting: ({ type }) => [type],
});

const notificationsManager = createTile({
  type: ['ui', 'notificationManager'],
  fn: ({ params, dispatch, actions }) => {
    dispatch(actions.ui.notifications({ type: params.type, data: params.data }));
    await sleep(params.timeout || 5000);
    dispatch(actions.ui.notifications({ type: params.type, data: null }));
    return { closed: true };
  },
  nesting: ({ type }) => [type],
});

Więc komponujemy akcje synchronizacji do wyświetlania powiadomień wewnątrz akcji asynchronicznej, która może poproś o informacje w tle lub sprawdź później, czy powiadomienie zostało zamknięte ręcznie.

To proste. użyj pakietu trim-redux i napisz w ten sposób w componentDidMout lub innym miejscu i zabij go w componentWillUnmount.

componentDidMount(){
   this.tm =  setTimeout(function(){ 
                      setStore({ age: 20 });
              }, 3000);
}

componentWillUnmount(){
   clearTimeout(this.tm);
}

Gdy wykonujesz setTimeout, upewnij się, że również wyczyścisz timeout używając clearTimeout, gdy twój komponent un montuje się w metodzie cyklu życia componentWillUnMount

store.dispatch({ type: 'SHOW_NOTIFICATION', text: 'You logged in.' })
this.timeout = setTimeout(() => {
  store.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)

componentWillUnMount(){
   clearTimeout(this.timeout);
}