OrderedMap o List for Redux structure?

Question

OrderedMap o List for Redux structure?

#1 da (0 voti)

1

Sto implementando un negozio Redux per un'applicazione React usando redux-saga per le chiamate API. Ho usato prima Immutable.js per altre app React con Redux, ma la natura dei progetti precedenti richiedeva sempre una struttura normalizzata.

In questa nuova app, il flusso è meno simile a un'app e più una serie di passaggi. C'è una chiamata API per acquisire una matrice di oggetti (un po 'sparsi), che dovrebbero essere circa 400-600 in totale. E poi c'è una chiamata API per oggetto per selezionare un'analisi da un set di dati molto grande derivato da ML. Non esiste un'API "bulk process" disponibile a breve termine per il set di dati ML (appena promesso in futuro - le loro risorse ingegneristiche sono ancora focalizzate sulla correttezza / validità nel loro set di dati).

Mi chiedo se mantenere gli oggetti sparsi iniziali come OrderedMap o List. Essenzialmente ho bisogno di scorrere gli oggetti in sequenza, aggiornando ognuno con i dati acquisiti dal set di dati ML tramite una specifica chiamata API. Con tutti gli oggetti aggiornati, viene quindi consegnato in una sola volta tramite un download utente.

Mi aspetto che redux-saga guidi le chiamate API e sputi solo le azioni per mantenere aggiornata una barra di progresso sull'interfaccia utente.

Questo fa sorgere la domanda: utilizzeresti mai un elenco ImmutableJS come struttura generale per Redux?

immutability javascript reactjs redux

posta timbo 24.07.2018 - 09:47

fonte

1 risposta

Leggi altre domande sui tag immutability javascript reactjs redux

Come posso gestire le modifiche tra un file di configurazione locale e un file di configurazione remoto in un'applicazione mobile? Separare le applicazioni dell'interfaccia utente vs singolo con la logica per mostrare / nascondere la funzionalità

score 0 · Accepted Answer

Sono andato avanti e l'ho implementato usando redux-saga per eseguire tre worker per estrarre gli URL richiesti da un canale.

export function* locationsWatcher() {
  yield takeLatest(FIND_ALL_LOCATIONS_START, handleAllLocations);
}

function* handleAllLocations() {
  try {
    // create channel to queue induvidual location requests on
    const locationChan = yield call(channel);
    yield fork(watchLocationRequests, locationChan);

    // get Immutable List of base customer ids
    const customers = yield select(getCustomersList);
    const custArr = customers.toArray();

    // put payloads into location channel
    for (let i = 0; i < custArr.length; i++) {
      const id = custArr[i].id;
      const payload = { path: '/find/${id}' }
      yield put(locationChan, payload);
    }

    // put 'end' into channel for last worker to identify finish
    yield put(locationChan, 'complete')

  } catch (error) {
      console.warn('handleAllLocations setup failed')
  }
}

function* watchLocationRequests(locationChan) {
  // create 3 worker threads
  for (var i = 0; i < 3; i++) {
    yield fork(handleLocationRequest, locationChan);
  }

  while (true) {
    const { payload } = yield take(FIND_LOCATION_REQUEST);
    yield put(locationChan, payload);
  }
}

// get a single location
function* handleLocationRequest(locationChan) {
  while (true) {
    const payload = yield take(locationChan)
    if (payload === 'complete') {
      yield put(findLocationsEnd());
      continue;
    }
    try {
      const response = yield call(request, payload.path);
      yield put(findLocationSuccess(payload, response.properties));
    } catch (err) {
      // update store with 'cannot find' message
      yield put(findLocationFailure(payload));
    }
  }
}

Durante la scrittura del codice iniziale, mi sono reso conto che avevo bisogno di disattivare il "caricamento" nell'interfaccia utente al completamento. Quindi l'ultimo carico utile nel canale è una semplice stringa. Il gestore del canale si impegna a inviare l'azione "finale". Potrebbe esserci un modo più elegante per farlo.

Ho provato questo e per circa 250 chiamate, ci vogliono circa 15 secondi (che include un sacco di aggiornamenti dell'interfaccia utente) di solito in < 300 ms tempo di risposta. Dato che c'è una barra di avanzamento per l'utente, penso che questo sia un buon primo taglio.

In risposta alla mia domanda, non penso che ci sia intrinsecamente qualcosa di sbagliato nell'usare un elenco immutabile e, come dimostrato, toArray fornirà semplicemente un array JS.

Questo modello potrebbe essere appropriato per un numero elevato di chiamate richieste ma una risposta api lenta potrebbe avere un impatto drammatico.