Come mostrare un indicatore di caricamento nell'app React Redux durante il recupero dei dati? [chiuso]

Sono nuovo in React / Redux. Uso un middleware api di recupero nell'app Redux per elaborare le API. È ( redux-api-middleware ). Penso che sia il modo migliore per elaborare azioni API asincrone. Ma trovo alcuni casi che non possono essere risolti da solo.

Come dice la homepage ( Lifecycle ), un ciclo di vita dell'API di recupero inizia con l'invio di un'azione CALL_API e termina con l'invio di un'azione FSA.

Quindi il mio primo caso è mostrare / nascondere un preloader durante il recupero delle API. Il middleware invierà un'azione FSA all'inizio e alla fine invierà un'azione FSA. Entrambe le azioni vengono ricevute da riduttori che dovrebbero eseguire solo una normale elaborazione dei dati. Nessuna operazione dell'interfaccia utente, non più operazioni. Forse dovrei salvare lo stato di elaborazione nello stato, quindi renderli durante l'aggiornamento del negozio.

Ma come farlo? Un flusso di componenti di reazione su tutta la pagina? cosa succede con l'aggiornamento del negozio da altre azioni? Voglio dire, sono più simili a eventi che a stati!

Anche in un caso peggiore, cosa devo fare quando devo utilizzare la finestra di dialogo di conferma nativa o la finestra di dialogo di avviso nelle app redux / react? Dove vanno messi, azioni o riduzioni?

Auguri! Desiderio di rispondere.

Voglio dire, sono più simili a eventi che a stati!

Non lo direi. Penso che gli indicatori di caricamento siano un ottimo caso di UI che può essere facilmente descritto come una funzione di stato: in questo caso, di una variabile booleana. Sebbene questa risposta sia corretta, vorrei fornire del codice per seguirla.

Nel asyncesempio nel Redux pronti contro termine , riduttore aggiorna un campo chiamatoisFetching :

case REQUEST_POSTS:
  return Object.assign({}, state, {
    isFetching: true,
    didInvalidate: false
  })
case RECEIVE_POSTS:
  return Object.assign({}, state, {
    isFetching: false,
    didInvalidate: false,
    items: action.posts,
    lastUpdated: action.receivedAt

Il componente utilizza connect()da React Redux per iscriversi allo stato del negozio e restituisce isFetchingcome parte del mapStateToProps()valore restituito in modo che sia disponibile negli oggetti di scena del componente connesso:

function mapStateToProps(state) {
  const { selectedReddit, postsByReddit } = state
  const {
    isFetching,
    lastUpdated,
    items: posts
  } = postsByReddit[selectedReddit] || {
    isFetching: true,
    items: []
  }

  return {
    selectedReddit,
    posts,
    isFetching,
    lastUpdated
  }
}

Infine, il componente utilizza isFetchingprop nella render()funzione per eseguire il rendering di un'etichetta "Caricamento in corso ..." (che potrebbe essere piuttosto uno spinner):

{isEmpty
  ? (isFetching ? <h2>Loading...</h2> : <h2>Empty.</h2>)
  : <div style={{ opacity: isFetching ? 0.5 : 1 }}>
      <Posts posts={posts} />
    </div>
}

Anche in un caso peggiore, cosa devo fare quando devo utilizzare la finestra di dialogo di conferma nativa o la finestra di dialogo di avviso nelle app redux / react? Dove vanno messi, azioni o riduzioni?

Eventuali effetti collaterali (e mostrare una finestra di dialogo è sicuramente un effetto collaterale) non appartengono ai riduttori. Pensa ai riduttori come passivi "costruttori di stato". Non "fanno" davvero le cose.

Se desideri mostrare un avviso, fallo da un componente prima di inviare un'azione o fallo da un creatore di azioni. Nel momento in cui un'azione viene eseguita, è troppo tardi per eseguire gli effetti collaterali in risposta ad essa.

Per ogni regola c'è un'eccezione. A volte la logica degli effetti collaterali è così complicata che in realtà vuoi accoppiarli a tipi di azione specifici oa riduttori specifici. In questo caso controlla progetti avanzati come Redux Saga e Redux Loop . Fallo solo quando sei a tuo agio con Vanilla Redux e hai un vero problema di effetti collaterali sparsi che vorresti rendere più gestibili.

Ottima risposta Dan Abramov! Voglio solo aggiungere che stavo facendo più o meno esattamente quello in una delle mie app (mantenendo isFetching come booleano) e ho finito per renderlo un numero intero (che finisce per leggere come il numero di richieste in sospeso) per supportare più richieste simultanee richieste.

con booleano:

richiesta 1 avvia -> spinner acceso -> richiesta 2 avvia -> richiesta 1 termina -> spinner spento -> richiesta 2 termina

con numero intero:

richiesta 1 inizia -> spinner acceso -> richiesta 2 inizia -> richiesta 1 termina -> richiesta 2 termina -> spinner spento

case REQUEST_POSTS:
  return Object.assign({}, state, {
    isFetching: state.isFetching + 1,
    didInvalidate: false
  })
case RECEIVE_POSTS:
  return Object.assign({}, state, {
    isFetching: state.isFetching - 1,
    didInvalidate: false,
    items: action.posts,
    lastUpdated: action.receivedAt

Vorrei aggiungere qualcosa. L'esempio del mondo reale utilizza un campo isFetchingnel negozio per rappresentare quando viene recuperata una raccolta di elementi. Qualsiasi raccolta è generalizzata a un filepagination riduttore che può essere collegato ai componenti per tenere traccia dello stato e mostrare se una raccolta è in fase di caricamento.

Mi è capitato di voler recuperare i dettagli per un'entità specifica che non si adatta allo schema di impaginazione. Volevo avere uno stato che rappresentasse se i dettagli vengono recuperati dal server, ma non volevo anche avere un riduttore solo per quello.

Per risolvere questo problema ho aggiunto un altro riduttore generico chiamato fetching. Funziona in modo simile al riduttore di paginazione ed è responsabilità solo osservare un insieme di azioni e generare un nuovo stato con le coppie [entity, isFetching]. Ciò consente al connectriduttore di qualsiasi componente e di sapere se l'app sta attualmente recuperando i dati non solo per una raccolta ma per un'entità specifica.

Questa domanda non mi è mai capitata fino ad ora, ma poiché nessuna risposta è accettata, mi metterò il cappello. Ho scritto uno strumento proprio per questo lavoro: react-loader-factory . Ha un po 'più di successo rispetto alla soluzione di Abramov, ma è più modulare e conveniente, dal momento che non volevo dover pensare dopo averlo scritto.

Ci sono quattro pezzi grandi:

• Modello di fabbrica: questo ti permette di chiamare rapidamente la stessa funzione per impostare quali stati significano "Caricamento" per il tuo componente e quali azioni inviare. (Ciò presuppone che il componente sia responsabile dell'avvio delle azioni su cui attende.)const loaderWrapper = loaderFactory(actionsList, monitoredStates);
• Wrapper: Il componente che Factory produce è un "componente di ordine superiore" (come quello che connect()ritorna in Redux), in modo che tu possa semplicemente fissarlo alle tue cose esistenti.const LoadingChild = loaderWrapper(ChildComponent);
• Interazione azione / riduttore: il wrapper verifica se un riduttore a cui è collegato contiene parole chiave che gli dicono di non passare al componente che necessita di dati. Le azioni inviate dal wrapper dovrebbero produrre le parole chiave associate (il modo in cui redux-api-middleware invia ACTION_SUCCESSe ACTION_REQUEST, ad esempio). (Puoi inviare azioni altrove e monitorare semplicemente dal wrapper se lo desideri, ovviamente.)
• Throbber: il componente che desideri venga visualizzato mentre i dati da cui dipende il tuo componente non sono pronti. Ho aggiunto un piccolo div in modo che tu possa provarlo senza doverlo montare.

Il modulo stesso è indipendente da redux-api-middleware, ma è quello con cui lo uso, quindi ecco un po 'di codice di esempio dal README:

Un componente con un caricatore che lo avvolge:

import React from 'react';
import { myAsyncAction } from '../actions';
import loaderFactory from 'react-loader-factory';
import ChildComponent from './ChildComponent';

const actionsList = [myAsyncAction()];
const monitoredStates = ['ASYNC_REQUEST'];
const loaderWrapper = loaderFactory(actionsList, monitoredStates);

const LoadingChild = loaderWrapper(ChildComponent);

const containingComponent = props => {
  // Do whatever you need to do with your usual containing component 

  const childProps = { someProps: 'props' };

  return <LoadingChild { ...childProps } />;
}

Un riduttore per il monitoraggio del caricatore (anche se puoi cablarlo in modo diverso se lo desideri):

export function activeRequests(state = [], action) {
  const newState = state.slice();

  // regex that tests for an API action string ending with _REQUEST 
  const reqReg = new RegExp(/^[A-Z]+\_REQUEST$/g);
  // regex that tests for a API action string ending with _SUCCESS 
  const sucReg = new RegExp(/^[A-Z]+\_SUCCESS$/g);

  // if a _REQUEST comes in, add it to the activeRequests list 
  if (reqReg.test(action.type)) {
    newState.push(action.type);
  }

  // if a _SUCCESS comes in, delete its corresponding _REQUEST 
  if (sucReg.test(action.type)) {
    const reqType = action.type.split('_')[0].concat('_REQUEST');
    const deleteInd = state.indexOf(reqType);

    if (deleteInd !== -1) {
      newState.splice(deleteInd, 1);
    }
  }

  return newState;
}

Mi aspetto che nel prossimo futuro aggiungerò cose come timeout ed errore al modulo, ma il modello non sarà molto diverso.

La risposta breve alla tua domanda è:

1. Collega il rendering al codice di rendering: usa un wrapper attorno al componente di cui hai bisogno per il rendering con i dati come quello che ho mostrato sopra.
2. Aggiungi un riduttore che renda facilmente digeribile lo stato delle richieste relative all'app che ti interessano, in modo da non dover pensare troppo a ciò che sta accadendo.
3. Gli eventi e lo stato non sono molto diversi.
4. Il resto delle tue intuizioni mi sembrano corrette.

Sono l'unico a pensare che gli indicatori di caricamento non appartengano a un negozio Redux? Voglio dire, non penso che faccia parte dello stato di un'applicazione di per sé ..

Ora, lavoro con Angular2, e quello che faccio è avere un servizio di "caricamento" che espone diversi indicatori di caricamento tramite RxJS BehaviourSubjects .. Suppongo che il meccanismo sia lo stesso, semplicemente non memorizzo le informazioni in Redux.

Gli utenti del LoadingService devono semplicemente iscriversi a quegli eventi che vogliono ascoltare.

I miei creatori di azioni Redux chiamano il LoadingService ogni volta che le cose devono cambiare. I componenti UX si iscrivono alle osservabili esposte ...

Puoi aggiungere listener di modifiche ai tuoi negozi, utilizzando connect()React Redux o il store.subscribe()metodo di basso livello . Dovresti avere l'indicatore di caricamento nel tuo negozio, che il gestore delle modifiche del negozio può quindi controllare e aggiornare lo stato del componente. Il componente quindi esegue il rendering del preloader, se necessario, in base allo stato.

alerte confirmnon dovrebbe essere un problema. Si stanno bloccando e l'avviso non riceve nemmeno alcun input dall'utente. Con confirm, è possibile impostare lo stato in base a ciò su cui l'utente ha fatto clic se la scelta dell'utente deve influire sul rendering dei componenti. In caso contrario, è possibile memorizzare la scelta come variabile membro componente per un uso successivo.

Abbiamo tre tipi di notifiche nella nostra app, tutte progettate come aspetti:

1. Indicatore di carico (modale o non modale in base al puntello)
2. Popup di errore (modale)
3. Notifica snackbar (non modale, a chiusura automatica)

Tutti e tre si trovano al livello più alto della nostra app (Principale) e cablati tramite Redux come mostrato nello snippet di codice sottostante. Questi oggetti di scena controllano la visualizzazione dei loro aspetti corrispondenti.

Ho progettato un proxy che gestisce tutte le nostre chiamate API, quindi tutti gli errori isFetching e (api) sono mediati con actionCreators che importano nel proxy. (Per inciso, uso anche webpack per iniettare una simulazione del servizio di supporto per dev in modo da poter lavorare senza dipendenze dal server.)

Qualsiasi altro punto nell'app che deve fornire qualsiasi tipo di notifica importa semplicemente l'azione appropriata. Snackbar & Error hanno parametri per la visualizzazione dei messaggi.

@connect(
// map state to props
state => ({
    isFetching      :state.main.get('isFetching'),   // ProgressIndicator
    notification    :state.main.get('notification'), // Snackbar
    error           :state.main.get('error')         // ErrorPopup
}),
// mapDispatchToProps
(dispatch) => { return {
    actions: bindActionCreators(actionCreators, dispatch)
}}

) export default class Main estende React.Component {

Sto salvando gli URL come:

isFetching: {
    /api/posts/1: true,
    api/posts/3: false,
    api/search?q=322: true,
}

E poi ho un selettore memorizzato (tramite reselect).

const getIsFetching = createSelector(
    state => state.isFetching,
    items => items => Object.keys(items).filter(item => items[item] === true).length > 0 ? true : false
);

Per rendere l'url univoco in caso di POST, passo alcune variabili come query.

E dove voglio mostrare un indicatore, uso semplicemente la variabile getFetchCount