2016-01-15 27 views
7

Sto cercando di riflettere su cosa considererebbero le migliori pratiche su come le persone organizzano le chiamate di rete nelle loro app di risposta + ridotte. Di solito permetto ai miei componenti di effettuare chiamate, ottenere dati e poi passarli a un'azione che verrà ridotta. È questa la migliore pratica o è meglio separare la rete dai miei componenti e posizionare quella logica da qualche altra parte nell'app, magari nei riduttori?Dove mettere le chiamate di rete in un'applicazione react + redux

risposta

4

Il posto migliore per effettuare chiamate di rete è nei creatori di azioni. Tuttavia, avrai bisogno di qualche middleware per farlo funzionare al meglio. Date un'occhiata a questo promise-middleware (in effetti, suggerirei di dare un'occhiata all'intero tutorial). Se si utilizza quel middleware, è possibile avere creatori di azioni che restituiscono una promessa e hanno anche tre tipi di azione: uno per la richiesta, uno per gestire le risposte riuscite e l'altro per gestire le richieste non riuscite. Quindi devi solo ascoltare quelle 3 azioni nei tuoi riduttori.

Quindi, con questo middleware, si potrebbe avere un creatore di un'azione del genere:

function networkCall() { 
    return { 
     types: ['MAKE_REQUEST', 'REQUEST_SUCCESS', 'REQUEST_FAILURE'], 
     promise:() => { 
      return new Promise((resolve, reject) => { 
       $.ajax({ 
        url: 'example.com/api' 
        type: 'GET' 
       }); 
      }) 
     } 
    } 
} 

Ovviamente si è liberi di costruire il proprio middleware promessa, ma che dovrebbe impostare nella giusta direzione.

1

Quasi seguo lo schema delle azioni nello redux tutorials for Async Actions. Ha più senso per me mantenere tutto asincrono nelle azioni, lontano sia dai componenti che dagli store/riduttori.

Io uso anche Redux Crud per standardizzare le azioni relative alle azioni di rete.

1

È possibile utilizzare un middleware API, o redux-api-middleware o qualcosa di proprio (non è molto difficile per write one).

Quindi, per esempio, i creatori di azione potrebbe tornare azioni come

{type: 'API_GET', url: '/api/userList', nextType: 'USER_LIST'} 

... che sarebbe poi gestito da un middleware che avrebbe inviato la richiesta effettiva e quindi inviare una nuova azione come:

{type: 'USER_LIST_FETCHED', status: 200, payload: [{id: 1, ...}, ...]} 
{type: 'USER_LIST_FAILED', status: 404, payload: {message: '...'}} 
2

Penso che questa sia una cosa che è stata fatta proprio in Angular. Hai tutte le tue chiamate di rete ordinatamente inserite nel tuo services. Questo può essere fatto facilmente in Redux.

I documenti suggeriscono giustamente che le chiamate di rete sono nel tuo actions. Li classificherei in un posto separato, puoi chiamarlo "servizi". Qui definiresti tutte le tue costanti come l'URL del tuo server API, i contenuti relativi all'autenticazione, ecc. Questo sarebbe l'unico posto a conoscenza dei dettagli di implementazione delle tue chiamate di rete - quale libreria usi (jQuery, axios, superagent, eccetera).

I file delle azioni importerebbero la funzione da tali servizi e li chiamerebbero. Se in seguito decidessi di sostituire la tua libreria di rete, non dovresti cambiare il tuo actions.

Problemi correlati